Questions about jackd

[hzulla]

Hi,

"I don't know jack."

The main issue reported back by users of the Ubuntu PPA is problems with jackd. I'm not familiar with jackd myself, so this is a list of open questions in order to research the situation, possibly improve and maybe even patch Sonic Pi to allow switching sound cards on Linux (see #842).

1. Is it correct that supercollider (and only supercollider) is connecting to jackd within Sonic Pi?
2. Is supercollider using jackd on Windows and OSX as well, or is this Linux-only?
3. If jackd is Linux-only, what audio output APIs are used by supercollider on Windows and OSX?
4. Why is it required that the Sonic Pi ruby server is starting jackd - why does the system not start jackd automatically?
5. Is there a cleaner way for an application to request starting/using jackd without using a command line through sys?
6. Is there a reason why these hacks by @rbnpi are necessairy? Why doesn't Ubuntu come pre-configured for this?
7. Why does using jackd kill the rest of a default Ubuntu desktop's sound? Why doesn't Ubuntu come pre-configured for using jackd and non-jackd applications without stepping on each other's toes?
8. Is there a good, clean code example of an Ubuntu application using jackd that we can learn from how to do this better?

If you can answer any of these, your input is most welcome. Thanks!

[samaaron]

Some partial answers:

1. Depends whether other processes need and use jackd at the time.
2. jackd is just used for Linux by scsynth
3. OSX is core audio - I'm not sure the name of the windows audio API
4. jackd isn't necessary for linux to run - and Linux audio isn't the most unified thing in the world ;-)
5. no idea
6. again unknown
7. :-)
8. would be nice.....

[hzulla]

Thanks so far!

Good to know that jackd is Linux-only, I can work with that and don't have to worry about how to test things outside Linux. But how does switching sound cards work on OS X and Windows when using Sonic Pi (e.g. sending sound to the HDMI output instead of the headphone output)?

[samaaron]

Currently SuperCollider binds to the default audio card, so to switch cards, you need to do it at the OS level first before booting Sonic Pi. Attempting to switch cards whilst Sonic Pi running can lead to bad behaviour including zombifying SuperCollider :-(

[hzulla]

About 5: There is a Jack API to manage the server including start/stop: http://www.jackaudio.org/api/group__ControlAPI.html

(Noted for further research)

[hzulla]

@samaaron is jackd a requirement for Sonic Pi or would it be worth investigating if a jackless supercollider is possible? Would you accept that as a solution on Linux?

[samaaron]

jack is definitely not a requirement for Sonic Pi - but I believe it is a requirement for SuperCollider. If you're able to figure out how to get SuperCollider to work on Linux without jackd - that would be amazing. However, my understanding is that it's currently required.

[hzulla]

Supercollider has audio drivers. So it might be possible to add an ALSA or PulseAudio driver next to the existing jackd driver. Worth a shot.

[hzulla]

Yow, they already have a working jackless version:
supercollider/supercollider#1658
It seems to have issues, but nonetheless, it's there.

[the-drunk-coder]

Hmm, this issue seems to be Ubuntu-Specific ... i'm using Arch Linux, and in my case, scsynth automatically starts JACK (jackd) on the default sound card or connects to JACK if it's already running ...

As for your questions:
1.) scsynth is connecting to JACK, but it shouldn't block anything else from connecting to JACK ...
2.) / 3.) Isn't it called ASIO on Windows ?

4.) In my case, when i run scysnth (without Sonic Pi), JACK is started automatically if it's not running already ... so, it shouldn't be necessary to run it from ruby ...

5.) see answer for 4.) ... it's possible to configure applications to start JACK if they need it !

6.) The usual desktop Linux system isn't pre-configured for real-time audio ... just listening to music doesn't really demand this. So, these tweaks should reduce latency and the like ... there are even specific kernel branches for real-time processing. Nowadays, i think the default kernel supports SMP preemption. With Arch, this option is enabled by default ...

7.) It doesn't necessarily ... some applications don't have native JACK support, so they can't connect to the default sound card using ALSA if JACK is already hogging it. BUT, there's a plugin that simply re-routes any ALSA output to JACK (alsa-jack-plugin). Et voila, desktop sound is back !

As for the second part of the question, JACK is intended for pro-audio users and provides powerful anywhere-to-anywhere routing. A little too much for the average desktop user. For those, there's pulseaudio or plain alsa. PulseAudio is somewhat the standard for desktop applications. Anyhow i haven't used it in ages ;)

8.) You might want to check how other linux distributions like arch do this ... i haven't really configured anything manually, and scsynth just starts jack on demand ...

[hzulla]

After some research, here's what I found out so far.

• jackd and pulseaudio both want direct access to the hardware.
  They have different ideas about what to do with the hardware once they have it. jackd is designed to cater to musicians' needs, pulseaudio to average users. There are some fairly different ideas about how to implement things and it looks like there are some grudges, too.
• there is a compatibility layer that allows pulseaudio to connect to jackd as a client.
  However, at least on Ubuntu this breaks the pre-configured audio mixer setup - things work, but while jackd is running, the user cannot change the audio volume anymore. The jackd folks appear to consider Ubuntu's default config and jackd packaging broken and say that other distributions get this right.
• there is no compatibility layer that allows jackd to connect to pulseaudio as a client.
  The jackd folks say that this is undesired, as pulseaudio doesn't give the musicians' level of audio quality that they require.
• it seems to be possible to use supercollider without jackd.
  People have been able to do this, but not me yet. Supercollider can be configured to use portaudio instead of jackd. In fact, portaudio is the default audio driver for supercollider on Windows and works fine there. There seems to be some linux-relevant edge case in supercollider's portaudio driver affecting my setup, but it seems worth debugging.

All in all, I think that trying to get supercollider to run without jackd is the "easiest" route to make Sonic Pi easier to use for Linux users, including Raspbian. If that works, the next hurdle will be to convince Debian/Ubuntu/Raspbian to package a jackless version of supercollider as an alternative package. After that, we could finally add a "soundcard selector" to the Linux version of the Sonic Pi UI.

This ticket is now closed. Thanks to everybody.

[nealmcb]

Many thanks - tricky stuff!

But PLEASE, until this is all fixed, save us from nightmares and endless confusion by noting this all in the docs for getting started with sonic-pi on Ubuntu.

I'm running Ubuntu Trusty, and by following the instructions in #827 (comment) I've succeeded in getting sonic-pi to run, by running qjackctl and "play" first, but in the process screwed up all the rest of the audio on my system, so I can't continue to listen to Sam demo it in https://youtu.be/TK1mBqKvIyU

Damn!

And include an explaintion of how to get back to a nice working pulseaudio after trying sonic-pi out. It seems to work to just "Stop" from qjackctl, but there is enough voodoo involved that I'm scared now.

[samaaron]

@nealmcb great that you got it working. Please do consider sending a pull request to improve the docs based on your recent experience and knowledge.

[nealmcb]

Thanks for the invite. This pull request should help: #1204