end of playback ... design question

end of playback ... design question

[Knut Petersen]

Hi everybody!

Although I looked at quite a bit of source code and documentation I have
to admit that I am confused about one question:

How should alsa playback be stopped in a way that _guarantees_ that no
artifacts remaining in the drivers ringbuffer are played back again?

Let´s assume we play stereo 16bit audio data using the rme96 driver, period size set to 0x800 frames.

At the end of the penultimate frame playing will not be stopped even if there is only one frame
of audio data remaining. Obviously that means 0x7ff frames of already played data is played again
after that one valid frame, plus possibly a few that are played during the short time from interrupt request to
the real stop of the playback hardware (about 5 frames on an old Pentium-M 1.2GHz).

Now that could be fixed in different ways:

A: Always ensure that there is a bit of silence (at least hardware buffer size plus a few frames) at the end of all audio data.

      Easy for the user , but only a workaround.

B: At the rme96 driver level that condition can be detected and the relevant part of the buffer
      can be filled with zeros.

      I did that in an experimental change. It does work, but it´s definitely only a hack as it fixes
      the problem for only one device.

C: The application playing audio data could pad all audio data to the period size with zeros.

     That would prevent playback of that max 0x7ff frames of garbage, but the few samples that are played
      during the time from interrupt request to the execution of the stop trigger do escape

D: Don´t try to drain the buffer but pad with zeros and set a stop threshold.

      Workaround for applications  should also work with older kernels.

E: The alsa core could detect that condition and solve it equivalent to solution D

      I think that´s the proper solution.

Did I miss something or do you agree?

cu,
  Knut

Re: end of playback ... design question

[Jaroslav Kysela]

Date 31.7.2013 15:42, Knut Petersen wrote:
> Hi everybody!
> 
> Although I looked at quite a bit of source code and documentation I have
> to admit that I am confused about one question:
> 
> How should alsa playback be stopped in a way that _guarantees_ that no
> artifacts remaining in the drivers ringbuffer are played back again?
> 
> Let´s assume we play stereo 16bit audio data using the rme96 driver, period size set to 0x800 frames.
> 
> At the end of the penultimate frame playing will not be stopped even if there is only one frame
> of audio data remaining. Obviously that means 0x7ff frames of already played data is played again
> after that one valid frame, plus possibly a few that are played during the short time from interrupt request to
> the real stop of the playback hardware (about 5 frames on an old Pentium-M 1.2GHz).
> 
> Now that could be fixed in different ways:
> 
> A: Always ensure that there is a bit of silence (at least hardware buffer size plus a few frames) at the end of all audio data.
> 
>       Easy for the user , but only a workaround.
> 
> B: At the rme96 driver level that condition can be detected and the relevant part of the buffer
>       can be filled with zeros.
> 
>       I did that in an experimental change. It does work, but it´s definitely only a hack as it fixes
>       the problem for only one device.
> 
> C: The application playing audio data could pad all audio data to the period size with zeros.
> 
>      That would prevent playback of that max 0x7ff frames of garbage, but the few samples that are played
>       during the time from interrupt request to the execution of the stop trigger do escape
> 
> D: Don´t try to drain the buffer but pad with zeros and set a stop threshold.
> 
>       Workaround for applications  should also work with older kernels.

Applications may also silence the whole ring buffer or few periods and
rewind the actual stream position back (if possible).

> E: The alsa core could detect that condition and solve it equivalent to solution D
> 
>       I think that´s the proper solution.
> 
> Did I miss something or do you agree?

Please, see snd_pcm_sw_params_set_silence_threshold() /
snd_pcm_sw_params_set_silence_size() .

The question what to do at the end of streaming is relevant to the
question what to do when an xrun comes to an action.

These types of silence settings should be configurable. Applications
should select what's best.

						Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: end of playback ... design question

[Kai Vehmanen]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1420 bytes --]

Hi,

On Wed, 31 Jul 2013, Jaroslav Kysela wrote:

>> E: The alsa core could detect that condition and solve it equivalent to solution D
>>
>>       I think that´s the proper solution.
>>
>> Did I miss something or do you agree?
>
> Please, see snd_pcm_sw_params_set_silence_threshold() /
> snd_pcm_sw_params_set_silence_size() .

thanks Knut for investigating this.

Ecasound started to use snd_pcm_drain() fairly recently (in 2.8.0) and as 
discovered by Knut, the usage was not quite correct. Drain was run with 
same settings as normal playback (stop_threshold==buffer_size, silence 
threshold set to disabled), and this caused issues with drain as stale 
data sometimes got out at the end.

We now resolved the issue with following code (run at the end of 
playback):

  snd_pcm_sw_params_set_silence_threshold(handle, params, 0);
  snd_pcm_sw_params_set_silence_size(handle, params, boundary);
  snd_pcm_sw_params(handle, params);
  snd_pcm_drain(handle); /* in blocking mode */

... now this does what I was mistakenly assuming snd_pcm_drain() would do
implicitly.

This seems a bit complicated from API usage point of view (reconfiguring 
sw-params for drain), but OTOH is aligned with the rest of the API. As app 
has full control over sw-params, I can imagine that it would be suprising 
as well if snd_pcm_drain() would change sw_params under the hood (even if 
convenient).

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]