[alsa-devel] appl_ptr and DMA overrun at end of stream

[Jon Smirl]

On Thu, May 14, 2009 at 11:05 AM, Takashi Iwai <tiwai at suse.de> wrote:
> At Thu, 14 May 2009 10:25:22 -0400,
> Jon Smirl wrote:
>>
>> On Thu, May 14, 2009 at 6:39 AM, Takashi Iwai <tiwai at suse.de> wrote:
>> > At Mon, 11 May 2009 14:00:59 -0400,
>> > Jon Smirl wrote:
>> >>
>> >> On Mon, May 11, 2009 at 1:37 PM, Jaroslav Kysela <perex at perex.cz> wrote:
>> >> > On Mon, 11 May 2009, Jon Smirl wrote:
>> >> >
>> >> >> Checking for over/under run in software is not reliable since the DMA
>> >> >> hardware runs asynchronously with the CPU. There will always be
>> >> >> variable latencies between when the CPU detects the condition and when
>> >> >> it can control the DMA hardware.  The only reliable way to do this is
>> >> >> to program the DMA hardware to do itself. AFAIK all DMA modern
>> >> >> hardware can be programed to do this if the right information is made
>> >> >> available. Programming the DMA hardware to do this is a 100% reliable
>> >> >> solution and not subject to random latency problems.
>> >> >
>> >> > I comment playback for simplicity.
>> >> >
>> >> > The key point is when you fill DMA engine. Nothing forces you to queue whole
>> >> > ring buffer in the scatter-gather list. You may queue just one period and
>> >> > then next one (including partial). The available samples can be determined
>> >> > using snd_pcm_playback_hw_avail() function at any time. If you have large
>> >>
>> >> I didn't know about this function. I can use it to replace the direct
>> >> manipulation of appl_ptr.
>> >
>> > Well, this computes a value between appl_ptr and hw_ptr.  That is, it
>> > relies on the current hw_ptr value.  Just to make sure...
>> >
>> >> > FIFO and you receive interrupt before FIFO goes empty, you can fill partial
>> >> > period. The elapsed notifier does not require any change.
>> >> >
>> >> > The underruns should be avoided as first step, because it's really unwanted
>> >> > system behaviour. All methods to fix underruns fails in some respects.
>> >> >
>> >> > Also note that we have also mode when appl_ptr is not updated at all (when
>> >> > stop_threshold == boundary).
>> >>
>> >> How does this mode work? Could it be hidden inside
>> >> snd_pcm_playback_hw_avail() such that low level drivers don't have to
>> >> worry about it?
>> >
>> > Hm, no, in this case, it won't work properly.
>> > *_avail() simply tells you a bogus value, even a negative one.
>> >
>> > Basically this is a free-wheeling mode, e.g. used by dmix.
>> > In this mode, you simply ignore appl_ptr but assume that period_size
>> > samples are available at each period update.  So, this would be a
>> > different implementation.
>>
>> Free-wheeling mode is basically unreliable. Wouldn't it be better to
>> start phasing dmix out in favor of pulseaudio?
>
> That's not what developers can decide.

Sure you can. Add a deprecation notification to dmix right now that
says dmix is going to be phased out in the future. Print it in the log
once at dmix startup time. Write a blurb for LKML/LWN.net that says
dmix is being phased out in favor of pulse.  You want to do this to
stop new people from starting to use dmix.  Work with distributions to
start removing it when they feel pulse is ready.  After the major
distributions convert remove dmix from the standard alsa build
packaging.  Anything can be removed by giving sufficient notice and
providing a clear migration path.

Until you make the announcement that dmix is not the way of the
future, there is no incentive for anyone to migrate.

>
>> Why is OSS still in the kernel?
>
> Why?  It is designed so :)

Leaving old code in the kernel with no one maintaining it is worse
than removing it. Old code will slowly suffer from bit rot as the
kernel evolves. Unsuspecting people will try and use it and it will
fail in random ways. It is better to make a one year notification and
then remove it.

Don't forget that removing OSS from the kernel only effects people
going forward. People using OSS on an ancient 2.4 kernels will still
have it. You want to stop creating new OSS users.


>
>
> Takashi
>



-- 
Jon Smirl
jonsmirl at gmail.com