[alsa-devel] Testing/forcing XRUN
nobin.mathew at gmail.com
Fri Jun 8 09:19:32 CEST 2007
This will be OK to test XRUN condition in driver.
XRUN will be reported in either of these functions
static inline int snd_pcm_update_hw_ptr_interrupt(struct
static inline int snd_pcm_update_hw_ptr_post(struct snd_pcm_substream
*substream, struct snd_pcm_runtime *runtime)
or you can put some Debug logs in
static void xrun(struct snd_pcm_substream *substream)
All these functions are in sound/core/pcm_lib.c
When we stop the application by issuing Ctrl-Z then onwards
application will not write/read data from device. So driver will go to
XRUN state, when driver detects XRUN it stops the substream by calling
snd_pcm_stop() (inside xrun()). But application cannot detect this
because he is not active. But when we activate application (fg) then
it detects -EPIPE (stopped substream), then application prepare it
snd_pcm_prepare() and starts the playback(substream) again.
On 6/8/07, Eliot Blennerhassett <linux at audioscience.com> wrote:
> I want to test my driver behaviour when an xrun happens.
> I have tried using aplay/arecord, and suspending (ctrl-Z) them while
> playing/recording but this doesn't have the desired effect. (I don't see my
> driver code detecting an xrun). Instead I see a trigger-stop command to the
> The apps do report an overrun when they are restarted though.
> Can anyone answer these:
> 1) Is this a valid way to simulate an xrun due to application not keeping up?
> 1.1) If not, what is? Do I have to write an app that deliberately starves the
> 2) Where is the xrun being detected if my driver doesnt see it? Where does
> the trigger-stop command come from when I suspend the app?
> Eliot Blennerhassett
> AudioScience Inc.
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
More information about the Alsa-devel