Too many xruns with JACK

[virtualdxs]

I have a similar issue to #60. I'm trying to use this as a sink for JACK, but it's extremely choppy due to excessive xruns (buffer underruns). The weird think is it doesn't happen with aplay, and it doesn't happen with JACK via my speaker or wired headphones, so I have no clue what's causing it.

[jamshark70]

I can't say much specifically about bluez-alsa since I only built it yesterday. I can only say that I got somewhat acceptable performance from JACK --> ALSA --> bluealsa by raising the buffer size and periods per buffer in qjackctl. (I set 2048 samples/buffer and 3 periods/buffer = 139 ms latency -- you will not get low-latency performance through Bluetooth, I'm quite sure.)

I'm speculating a bit, but I think the issue may be: when ALSA is connected to built-in hardware or a USB soundcard, for each buffer, it needs only to dump the PCM data over the wire, but for Bluetooth, it needs to compress the data for transmission. That takes time. If this is late for some reason (and, a small buffer will make it more likely to be late), you would get hiccups.

I had a different problem, though. On my machine, it seemed to be stable when just playing a sound file in Audacity (selecting JACK and bluealsa) -- I ran it for about five minutes, qjackctl reported about 5% DSP load, no sign of trouble (and it sounded clean in the earphones).

Then I tried some synthesis in SuperCollider. It seemed OK for a while, but then at some point I guess the DSP load went too high and then JACK froze and eventually crashed.

../../../src/asound/bluealsa-pcm.c:130: IO thread paused: 4
ALSA: could not complete playback of 2048 frames: error = -32
ALSA: could not complete playback of 2048 frames: error = -32
JackPosixProcessSync::LockedTimedWait error usec = 5000000 err = Connection timed out

The thread safety bug might also be relevant. When I changed my bluealsa service script to the following, DSP load dropped a few percentage points, and it seemed to survive up to a much higher DSP load.

export LIBASOUND_THREAD_SAFE=0
/usr/bin/bluealsa

But, then it crashed as soon as I started typing things on a USB keyboard. So it seems inherently unstable -- at higher DSP loads, maybe sensitive to other system interrupts. (JACK is notably intolerant of any timing or connection issues with the audio hardware.)

TL;DR: 1/ Try a (much) bigger buffer in your JACK settings. 2/ Try disabling thread safety in ALSA (as discussed in the bluez-alsa readme).

[virtualdxs]

@jamshark70 Thanks for the info! I increased the buffer to 2048/3 and I'm running at 0 xruns.