On Tue, 22 Jan 2019 18:16:52 +0100, Timothy Pearson wrote: > > On 01/22/2019 11:13 AM, Takashi Iwai wrote: > > On Mon, 21 Jan 2019 22:38:19 +0100, > > Timothy Pearson wrote: > >> > >> On 01/20/2019 07:00 PM, Timothy Pearson wrote: > >>> I've been running a dedicated machine with ALSA loopback, feeding > >>> darkice on the capture side and (currently) using mplayer to provide > >>> audio on the playback side. I've seen sporadic hangs for a couple of > >>> years on this setup, but recently with the switch to mplayer I have > >>> additional information that points more to ALSA than the other applications. > >>> > >>> When the audio hangs, mplayer prints a continuous stream of: > >>> "Audio device got stuck!" > >>> > >>> The only way to "unstick" the audio stream is to terminate and restart > >>> mplayer. Restarting darkice does not fix the stuck stream. There is no > >>> pulseaudio on this sytem. > >>> > >>> What would be the next steps to debug this setup? It's shown up on two > >>> entirely different installs at this point (Ubuntu 14.04 and Debian 9). > >>> > >>> Thanks! > >> > >> A bit of additional information: before audio output ceases entirely, > >> the messages start printing and the audio becomes very choppy. The > >> system has no processes stuck at 100% CPU or any other visible signs of > >> duress during this time. > >> > >> Suggestions on debug are welcome! > > > > The whole story above indicates merely a message like infamous TeX > > error, "something is wrong" :) We need more detailed information. > > That's what I had guessed, but I am not familiar enough with the ALSA > stack to know what would be useful for debugging or how to get it. The > loopback module is in kernel, which makes debug even more fun. > > I recently determined that the capture end of the loopback device > (darkice) reports "Buffer overrun". Given that, my next question > becomes what happens if capture stops / stalls on an ALSA loopback > device? Is this expected to be recoverable without restarting both ends > of the loopback (playback and capture) or am I asking ALSA to do > something it isn't designed to do? If it's about buffer overrun (or underrun for playback), more often it's an application-side problem that doesn't recover the stream properly. > > For example, how is the PCM status of each running PCM stream when > > this happens? Also, track where the application gets stuck, what was > > expected but what didn't happen. You can see it via gdb or whatever. > > How would I get the PCM status? You can check it in /proc/asound/card*/pcm*/.... If the stream gets stuck as XRUN state, it implies that the application didn't treat it right. HTH, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
