Question: limit for number of JACK clients

[spatialaudio]

Question: limit for number of JACK clients

[HaHeho]

For reference, here's a link to the question: http://lists.jackaudio.org/pipermail/jack-devel-jackaudio.org/2019-August/002133.html (it may only work if you are subscribed to the list).

BTW, this is the link to the archived thread on the Jackaudio mailing list (since this version of the list is offline now).
https://lists.linuxaudio.org/archives/jackaudio/2019-August/002133.html

[mgeier]

I don't know if there is a limit on the number of clients, but there is definitely a limit on the number of ports. By default that's 256, and you can increase it when starting jackd with the --port-max option (or with qjackctl).

[HaHeho]

That could actually be what is limiting there. Since I'm generating clients with 2 in- and 2 output ports, which corresponds to getting close to 256. Thank you, I will investigate if starting JACK with the different configuration will fix it for me. To be continued...

[mgeier]

@HaHeho Any news on this?

[HaHeho]

Here are some observations of my tests:

jackd --port-max 64 -d coreaudio
not able to create more then 14 clients

jackd --port-max 256 -d coreaudio
not able to create more then 62 clients

jackd --port-max 2048 -d coreaudio
not able to create more then 62 clients

Please consider that the number of JACK clients I'm referencing there are spawned by my benchmarking procedure (2 in and 2 out ports each). Additionally there should not be any other clients or ports active, except for the system recording and system playback ports (2 each). So at this point the JACK server seems to signal the reached limit.

For 64 and 256 (should be default) that limit matches the port limitation theory quite well (15*4=60 + 4 system ports). Sadly for 2048 (tried 512 as well of course) I don't experience the expected up-scaling. Maybe there is another limit?

[mgeier]

Hmmm, there indeed seems to be another limit ...

You should probably ask the JACK mailing list: http://jackaudio.org/community.html

[HaHeho]

I have encountered the number limitation number of JACK ports in another instance. I have just posted the topic on the JACK-DEVEL mailing list. Lest hope for some insight. :)

BUT, I am not 100% sure that port number is necessarily what also leads to the observed limitation that started this topic. They fail for different reasons as reported by the server, being No more refnum available\nCannot create new client for the client number, and Maximum number of output ports is reached for application ref = 2 in case of the port number.

With the help of jackd --port-max 2048 I was able to raise the port limitation to around 800 (not sure how or why exactly, see mailing list). BUT , this does not result in more than 62 JACK clients that I could instantiate. Again, speaking against the port limitation being an explanation for my initial question.

[mgeier]

For reference, here's a link to the question: http://lists.jackaudio.org/pipermail/jack-devel-jackaudio.org/2019-August/002133.html (it may only work if you are subscribed to the list).

There's already an answer which mentions the constants in https://github.com/jackaudio/jack2/blob/develop/common/JackConstants.h

[HaHeho]

Yes correct, thanks. Now that I have taken a look again, I noticed #define PORT_NUM_FOR_CLIENT 768 which is actually raising the limitation in my latest test case. I mentioned something around 800, since 768 seemed arbitrary.

Looking at the file most of the numbers still seem arbitrary, but at least there is a known source for the limitations. I will ask what the consequences of raising the limits might be and will try to recompile. But on OSX or potentially Windows, it seems like a not very pleasant adventure at the moment. :/

Sadly, even if I manage, I will not really be able to utilize these changes in my application. I can hardly rely on users having to build JACK themselves to utilize functionality. (Even though these limits only kick in in pretty specific use cases my pipeline, so everything else works fine from pre-build binaries.)

[mgeier]

It might be easier to somehow change your benchmarking system to utilize fewer JACK clients?

Either way, I guess this issue can be closed because there is nothing we can do on the Python side, right?

[HaHeho]

Correct. As mentioned before, the only way this can be circumvented is by building a modified JACK version yourselves. Anyhow, this is a very specific use case and the limit of ports is not going to be a problem any time soon in realistic use cases.