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