(Sorry this question has already been discussed but the search function in the archive of the list does not work)
Is anyone working on the problem of getting Jack up and running on MacOS again? I installed Jack with brew but I get these “could not handle external client request” errors which seems to be old problems from looking at search results and GitHub discussions - problems introduced when MacOS audio architecture was changed a while back. Is there any progress on these matters? Is someone working on it? I need Jack as it is a dependency to another library I would like to use but I realize that I might have to abandon MacOS as a platform in the process.
That is such good news. What(low cost) hardware would this development be
used on to support the developers with testing/debugging and maybe even
* MOTU LP32 (Preferred)
* MiniDSP https://www.minidsp.com/products/network-audio/avb-dg (I think
MOTU's switch uses midDSP switch hardware)
I hope someday it will be possible to connect 4 or more 8 channel ADAT
modules (32 channels) to a PC under Ubuntu via AVB with low latency. The
only option to get this done under Windows is a Focursrite DANTE based
Rednet 3 right now because Thunderbolt is not really available there as
well. Plan to get Rednet3, but that does not solve the Linux environment
which I prefer. Would love to be able to use the Rednet 3 under Linux but
since DANTE is proprietary , so unlikely.
My two wishes:
[a] Multi (16+) channel low latency audio I/O using ADAT audio AD/DA
[b[ Bitwig supporting LV2 plugins.
With those two, the Linux Audio environment would be perfect and the world
a better place.
*(Apology for the re-sends and ignore the previous edits. Web based Gmail
is such a annoyance and un-logically structured)*
On Mon, March 26, 2018 9:38 am, Christopher Obbard wrote:
> Big typo! I am running on a TI 1GHz AM3358 processor.
Ok, three orders of magnitude is a pretty significant difference. So is
this a BeagleBone Black or something similar?
If so I run the RT kernels from the RCN repo, never had any problem with
those so might be a good starting point.
> I've been using CONFIG_PREEMPT also in other places, I have been
> wondering whether the full RT patch will cause less throughput for
> the jack process.
The design of jackd is not about throughput, it is about low latency. If
you want better throughput, use larger period sizes. That is not really
specific to jack, that is just a general principle in computing, if you
want the best throughput using a general purpose computer design you
should bundle your data into larger groups so that the processor has to
handle fewer interrupts and the DMA controller(s) can run in the most
efficient configuration. If you want the lowest latency you will have to
trade off some throughput for that.
If you want really low latency and high throughput you will likely have to
design custom hardware with pipelined processing (e.g. some of the
cut-through switch designs used for Infiniband and very low latency HPC
Ethernet switches). That is a more advanced topic than how to get jackd
running on an off the shelf processor.
> Both jack and my application are requesting SCHED_FIFO, I am not sure
> of the priority of the application but I am thinking of setting them
both to 70-80.
Why not start off reading the linux audio and jack FAQs that explain how
you should configure your RT system? It sounds like you are getting ready
to re-discover all of that information the long and hard way. Might be
entertaining and educational but probably is no the best use of your time.
I thought there was a page somewhere with suggestions on RT priority
settings, but I do not see it on the jackaudio FAQ or wiki pages. The
rtirq script from Rui might be useful:
(link is toward the bottom)
There may be some useful info here:
but unfortunately the low latency page is from 2000, there have been quite
a few changes in kernel setup since then, so I don't know how useful the
low latency wiki page actually is on linuxaudio.org these days.
The short version is you want the interrupt for your sound hardware to be
highest, then jack right after that. There probably won't be any other RT
tasks on a single use system, so it probably won't matter whether you set
the sound IRQ and jackd priorities to 90 and 89, or 70 and 69, just make
sure they are higher than the default for non-RT tasks, which I think is
The applications using jackd actually run the RT audio thread in jackd
context, so unless I misunderstood something it should not in principle
matter what the priority of the (main thread) of the other applications is
> What about HZ, I currently have this set to HZ_100. Would HZ_1000 be any
Could be better for scheduling latency, but for IRQ driven tasks like
handling the sound hardware I don't know if it matters or not.
>> What audio hardware are you running?
>> Are you using an ALSA driver from the current kernel tree?
> It's an 6-channel in, 6-channel out card with a simple ALSA driver
written by me.
There appears to be a TI McASP driver in the kernel tree already, any
reason you are not using that? Just asking, I have not tried to base
anything on that driver yet myself.
>From that page it appears you would just need to write the codec driver
that handles specifics of the platform driver settings needed, and any
> The driver just binds the codecs to the CPU, nothing latent in there.
> All of the FIFO stuff is taken care of by the TI McASP driver.
OK, it sounds like maybe that is actually what you did, just wrote the
codec portion and used the existing McASP driver to handle the I2S/TDM
> Currently the driver reads & writes to 8 channels but two of the
> out channels are unused, I can possibly try to gain some
> performance here.
Not worth the trouble at this point. If you get a system that is mostly
working and just has an occasional problem it might be worth optimizing,
but it sounds like right now the system is pretty broken, so look for big
problems, not small optimizations you could make.
> Sorry, I missed out the first part of the log. The LockedTimedWait
> error came when my client tried to connect. I think it's to do
> with the Kernel scheduling.
Make sure you have RT scheduling enabled for whatever user account you are
using, try again and get the entire startup log.
> It manages to open and all performs fine at 128 frames.
OK, then make sure you are really clear about when you are trying to
debug problems with e.g. 32 frame setting vs. problems with the 128 frames
setting, since it looks like you have different problems with the
different period sizes.
> I've not had much luck with PREEMPT_RT in the past, I don't
> think I've set the priorities of interrupts properly.
Then start with Rui's rtirq script. Some of the devices in the default
script are x86 specific, and even some of those are probably outdated, but
the framework is great, put the devices you want in the configuration file
and run the script, it will set everything for you.
> I think I need to chrt the soundcard IRQ highest, then JACK, then my
> AFAIK, jack already does this with the -R argument & sets the
> scheduler priority to SCHED_FIFO.
I don't think the application RT priority matters, if I understand
correctly jackd will be allocating the thread that the application uses
for audio callback, so that thread of the application should run at jackd
priority, so for a simple embedded system you would just need to set the
sound hardware IRQ the highest, then jackd after that (with the -R
argument, default values is probably OK), then everything else can run at
non-RT default. I think non-RT default is 50 and jackd default is 70
based on what I have seen on x86 machines.
> Have you got any links to information, books etc on RT patch?
Just this, but honestly the original jackd developers took care of almost
everything for you, you shouldn't need to know much about the low level
details just to get it running.
Running jack with a small buffer (-p64 -n2), and connecting with any
client causes issues.
With higher buffer sizes, all is OK.
This is on an ARM embedded system, with a single core 1MHz processor.
I've set the cpu governor to performance.
I have a custom compiled 4.14 kernel with omap2plus_defconfig with the
following config settings:
$ jackd -R -P95 -dalsa -dhw:0 -r48000 -p64 -n2
> JackPosixProcessSync::LockedTimedWait error usec = 5000000 err = Connection timed out
> Driver is not running
> Cannot create new client
> CheckSize error size = 32 Size() = 12
> CheckRead error
> CheckSize error size = -1 Size() = 4
> CheckRead error
> CheckSize error size = 0 Size() = 12
> CheckRead error
Also, with higher buffer sizes sometimes I get xruns. After enabling
alsa debugging, the error is:
> ALSA: PCM: [Q] Lost interrupts?: (stream=0, delta=221, new_hw_ptr=181343, old_hw_ptr=181122)
Loosing the FIFO interrupts doesn't seem like a great thing.........
I _think_ the issue is to do with the kernel scheduling, but this why
I ask the experts :-).
Can anyone suggest any kernel settings that will improve my situation?
I am working on Arch Linux and use gcc and gdb, my current IDE is Visual
Can someone help me with how to use waf? It let's me configure, build and
install... but what if I want to test a change in code? I made a short
script wich unistalled, built and installed jack2 again so I could see the
change, but is there another way like executing jackd in the build dir? How
about cross-compiling to another architecture? I couldn't find anything
allowing me to do that. And how do you debug a program like this? I only
have experience with small projects and it's really hard to find anything
about it on the internet.
Sorry if this may end up being a stupid question but I have been spending
weeks trying to figure this out.
Sent from: http://jack-audio.10948.n7.nabble.com/Jackit-f3.html
I observed some strange behavior of libjack and libjackserver.
If I have a multiprocessing application with one jack server fork and
one jack client fork, jack_client_open crashs.
Here the backtrace:
#0 __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:174
#1 0x00007f83dddb803f in jack_find_driver_descriptor(_JSList*, char
const*) () from /usr/local/lib/libjackserver.so.0
#2 0x00007f83dddb9ef8 in Jack::JackServerGlobals::Init() () from
#3 0x00007f83dddb64f8 in jack_client_open_aux(char const*, JackOptions,
JackStatus*, __va_list_tag*) () from /usr/local/lib/libjackserver.so.0
#4 0x00007f83dddb67b1 in jack_client_open () from
#5 0x0000000000414f04 in talker_Process (arguments=0x63f680
<arguments>) at ../src/net/avb/talker/talker_process.c:395
#6 0x000000000042d487 in avbruntime (arguments=0x63f680 <arguments>) at
#7 0x000000000042e888 in main (argc=11, argv=0x7ffebee6f678) at
The interesting thing is, jack_client_open keeps crashing if I remove
all the jack server code.
It was neccessary to remove the -ljackserver linker option as well,
because the client code linked against libjackserver.so instead of
This means it is not possible to have a jack server and a jack client in
a single multiprocessing application.
FFADO version 2.4.1 is now available, a package of userspace drivers for
firewire audio interfaces. This is a bugfix release with many of the
changes associated with the use of python3 and distribution packaging.
This is a source-only release which can be downloaded from the ffado.org
or via the direct link:
Issues addressed in this release include:
* Fix some python syntax which was not compatible with python3. These
were missed during the preparation of FFADO 2.4.0.
* Modify the SCons build system to allow for scons running under python3.
As of this release there seem to be a number of issues in scons itself
when running under python3, so building FFADO in this environment is not
* Merge distribution patches provided by package maintainers.
* Address some difficulties experienced by package maintainers when
* Improve the output of ffado-diag.
Thanks to the developers and users who contributed to this release: Nicolas
Bouleng, Benoit Delcour, David Kastrup, Hector Martin, Orcan Ogetbil, Dave
Plater, David Runge, Jano Svitok and Jonathan Woithe. If an omission has
been made please contact us through the ffado-devel mailing list so this can
I am new to jack and trying to setup Jack2 on Ubuntu 17.10 on a Dell
laptop 15-5570 that uses a Realtek ALC3246 sound device.
It is basically working ( I am testing it with simple_client and
latent_client) but I think that I am doing something wrong as the first
time I use it after booting the laptop I get the error.
"ATTENTION: The playback device "hw:0" is already in use. Please stop
the application using it and run JACK again" followed by lots of
"Cannot connect to server socket err = No such file or directory"
"Cannot connect to server request channel"
fuser -v /dev/snd/pcmC0D0p shows that it is use by pulseaudio.
However the 2nd and subsequent runs of the jack example clients work
just fine without any error.
Thanks for any suggestions or help