[alsa-devel] device underruns

Takashi Iwai tiwai at suse.de
Sun Apr 26 13:18:52 CEST 2009


At Sat, 25 Apr 2009 14:23:38 +0200,
Daniel Mack wrote:
> 
> The posting below didn't get any response yet, but the problem persists.
> Any hints, anyone?

The ALSA PCM core just relies upon two things from the lowlevel driver:

1. The lowlevel driver calls snd_pcm_period_elapsed() at each time
   when the set-up period size has been processed by the hardware.
2. The pointer callback reports the sane position as the current
   position; not below the previous position and not above the next
   period boundary.

Especially pulseaudio is very sensitive about these two things,
because it always asks the driver the current position.  Thus, if your
driver doesn't fulfill the above conditions, it won't work properly.


Takashi


> 
> Thanks,
> Daniel
> 
> On Tue, Mar 31, 2009 at 04:46:03PM +0200, Daniel Mack wrote:
> > I'm currently stress-testing my snd-usb-caiaq driver under several
> > environments and happen to see a number of such messages echoed once in
> > a while at the start of aplay (1.0.16):
> > 
> > underrun!!! (at least 1558380812.470 ms long)
> > underrun!!! (at least 1558380818.673 ms long)
> > underrun!!! (at least 1558380812.465 ms long)
> > 
> > Also, pulseaudio (0.9.14) keeps complaining with the following message
> > all over the place:
> > 
> > E: module-alsa-sink.c: ALSA woke us up to write new data to the device,                                                                                                                                   
> >    but there was actually nothing to write! Most likely this is an ALSA                                                                                                                                   
> >    driver bug. Please report this issue to the PulseAudio developers.
> > 
> > What puzzles me a bit is that I don't really know where and how the
> > driver could confuse the core so badly. All it reports is a valid
> > pointer to the current head in each substream. Is there anything else it
> > could provide for tighter syncing? Any hint how to debug this? Or maybe
> > it's not a bug in this specific driver but in the core somewhere?
> > 
> > Thanks,
> > Daniel
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 


More information about the Alsa-devel mailing list