[alsa-devel] Possible ALSA loopback bug?

[Timothy Pearson]

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?

> 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?

> 
> thanks,
> 
> Takashi


-- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com