Support Jack server and native sound driver on all main plateforms (Windows, MacOs and Linux)

[newlaurent62]

Hello,

Is it possible to implement jack support as well as native sound driver support on the same jamulus build with the main platforms (Windows, Linux and MacOS) ? Ardour does such a thing.

On Linux ALSA and Jack
On Windows ASIO and Jack
On MacOS coreaudio and Jack

Today, we need to compile specific version for jack support. So we can have Jack support or native sound support but not both.

Kind Regards,
Laurent

[dcorson-ticino-com]

I think this is known as SMOP, "Simple Matter Of Programming"
If you know how, please do it.

Otherwise realize that Jamulus is written and maintained by volunteers who do this along side their bread winning jobs.
As this is the first time I can remember seeing this need, it appears to me to not be a very common need. As such will probably not be high on the priority list, especially as you say it is possible to have, just not as convenient as in some other program.

We will see what others say.

[jujudusud]

On Linux, the realtime sound server is JACK. Jamulus is used to minimise the latency by sending sound via UDP packages through the internet. using another sound server is not reasonable because it would mean losing the advantage of low latency...

I will have a look to windows script if I can do anything to autobuild jackonwindows version. do you have already made a script file localy ?

[newlaurent62]

This use case in action : #1717

[jujudusud]

What about a reply here : #1705

[hoffie]

Is it possible to implement jack support as well as native sound driver support on the same jamulus build with the main platforms (Windows, Linux and MacOS) ? Ardour does such a thing.

It's almost certainly possible, but it might not be simple with the current code base. As this whole topic is rather niche (at least that's my impression), we'd likely want to limit the amount of maintenance work regarding this.

Providing jack-enabled autobuilds for Windows and Mac may be viable options if someone can contribute the necessary scripts. This would enable those people who do need jack support on these platforms to download binaries, but would avoid any new code complexity by introducing backend switching logic to Jamulus.

On Linux ALSA and Jack

I don't see any benefit in attempting to directly access ALSA. jackd uses ALSA as a backend (on Linux) and provides relevant abstractions.
If we were to add additional support on Linux, I'd rather expect that to be pipewire which some distributions start adopting as a replacement for both pulseaudio and jackd.

[npostavs]

I recently updated #870 (Portaudio support) so that it works on Linux. Portaudio supports ALSA and Jack (and theoretically OSS too, though it didn't work when I tried). See first post there for compile instructions.

[npostavs]

So that we have less code to maintain. In the end, the code which "directly" uses WASAPI would look a lot like portaudio's code.

(portaudio doesn't support Audiograph, but from what I've read, it would have more latency than WASAPI anyway)

[jujudusud]

Understood. Since JACK server provides the use of Portaudio to connect all the sound cards on Windows, Is it already needed to code this in Jamulus core ?

[npostavs]

No, JACK is yet another API. Portaudio is able to use it as well (although I'm not sure if it handles JACK on Windows).

[jujudusud]

JACK on Windows is a multi-purpose audio server that connects audio streams using the Windows system drivers. It connects (OUTPUT) to those audio drivers using the PortAudio project (so JACK can connect using dsound, wmme, ASIO, etc) depending on what the soundcard’s drivers support.
JACK is already implemented in Jamulus for Windows.
In other words, Jamulus with JACK on windows support already uses Portaudio with no additional latency. No code to add.

[ann0see]

However, it adds the need of installing a somewhat complicated program for newbies (avoiding the need of that is what the portaudio WDM/WASAPI support is also targeted at).