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:
- 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?
- 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