Jack Alsa PortAudio

Greetings.

I am on Ubuntu 19.10.
I have compiled SC from source 4 times now.
everything works fine ONLY until I install any other sound app, e.g. PureData, or things like PortAudio for real-time Python DSP etc.

At that point there seems to be a mismatch in the sampling rate and it’s not clear what is causing this.
PureData’s sound is choppy and intermittent.
Pyo does not make any sound.

In PureData I have to do the following:
pd -alsa -alsaadd pulse etc.
then it works
But SC is then broken. It seems that SC is forcing Jack at 48000 where everything else is running at 44100.

“creating alsa driver … hw:0|hw:0|1024|2|44100|0|0|nomon|swmeter|-|32bit
configuring for 44100Hz, period = 1024 frames (23.2 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 2 periods for playback
JackDriver: client name is ‘SuperCollider’
SC_AudioDriver: sample rate = 48000.000000,…”
If I reconfigure from qJackCtl it does not have any effect (rebooted, yes).

Tired or reinstalling OS…

any help is appreciated.

If I reconfigure from qJackCtl it does not have any effect (rebooted, yes).

Hm, missed that comment earlier.

Do you mean this sequence of steps? This is the recommended way.

  1. Configure Jack.
  2. Boot Jack server.
  3. Boot SC server, so that scsynth connects to the existing Jack server.

Or this sequence? This is not the recommended way.

  1. Configure Jack.
  2. Boot Jack server.
  3. Quit Jack server.
  4. Boot SC server so that it launches its own Jack instance.

Also, I believe qjackctl does not write the .jackdrc file until you boot the Jack server, so “configure in qjackctl, then boot SC server without doing anything else” is likely to use the old Jack configuration.

In any case, the least risky way to run scsynth is to connect to an already-running Jack server. (The fact that scsynth tries to boot a Jack server if it can’t find one causes a lot of problems for new users – so many problems I’m tempted to say we should take that part out and require a running Jack instance before starting scsynth.)

hjh

Hello hjh,

thanks for reply.

Yes, I try all possible settings, to include:

  1. Configure Jack
  2. Boot Jack
  3. Boot SC server
    this last step overrides 1. and SC_AudioDriver: sample rate = 48000.000000 is still the default.

Once I install PortAudio and/or PD, all goes south.

Neither (PD, Pyo nor SC) are no longer able to resolve conflicts.

Pyo sees both ALSA (@ 44100), Jack (@48000) and the sound card etc. but no sound to be heard, even if I
s = Server(duplex=0)
s.setOutputDevice(0) # or 6, for Jack
s.boot()
s.start()
etc.

PD only works if I launch with
pd -alsa -alsaadd pulse -audiooutdev 3

And SC’s sound is intermittent because of the sample rate mismatch.

I also wanted to ask about real-time priority, should I open another thread?

It seems that SC is forcing Jack at 48000 where everything else is running at 44100.

I tested this. If a Jack server is running, scsynth connects to it and uses the Jack server’s sample rate, no matter what is the value of s.options.sampleRate. If a Jack server is not running, scsynth starts a Jack instance using Jack’s previous configuration (~/.jackdrc) and then uses the sample rate from the Jack server.

In both cases, s.options.sampleRate is ignored and Jack’s configuration is used. Scsynth has no power to override or even set Jack’s sample rate. (Therefore SC is not the cause.)

This means, if scsynth is running at a different sample rate from expected, then it’s because Jack is running at the unexpected sample rate. (And, Jack is the place to fix it, not scsynth.)

What’s puzzling is:

creating alsa driver … > hw:0|hw:0|1024|2|44100|0|0|nomon|swmeter|-|32bit
configuring for 44100Hz, period = 1024 frames (23.2 ms), buffer = 2 periods
… snip…
SC_AudioDriver: sample rate = 48000.000000,…

Jack is clearly requesting 44100, but then failing to get it and running at 48000 instead. (Again, scsynth cannot force 48000 – it is getting 48000 from Jack. Therefore Jack is starting at the wrong rate and not reporting this in its messages. It’s the only explanation.)

So, something in the system is preventing Jack from starting in the right way. What that is… I’m afraid I don’t know. You’d get a more detailed answer from the linux-audio-users mailing list or linuxaudio forum.

This is a weird problem, and not strictly within SC’s purview.

hjh

PS Those tests: 1. Starting Jack at 48000, and SC’s default s.options.sampleRate == nil:

Jack messages:

creating alsa driver … hw:PCH|hw:PCH|1024|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods

SC:

s.options.sampleRate;
-> nil

s.boot;
... snip...
SC_AudioDriver: sample rate = 48000.000000, driver's block size = 1024

s.quit;

// explicitly ask for 44100
s.options.sampleRate = 44100;
s.boot;

SC_AudioDriver: sample rate = 48000.000000, driver's block size = 1024

s.quit;

// stop Jack server
Released audio card Audio0
audio_reservation_finish

// and reboot sc server (requesting 44100)
s.options.sampleRate;
-> 44100

s.boot;

// SC starts Jack -- note Jack is NOT using ServerOptions 44100 sample rate
creating alsa driver ... hw:PCH|hw:PCH|1024|2|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods

// then SC picks up Jack's rate
SC_AudioDriver: sample rate = 48000.000000, driver's block size = 1024

[s.options.sampleRate, s.sampleRate];
-> [ 44100, 48000.0 ]

But I might guess dbus.

I’ve seen dbus prevent qjackctl settings from taking effect. So you might be configuring in qjackctl but then Jack might never get the update.

I was told that cadence might play better with dbus, but I turned off dbus for Jack so I can’t confirm that on my system.

Alternately, turn off dbus in qjackctl and set up PulseAudio not to restart automatically. This involves more steps but I prefer it on my own machine.

hjh

Hello hjh,

understood. Makes sense that SC is not the culprit.
Was hoping someone might have had similar issues and able to recommend strategy.
Thank you for the time and help, much appreciated.

sk

The particular detail that I don’t understand (and I’ve never seen before) is, in your first log here, Jack claims to be configuring for 44100 but ends up running at 48000. I couldn’t reproduce that on my system. It’s very weird.

hjh

Hello, I think the issue described here might be relevant:

so … perhaps my integrated sound card capable of 48000 only, hence Jack uses that, ultimately.
I will try the workaround described in the link above.
Since it seems that this has nothing to do with SC, perhaps we should close this?

Thank you, hjh.

sk