On Fri, 26 Aug 2016, jonetsu@xxxxxxxxxxxx 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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
