From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Possible ALSA loopback bug? Date: Tue, 22 Jan 2019 18:21:23 +0100 Message-ID: References: <5C4519A3.2050200@raptorengineering.com> <5C463BCB.2030907@raptorengineering.com> <5C475004.4010106@raptorengineering.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 1B7DD2674B9 for ; Tue, 22 Jan 2019 18:21:24 +0100 (CET) In-Reply-To: <5C475004.4010106@raptorengineering.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Timothy Pearson Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org 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