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