XRUN handling

XRUN handling

[melwyn lobo]

Hi all,
I have noticed when an Xrun occurs, the bytes between the hw_ptr and
appl_ptr are not copied when both hw and appl pointers are reset in
snd_pcm_prepare().
Consider the following parameters:
  buffer_size  : 22352
  period_size  : 1016
  period_time  : 23038
  tstamp_mode  : NONE
  period_step  : 1
  avail_min    : 1016
  period_event : 0
  start_threshold  : 22352
  stop_threshold   : 22352
  silence_threshold: 0
  silence_size : 0

In case snd_pcm_playback_avail() is less than stop threshold but
greater than 0, then these bytes are missing after Xrun prepare and
start stage.

Is my analysis correct? If so how do we ensure correct behaviour ie
byte accuracy after Xrun.

Thanks,
M.

Re: XRUN handling

[Clemens Ladisch]

melwyn lobo wrote:
> In case snd_pcm_playback_avail() is less than stop threshold but
> greater than 0, then these bytes are missing after Xrun prepare and
> start stage.

Preparing a stream resets it, i.e., any data currently in the buffer
is discarded.

If you want to have data in the buffer after preparing, you have to
write it again.


Regards,
Clemens

Re: XRUN handling

[melwyn lobo]

Adding mailing list to copy:

- Hide quoted text -
> melwyn lobo wrote:
>> In case snd_pcm_playback_avail() is less than stop threshold but
>> greater than 0, then these bytes are missing after Xrun prepare and
>> start stage.
>
> Preparing a stream resets it, i.e., any data currently in the buffer
> is discarded.
>
> If you want to have data in the buffer after preparing, you have to
> write it again.
>


Thanks for the confirmation. Our client is working on aplay to test
our driver in which already there is this issue.
Is there any workaround in kernel/driver space that could be done or
it can only be fixed in aplay.

Regards
M.

Re: XRUN handling

[Clemens Ladisch]

melwyn lobo wrote:
>> melwyn lobo wrote:
>>> In case snd_pcm_playback_avail() is less than stop threshold but
>>> greater than 0, then these bytes are missing after Xrun prepare and
>>> start stage.
>>
>> Preparing a stream resets it, i.e., any data currently in the buffer
>> is discarded.
>>
>> If you want to have data in the buffer after preparing, you have to
>> write it again.
> 
> Thanks for the confirmation. Our client is working on aplay to test
> our driver in which already there is this issue.
> Is there any workaround in kernel/driver space that could be done

When the ALSA framework tells the driver to stop, and then resets the
pointers, the driver cannot avoid doing this.


Applications have two choices how xruns are to be handled:
1) Stop the stream; the application must then reset the stream (by
   preparing it).  This mode is selected by using a stop_threshold that
   is lower than the buffer_size.  This is the default mode.
2) Continue playing.  The device will play old data from the ring
   buffer, until the application has caught up and written new data
   to the buffer.  This mode is selected by setting stop_threshold to
   the boundary value.


Regards,
Clemens

Re: XRUN handling

[James Courtier-Dutton]

On 6 July 2010 06:03, melwyn lobo <linux.melwyn@gmail.com> wrote:
> Hi all,
> I have noticed when an Xrun occurs, the bytes between the hw_ptr and
> appl_ptr are not copied when both hw and appl pointers are reset in
> snd_pcm_prepare().
>
> Is my analysis correct? If so how do we ensure correct behaviour ie
> byte accuracy after Xrun.
>

When an Xrun occurs, all bets are off. You should reset the sound card
buffers and start again.
The best thing to do is try to track down why the Xrun occurs in the
first place and stop it happening.
It most likely occurs because some other device is keeping the CPU
from servicing the interrupt correctly.
Normally graphics card drivers, hard disk drivers or file system code
causes this problem.
Look at low latency and real time patches for the Linux kernel.

Kind Regards

James

Re: XRUN handling

[melwyn lobo]

On Tue, Jul 6, 2010 at 9:46 PM, James Courtier-Dutton
<james.dutton@gmail.com> wrote:
> On 6 July 2010 06:03, melwyn lobo <linux.melwyn@gmail.com> wrote:
>> Hi all,
>> I have noticed when an Xrun occurs, the bytes between the hw_ptr and
>> appl_ptr are not copied when both hw and appl pointers are reset in
>> snd_pcm_prepare().
>>
>> Is my analysis correct? If so how do we ensure correct behaviour ie
>> byte accuracy after Xrun.
>>
>
> When an Xrun occurs, all bets are off. You should reset the sound card
> buffers and start again.
> The best thing to do is try to track down why the Xrun occurs in the
> first place and stop it happening.
> It most likely occurs because some other device is keeping the CPU
> from servicing the interrupt correctly.
> Normally graphics card drivers, hard disk drivers or file system code
> causes this problem.
Thanks James.
We would not like to change the core vanilla kernel available as is
from kernel.org
apart from adding our own platform software of course.
For software robustness, we need to ensure that even after an XRUN
no data is missed.

> Look at low latency and real time patches for the Linux kernel.
>
> Kind Regards
>
> James
>

Thanks Clemens,

>When the ALSA framework tells the driver to stop, and then resets the
>pointers, the driver cannot avoid doing this.
>
>
>Applications have two choices how xruns are to be handled:
>1) Stop the stream; the application must then reset the stream (by
> reparing it).  This mode is selected by using a stop_threshold that
>  is lower than the buffer_size.  This is the default mode.
>2) Continue playing.  The device will play old data from the ring
>  buffer, until the application has caught up and written new data
>  to the buffer.  This mode is selected by setting stop_threshold to
>  the boundary value.
>
>
>Regards,
>Clemens

I have already done the above and issues are as under:
1. Stopping the stream after stop_threshold does ensure that garbage data is not
played, but, as said earlier, the remaining bytes within the buffer
are discarded
by the application. Not acceptable for us (assuming we use only standard aplay)
2. Continuing to run the the ring buffer produces garbage which can be
done away with by using silence_size and silence_threshold. And if the
application still does not get processor time for some reason, the
hw_ptr will overrun the appl_ptr by more than buffer_size and trigger
a bug in snd_pcm_playback_silence().

I am using 2.6.32.8. Are there any patches for xrun handling between
this and the latest versions of the kernel that I could use.

Regards
M.

Re: XRUN handling

[Jaroslav Kysela]

On Tue, 6 Jul 2010, melwyn lobo wrote:

> done away with by using silence_size and silence_threshold. And if the
> application still does not get processor time for some reason, the
> hw_ptr will overrun the appl_ptr by more than buffer_size and trigger
> a bug in snd_pcm_playback_silence().

Could you fix (send us a patch) or describe exactly this problem?

 					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: XRUN handling

[James Courtier-Dutton]

On 6 July 2010 18:46, melwyn lobo <linux.melwyn@gmail.com> wrote:
> For software robustness, we need to ensure that even after an XRUN
> no data is missed.
>
Not possible. You can recover from the XRUN state but you will never
reach "no data is missed".

Re: XRUN handling

[melwyn lobo]

On Wed, Jul 7, 2010 at 12:09 AM, Jaroslav Kysela <perex@perex.cz> wrote:
> On Tue, 6 Jul 2010, melwyn lobo wrote:
>
>> done away with by using silence_size and silence_threshold. And if the
>> application still does not get processor time for some reason, the
>> hw_ptr will overrun the appl_ptr by more than buffer_size and trigger
>> a bug in snd_pcm_playback_silence().
>
> Could you fix (send us a patch) or describe exactly this problem?

Yes. It occurs in a loaded system. The hardware runs continously and
eventually underruns (stop_threshold trigger does not
occur because of its large value).
Eventually due to silence_threshold, silence_size setting,
snd_pcm_playback_silence() attempts to continously append
silence.
The function snd_pcm_playback_hw_avail(runtime) returns negative
values. Now consider the code fragment;
noise_dist = snd_pcm_playback_hw_avail(runtime) + runtime->silence_filled;

                if (noise_dist >= (snd_pcm_sframes_t)
runtime->silence_threshold)
                        return;
                frames = runtime->silence_threshold - noise_dist;

which makes at some point frames > runtime->buffer_size and triggers

  if (snd_BUG_ON(frames > runtime->buffer_size))
                return;

This is my analysis as I can see the above statement getting executed.
For this, the solution implemented in the driver, is to eventually
stop the infinite DMA when appl_ptr <= hw_ptr.
>
>                                        Jaroslav
>
> -----
> Jaroslav Kysela <perex@perex.cz>
> Linux Kernel Sound Maintainer
> ALSA Project, Red Hat, Inc.
>
>

Regards,
M.
Regards,
M.

Re: XRUN handling

[melwyn lobo]

Another query, if setting runtime parameters like:
runtime->silence_threshold = runtime->boundary;
runtime->silence_size = runtime->boundary;
runtime->stop_threshold = runtime->boundary;

Also to avoid the bug in snd_pcm_playback_silence()  i.e.,
snd_BUG_ON(frames > runtime->buffer_size),
I have added a tweak in the driver IRQ handler:

              if(substream->stream == SNDRV_PCM_STREAM_PLAYBACK
                                    &&
snd_pcm_playback_hw_avail(runtime) == 0) {

                        /* Hardware is continously running so it is
                         * playing silence so that should be OK.
                         * And we played all valid samples, so no data
                         * is lost. Not stopping intentionally
                         */

                          runtime->control->appl_ptr += runtime->period_size;
                        if(runtime->control->appl_ptr >= runtime->boundary)
                                runtime->control->appl_ptr -= runtime->boundary;

                        offset = runtime->control->appl_ptr -
runtime->silence_start;
                        if (offset < 0)
                                offset += runtime->boundary;
                        if ((snd_pcm_uframes_t)offset < runtime->silence_filled)
                                runtime->silence_filled -= offset;
                        else
                                runtime->silence_filled = 0;

                        runtime->silence_start = runtime->control->appl_ptr;

This avoids the bug above, but aplay does not stop after reading all
the samples from the file. It plays silence infinitely.
Should not this condition be detected by the aplay and stop the stream
when EOF on the file happens.

Regards,
M.

Re: XRUN handling

[Jaroslav Kysela]

On Wed, 14 Jul 2010, melwyn lobo wrote:

> Another query, if setting runtime parameters like:
> runtime->silence_threshold = runtime->boundary;
> runtime->silence_size = runtime->boundary;
> runtime->stop_threshold = runtime->boundary;
>
> Also to avoid the bug in snd_pcm_playback_silence()  i.e.,
> snd_BUG_ON(frames > runtime->buffer_size),
> I have added a tweak in the driver IRQ handler:

This patch might fix this problem:

diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c
index bcf95d3..e23e0e7 100644
--- a/sound/core/pcm_lib.c
+++ b/sound/core/pcm_lib.c
@@ -67,6 +67,8 @@ void snd_pcm_playback_silence(struct snd_pcm_substream *substream, snd_pcm_ufram
  	} else {
  		if (new_hw_ptr == ULONG_MAX) {	/* initialization */
  			snd_pcm_sframes_t avail = snd_pcm_playback_hw_avail(runtime);
+			if (avail > runtime->buffer_size)
+				avail = runtime->buffer_size;
  			runtime->silence_filled = avail > 0 ? avail : 0;
  			runtime->silence_start = (runtime->status->hw_ptr +
  						  runtime->silence_filled) %

But it looks that you do something wrong with hw_ptr or appl_ptr in your 
driver, because this condition would be true only when an large underrun 
occurs immediatelly.

 					Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: XRUN handling

[Jaroslav Kysela]

On Mon, 19 Jul 2010, Jaroslav Kysela wrote:

> On Wed, 14 Jul 2010, melwyn lobo wrote:
>
>> Another query, if setting runtime parameters like:
>> runtime->silence_threshold = runtime->boundary;
>> runtime->silence_size = runtime->boundary;
>> runtime->stop_threshold = runtime->boundary;
>>
>> Also to avoid the bug in snd_pcm_playback_silence()  i.e.,
>> snd_BUG_ON(frames > runtime->buffer_size),
>> I have added a tweak in the driver IRQ handler:
>
> This patch might fix this problem:
>
> diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c
> index bcf95d3..e23e0e7 100644
> --- a/sound/core/pcm_lib.c
> +++ b/sound/core/pcm_lib.c
> @@ -67,6 +67,8 @@ void snd_pcm_playback_silence(struct snd_pcm_substream *substream, snd_pcm_ufram
>  	} else {
>  		if (new_hw_ptr == ULONG_MAX) {	/* initialization */
>  			snd_pcm_sframes_t avail = snd_pcm_playback_hw_avail(runtime);
> +			if (avail > runtime->buffer_size)
> +				avail = runtime->buffer_size;
>  			runtime->silence_filled = avail > 0 ? avail : 0;
>  			runtime->silence_start = (runtime->status->hw_ptr +
>  						  runtime->silence_filled) %
>
> But it looks that you do something wrong with hw_ptr or appl_ptr in your
> driver, because this condition would be true only when an large underrun
> occurs immediatelly.

Not underrun but overfill (but this should not occur - the PCM core 
functions check for this). Could you print appl_ptr, hw_ptr and 
buffer_size before you call snd_pcm_elapsed()?

 						Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.