[LAU] Crackles in audio - how to troubleshoot ?

[Len Ovens]

On Fri, 26 Aug 2016, jonetsu at teksavvy.com wrote:

> As this shows so far, Bitwig contaminated the audio system.  Or it is a
> coincidence ? I will see in the coming days.
>
> Now, _if_ the problem is purely software based, no capacitors involved,
> is there a way, short of a reboot, to reinitialize completely the audio
> infrastructure ?  Like cleaning up every buffer, everything and
> restart the audio subsystem as if a reboot has happened ?
>
> What runs on this system is:
>
> S<Ll  /usr/bin/pulseaudio --start --log-target=syslog
normal
>
> Z<    [pulseaudio] <defunct>
not normal Can you kill -9 that one by using the PID?
>
> S<Lsl /usr/bin/jackd -T -ndefault --sync -T -P95 -ndefault -dalsa
>      -dhw:M1010LT -r44100 -p128 -n2
I have always used 48k but that should not make a difference.

>
> S     /usr/lib/pulseaudio/pulse/gconf-helper

I do not have this either, but that could something to do with the DE.

> Yes, there is always a zombie pulseaudio process.  Killing -9 pulseaudio
> is not easy, if possible at all, since it will always restart.
>

That sounds like there are two dbus running and two pulse. normally pulse 
is run across dbus which should ensure only one of them. Do you have two 
sessions open? (one with a dfferent user?)

try running these two commands while the noise is there:
pactl unload-module module-udev-detect
pactl unload-module module-alsa-card

Does that help? Note: to do this, all of your audio must be running from 
pulse through jack to the 1010.

I have found pulseaudio to be very stable provided pulse uses jack as it's 
only i/o device. If pulse sees both jack and another device (internal 
audio for example) I get xruns and other odd things. It seems that while 
pulse has no problem with two cards out of sync if it is connected 
directly, it does have a problem if one of those cards goes through 
pa-jack bridge. Do remember that the pa-jack bridge is mostly a hack that 
was originally done as an example and has not been polished. It is in 
any case very useful if these things are take into account.

In other words I use pulse only as a front end for jack... nothing more. 
If I want pulse to see some other AI, I start a zita-ajbridge to make that 
interface show on the jack graph and attach the pa bridge to that. 
Personally, I also run pactl unload-module module-jackdbus-detect to get 
rid of auto bridging and have a script that creates a named pa-jack bridge 
for each AI using lines like:
zita-a2j -j ${cname}-in -d hw:${cname} -r $RATE -p $ZFRAME -n $PERIOD &
zita-j2a -j ${cname}-out -d hw:${cname} -r $RATE -p $ZFRAME -n $PERIOD &
pactl load-module module-jack-sink client_name=PA-${cname} channels=2 connect=no
pactl load-module module-jack-source client_name=PA_${cname} channels=2 connect=no
jack_connect ${cname}-in:capture_1 PA_${cname}:front-left
jack_connect ${cname}-in:capture_2 PA_${cname}:front-right

So in pavucontrol I can see both a Jack sink (PA-M66) and a Jack sink 
(PA-PCH) and they are connected to the AI of the same name. jack_lsp -c 
shows:
PCH-in:capture_1
    PA_PCH:front-left
PCH-in:capture_2
    PA_PCH:front-right
PA-PCH:front-left
    PCH-out:playback_1
PA-PCH:front-right
    PCH-out:playback_2

for this device. (dupliactes removed) I have never had any trouble with 
pulse when doing this aside from skype (which my wife uses) which needs 
30ms or so latency to work. I suspect module-jack-sink/source could be 
fixed/hacked/polished so that desktop apps could run at a lower latency 
than jack is. (add buffering or whatever) The module-alsa-card module in 
PA obviously does something like this already to deal with more than one 
card and more than one application sending sound so it would be a matter 
of pulse treating jack as a one SR, One latency audio device.

Sorry for the long post...


> Is it possible to reinitialize the audio subsystem without rebooting ?
> Not only this will be a faster work around, but it will also make
> testing much easier.

remove the respawn from pa? then killing a pa will be permanent... sort 
of. sending any message to PA will restart it. for example running 
pavucontrol will restart PA. (if you are using KDE or other DE that 
replaces pavucontrol with something else, I would suggest installing 
pavucontrol as well. I find it easier to use that other things)


--
Len Ovens
www.ovenwerks.net