Re: Testing/forcing XRUN

["Nobin Mathew" <nobin.mathew@gmail.com>]

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
snd_pcm_substream *substream)

or
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.

Nobin

On 6/8/07, Eliot Blennerhassett <linux@audioscience.com> wrote:
> Hi,
>
> 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
> driver.
>
> 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
> streams?
>
> 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?
>
> thanks
>
> Eliot Blennerhassett
> AudioScience Inc.
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>