Need help debugging SuperCollider's PortAudio on Linux

[Hanno Zulla]

Hello,

I would appreciate some help debugging / improving the PortAudio
interface of SuperCollider.

When using SuperCollider's PortAudio driver on Linux, I have two
problems:

- it works with PulseAudio's "default" device,
but there are occasional buffer underruns

- it does NOT work with pure ALSA's "default" device,
(very choppy audio, see [1])

- it works with a hardware device like "hw:0,0" in pure ALSA,
no buffer underruns on my system (but not sure)

I don't know if the "buffer underrun" issue and the "ALSA default device
choppy audio" are the same or not.

After digging into the code, I found that SuperCollider unnecessarily
allocates all channels reported back by PortAudio, but my patch [2]
for that wouldn't fix the issues above.


Some background to explain the problem, please bear with me for this
writeup.


SuperCollider [3] is a programming language for audio synthesis, or
in other words, a programmable electronic synthesizer.

SuperCollider is also the synthesizer inside of Sonic Pi [4], a
Live Coding synthesizer used in schools to teach coding. Sonic Pi is
using a ruby interpreter as a more kids-friendly programming language
and converts the commands to SuperCollider's language while hiding its
complexity from the users.

Sonic Pi is mainly developed for Raspberry Pi, but just like
SuperCollider, it is distributed for OS X, Windows and generic Linux
distributions.

I'm a casual contributor to the Sonic Pi team and our Linux users
experience recurring problems with SuperCollider's default JACK driver.
Well, it works fine, but most Linux desktop distributions ship with
PulseAudio and for an average user, it's fairly complicated to get JACK
and PulseAudio cooperate. (You can use one of them at a time, but
they'll stomp each other's feet once you try to run both.) So a simple
way to use SuperCollider without JACK would be a major advantage for
Sonic Pi users who don't want to fiddle with their audio backends.

The SuperCollider scsynth backend comes with three different
AUDIOAPI drivers:

- jack (default for Linux)
- portaudio (default for Windows)
- coreaudio (default for OSX).

The portaudio driver SC_PortAudio.cpp works fine on Windows. The
JACK driver SC_JACK.cpp works fine on Linux. Both drivers use more or
less the same code structure and flow.

It is possible to build SuperCollider on Linux using the PortAudio
driver:

git clone https://github.com/supercollider/supercollider.git
cd supercollider
# see README_LINUX.md, install build dependencies, then:
git submodule init
git submodule update
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release -DAUDIOAPI=portaudio ..
make
sudo make install
/usr/local/bin/sclang

After this, you can enter SuperCollider code:

s.options.device="default"
s.boot
x = {PinkNoise.ar(0.1)}.play
// should result in pink noise on one channel
x.free
// leave with ^D

Try this sclang code with and without PulseAudio [5] and you'll
see the problems described above.


Help would be appreciated. The goal is to get SuperCollider's
SC_PortAudio.cpp working with pure ALSA's "default" device and get
rid of the buffer underruns. I've spent some time looking at this
problem now and haven't found an obvious way to debug/fix this.


Kind regards,

Hanno


[1] https://github.com/supercollider/supercollider/issues/1944
[2] https://github.com/supercollider/supercollider/pull/1943
[3] http://supercollider.github.io
[4] http://sonic-pi.net
[5] http://askubuntu.com/a/394872/274072

[Phil Burk]

Hello Hanno,

I have been using PortAudio on an RPi 2. It is a great machine. I just
ordered an RPi 3.

There is a Wiki page for Portaudio on Raspberry Pi here:

https://www.assembla.com/spaces/portaudio/wiki/Platforms_RaspberryPi

Note the bug at the bottom. The default low latency is too low and causes
glitches or "choppy audio".

I increased the suggested latency in my test program to 0.030 seconds and
was able to get smooth audio. You can probably go lower but for live coding
you don't need very low latency.

To set the latency you need to call Pa_OpenStream() and set
suggestedLatency in the outputParameters.

http://portaudio.com/docs/v19-doxydocs/portaudio_8h.html#a443ad16338191af364e3be988014cbbe

Let me know if increasing the latency does not work.

Post by Hanno Zulla
http://sonic-pi.net

Sonic Pi sounds like a great project. I'll check it out.

Phil Burk

[Spencer Russell]

Does the supercollider portaudio code do the audio processing directly
in the audio callback or does it pass data to the main task through some
other buffers?

I'm debugging some dropout issues with portaudio->alsa->pulseaudio->alsa-

hardware for my Julia wrapper, but haven't really troubleshot enough

to know where the issue is. In my case the callback reads/writes from
an intermediate buffer that is fed/consumed by the main task, so I
suspect there could be an issue where my portaudio buffer size is
smaller than the pulseaudio buffer size, so the callback is being
called back-to-back. Reading the docs more carefully it looks like
maybe I should be giving zero for my buffer size when I open the stream
to let portaudio choose.

Not sure if this is helpful, but I figured our issues might be related.

-s

Hello Hanno,
I have been using PortAudio on an RPi 2. It is a great machine. I just
ordered an RPi 3.
https://www.assembla.com/spaces/portaudio/wiki/Platforms_RaspberryPi
Note the bug at the bottom. The default low latency is too low and
causes glitches or "choppy audio".
I increased the suggested latency in my test program to 0.030 seconds
and was able to get smooth audio. You can probably go lower but for
live coding you don't need very low latency.
To set the latency you need to call Pa_OpenStream() and set
suggestedLatency in the outputParameters.
http://portaudio.com/docs/v19-doxydocs/portaudio_8h.html#a443ad16338191af364e3be988014cbbe
Let me know if increasing the latency does not work.

http://sonic-pi.net[1]

Sonic Pi sounds like a great project. I'll check it out.
Phil Burk
_________________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio

Links:

1. http://sonic-pi.net/

[Ross Bencina]

Post by Spencer Russell
Does the supercollider portaudio code do the audio processing directly
in the audio callback

Yes. I had something to do with that code many years ago when I worked
on the windows SC port.

Ross.

[Hanno Zulla]

Hi,

Post by Spencer Russell
Not sure if this is helpful, but I figured our issues might be related.

Yes, I stumbled over this in your discussion with Phil Burk:

<https://lists.columbia.edu/pipermail/portaudio/2016-March/000351.html>

Post by Spencer Russell
Also not that if you are doing both audio input and output then you
should start with the input empty and the output full. That way if
the app gets hung up the input will fill and the output will drain
symmetrically.

Indeed, SuperCollider does input, audio processing and output in its
callback loop. I wonder what to code so that one can "start with output
full" and if this might be an explanation for SuperCollider's audio issue.

Regards,

Hanno

[Hanno Zulla]

Hi,

Post by Hanno Zulla
Indeed, SuperCollider does input, audio processing and output in its
callback loop. I wonder what to code so that one can "start with output
full" and if this might be an explanation for SuperCollider's audio issue.

Ok, if I tell SuperCollider to skip the input channels and only compute
output audio...

<https://github.com/supercollider/supercollider/issues/1944#issuecomment-205299557>

...the problems go away almost completely, using default latency values.

So it's something in the way input and output are being handled in the
main loop

<https://github.com/hzulla/supercollider/blob/audiodriver/server/scsynth/SC_PortAudio.cpp#L219-L276>

Yet I still don't know what it is causing this.

Thanks,

Hanno

[Hanno Zulla]

Hi,

ok, sorry to flood the mailing list, but I have now found a fairly
minimal source example for you to reproduce the problem on your box,
without having to build a SuperCollider binary.

The original paex_sine.c from the PortAudio documentation was doing
audio output, only.

I have modified the original code minimally, to reflect the behaviour
from SuperCollider's code.

- the stream format is using paFloat32 | paNonInterleaved

- the program opens a stereo input channel on the default input device

Bingo, opening the input channel triggers the problem on my box. (*)

Once the input channel is added to the program, the exact same problem
occurs as experienced with SuperCollider. Replace &inputParameters with
NULL in Pa_OpenStream() and the problem goes away.

The callback here is really minimal, so it's not any audio processing
inside the callback look causing this.

What can be done to fix this?

Kind regards,

Hanno

(*) Ubuntu 15.10, amd64, desktop CPU.
PulseAudio turned off, using pure ALSA's "default" device.

[Phil Burk]

Hello Hanno,

Thanks for the test program. I will try that when I get on my Linux machine.

Good job narrowing down the issue. I agree this looks related to
input/output stream synchronization. If the output is not primed properly
then there can definitely be issues with output underruns.

Note that there is a flag, paPrimeOutputBuffersUsingStreamCallback, that
you can OR with paClipOff.

http://portaudio.com/docs/v19-doxydocs/portaudio_8h.html#ad7b862a223edd680d7985c33c847e31d

Also note that paPrimeOutputBuffersUsingStreamCallback may not be fully
implemented on ALSA.

http://www.portaudio.com/docs/proposals/status.html

The problem may be related to block size adaptation. Try setting
framesPerBuffer to paFramesPerBufferUnspecified, 0, when you open the
stream.

Also note that the callback is passed a set of flags.
http://portaudio.com/docs/v19-doxydocs/portaudio_8h.html#a55a005924bcfa0424594f4f65cd4ae82

Are any of those being set?

Thanks,
Phil Burk

Post by Hanno Zulla
Hi,
ok, sorry to flood the mailing list, but I have now found a fairly
minimal source example for you to reproduce the problem on your box,
without having to build a SuperCollider binary.
The original paex_sine.c from the PortAudio documentation was doing
audio output, only.
I have modified the original code minimally, to reflect the behaviour
from SuperCollider's code.
- the stream format is using paFloat32 | paNonInterleaved
- the program opens a stereo input channel on the default input device
Bingo, opening the input channel triggers the problem on my box. (*)
Once the input channel is added to the program, the exact same problem
occurs as experienced with SuperCollider. Replace &inputParameters with
NULL in Pa_OpenStream() and the problem goes away.
The callback here is really minimal, so it's not any audio processing
inside the callback look causing this.
What can be done to fix this?
Kind regards,
Hanno
(*) Ubuntu 15.10, amd64, desktop CPU.
PulseAudio turned off, using pure ALSA's "default" device.
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio

[Hanno Zulla]

Hi,

thanks.

Post by Phil Burk
Note that there is a flag, paPrimeOutputBuffersUsingStreamCallback,
that you can OR with paClipOff.

No, didn't help when I added that.

Post by Phil Burk
The problem may be related to block size adaptation. Try setting
framesPerBuffer to paFramesPerBufferUnspecified, 0, when you open the
stream.

No, that didn't help, either.

Post by Phil Burk
Also note that the callback is passed a set of flags.
http://portaudio.com/docs/v19-doxydocs/portaudio_8h.html#a55a005924bcfa0424594f4f65cd4ae82
Are any of those being set?

Yes, I get paOutputUnderflow (value 4) with my paproblem.c once it opens
an input channel.

Post by Phil Burk
If the output is not primed properly then there can definitely be
issues with output underruns.

Ok, how does one prime the output properly?

Is there some example code to look at for this?

Kind regards,

Hanno

[Hanno Zulla]

Hi,

Post by Phil Burk
Also note that paPrimeOutputBuffersUsingStreamCallback may not be
fully implemented on ALSA.

Indeed, it isn't.

Post by Phil Burk
/* XXX: Ignore paPrimeOutputBuffersUsingStreamCallback
untill buffer priming is fully supported in pa_process.c */

Kind regards,

Hanno

[Ross Bencina]

Post by Hanno Zulla
Indeed, it isn't.

Post by Phil Burk
/* XXX: Ignore paPrimeOutputBuffersUsingStreamCallback
untill buffer priming is fully supported in pa_process.c */