Debugging dmix?
Mark Hills
mark at xwax.org
Wed Apr 15 16:22:10 CEST 2020
Recommendations for debugging dmix?
For a long time I have a problem where audio output regresses to glitches,
only solved by closing all applications using audio and reopening.
Especially common when Chromium is used: 3-4 times a day, frustrating.
I have a very explicit dmix configuration (see below); no PulseAudio.
Reproducable on latest alsa-lib (fb48ad9e; later than v1.2.2)
I can rule out _some_ aspects of hardware/drivers (Layla3G); eg. when the
fault occurs, other soundcard channels are fine.
Any way to understand what dmix is doing? Clients? Control process?
Here's a recording taken from the analogue output (L+R chanel get zero'd):
http://www.pogo.org.uk/~mark/tmp/dmix-glitch.png
http://www.pogo.org.uk/~mark/tmp/dmix-glitch.flac
Some process overwriting the ring buffer? Not high enough thread priority?
Seems like it might be more prevalant with more applications using sound.
Maybe why Chromium makes it worse; several threads/sandboxes, perhaps.
dmix has all the trappings of something fiendishly clever and concise, but
quite opaque. I'd need time to study the code (it has few comments, a lot
of assumed knowledge) to understand its IPC. Can anyone give a head start?
Specifically, how does the final mix get written to the output? eg. Thread
priorities, if that process goes away etc.
Thanks
---
pcm.layla_multi {
type route
slave.pcm {
type dmix
ipc_key 833282
ipc_key_add_uid true
slave {
pcm "hw:Layla3G,0,0"
period_size 256
buffer_size 32768
channels 4
rate 48000
format S24_3LE
}
}
ttable {
# Headphones
0.0 1
1.1 1
# Speakers
0.2 1
1.3 1
}
}
pcm.!default {
type plug
slave.pcm layla_multi
}
--
Mark
More information about the Alsa-devel
mailing list