[pulse bridge] Stuttered Audio Playback after xruns

[Glocke]

Hi,

I'm running my regular Audioplayback via a pulse bridge into jack. It's working great for most applications (like VLC). Earlier, I was using ubuntu 18.04 (without ubuntu-studio) and everything was running fine.

Meanwhile, Discord is stuttering while audio playback from time to time (especially if the CPU load slightly increases; CPU is i7-7700K CPU @ 4.20GHz btw, CPU Governor on Performance). This is reproducable most of the time - also it's occuring without doing anything fancy. My ubuntustudio-controls is setup for 44.1kHz, buffer size of 4096, 2 jack periods. I'm getting a couple of xruns (around 2) when the problem occurs.

Discord support isn't any help, so asked on unfa's discord server and was adviced by "ROb van den Berg" to post here. It may be a bug in ubuntustudio-controls.

To give more information:

I also ran VLC in parallel (playing music while reproducing the behavior on discord). VLC plays back fine, even when discord starts stuttering. I recorded the stuttered audio in ardour (routing the pulse-bridge outs into a track). Lots of gaps can be seen in the audio's waveform.

lsb_release -rd
Description: Ubuntu 20.04.1 LTS
Release: 20.04

apt-cache policy ubuntustudio-controls
ubuntustudio-controls:
  Installiert: 1.12.6~20.04.1
  Installationskandidat: 1.12.6~20.04.1
  Versionstabelle:
 *** 1.12.6~20.04.1 500
        500 http://de.archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages
        500 http://de.archive.ubuntu.com/ubuntu focal-updates/universe i386 Packages
        100 /var/lib/dpkg/status
     1.12.4 500
        500 http://de.archive.ubuntu.com/ubuntu focal/universe amd64 Packages
        500 http://de.archive.ubuntu.com/ubuntu focal/universe i386 Packages

I attached the audio file with the stuttering (music playback and some voice can be heard).

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: ubuntustudio-controls 1.12.6~20.04.1
ProcVersionSignature: Ubuntu 5.4.0-58.64-lowlatency 5.4.73
Uname: Linux 5.4.0-58-lowlatency x86_64
ApportVersion: 2.20.11-0ubuntu27.14
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: XFCE
Date: Tue Dec 22 18:24:06 2020
PackageArchitecture: all
SourcePackage: ubuntustudio-controls
UpgradeStatus: No upgrade log present (probably fresh install)

[Glocke (cgloeckner)]

It might not be any help since it's a discord-log... but it reports some underflow issue:

[011:561] [10873] (audio_device_pulse_linux.cc:1762): Playout underflow

Maybe this helps to get some direction on it.. idk.
(I know that neither the filename nor the line number is really helpful since it's related to closed source software^^)

[Len Ovens (len-ovenwerks)]

Some questions... and log file requests.
I see you are using 4096 samples of buffer, Is that because you are using HDMI? or some other reason? Are you using a discord client or a browser instance? Does htop show one core running at 100%?

Could you attach:
~/.log/jack/jackdbus.log
If The device you are using for output is internal, the file:
/proc/asound/PCH/codec#0
or if it is USB:
/proc/asound/PCH/stream0
Also of interest:
/proc/asound/PCH/pcm0p/sub0/hw_params

In the above three cases the device would be PCH,0,0, If your's is different (eg, Device,1,0) then change the PCH to Device and the pcm0p to pcm1p. All of these should be copied while jack is running and also with jack not running but with discord still working through pulse.

My first guess is that discord runs at 48000 and not 44100 or that your audio device only works at 48000. (JACK will use the device at whatever it is able to get but still tell the world it is running at what was asked for) So in this case you asked for 44100 but the device is 48000 only so JACK runs at 48000 but pulse thinks it is running at 44100. Something like VLC, may handle that fine because it is just sending the next 4096 samples when they are asked for but because discord is live it will get asked for the next 4096 samples before it has them to give because it is working at a slower sample rate.

In any of these cases, Studio-controls is not to blame, but rather JACK or the pulse-jack bridge (pulse module) Studio-controls does not handle audio itself at all, it is a script for running JACK and other utilities and creating some connections along the way.

[Len Ovens (len-ovenwerks)]

might have been easier to have you use:
cd /tmp && wget https://community.ardour.org/files/adevices.sh && bash ./adevices.sh >adevices-jack
and
cd /tmp && wget https://community.ardour.org/files/adevices.sh && bash ./adevices.sh >adevices-pulse

[Glocke (cgloeckner)]

I'm using such a large buffer because I encounter less problems using ardour that way. Also for smaller buffer sizes, my voice was sounding "weird" (that's what I was told by my friends in voice chat), so I kept the large buffer size.

48kHz vs. 44.1kHz sounds a bit strange, because I was always using 44.1kHz earlier (including on my old ubuntu installation, where everything worked fine). But for the sake of testing, I tried 48kHz too - and I WASN'T ABLE to REPRODUCE the behavior.

Also I tried 44.1kHz with a smaller buffer (512) and NEITHER can I REPRODUCE it with these settings.

About the logs... I've added my jackdbus.log as attachment. I'll add the rest via seperate comments (cannot select multi files for attachment).

Greetings

[Glocke (cgloeckner)]

/proc/asound/PCH/pcm0p/sub0/hw_params

[Glocke (cgloeckner)]

/proc/asound/PCH/codec#0

Well, I'm using a USB interface (Focusrite), but :

/proc/asound/PCH$ ls
codec#0 id pcm0c pcm0p pcm2c

[Glocke (cgloeckner)]

@Len Ovens (len-ovenwerks): here's the adevices-jack output file

[Len Ovens (len-ovenwerks)]

Sorry for the delay, Anyway, the device is able to use 44k1 without problems and because VLC works fine we can probably rule out jack, and pulse too. Studio-controls is just a script that runs jack and adds bridges to it using software that is not a part of studio-controls so it is not studio-controls specific. Really, that leaves discord either not liking 44k1 or not being able to deal with large buffer sizes. It would be interesting to know what discord asks for when it opens the audio device. You can check this by stopping jack in studio-controls, make sure vlc is not running, run discord and while discord is running run:
cd /tmp && wget https://community.ardour.org/files/adevices.sh && bash ./adevices.sh >adevices-pulse
Attach adevices-pulse here or look at it yourself. The lines to look at are:
used by: pulse
rate: 44100 (44100/1) - The 44100/1 means it really is 44100 as measured by the computer
period_size: 4096 - what we call buffer size, the amount of memory pulse can deal with per period
buffer_size: 8192 - buffer size X nperiods, the application deals with one half while the device deals with the other and then they switch when the device says so (at least in jack) pulse does other things sometimes.

[Glocke (cgloeckner)]

Thx for your reply! :)

The log looks like 44.1kHz and a huge buffer oO - I attached it anyway.

Btw discord quit support for my issue because I'm using an audio interface .. lol.