Buffer underrun in a not empty playback buffer

Buffer underrun in a not empty playback buffer

[Christian Gruber]

I had a problem with an ALSA-driver, which causes an underrun in the playback stream 
before the playback buffer was completely empty (snd_pcm_avail() < playback buffer size). 
The driver developer told me, that this is correct, since for correct DMA transfer a 
minimum buffer filling level is required.

Is this an allowed ALSA-driver behaviour or does the ALSA-driver developer has to hide all 
DMA internals to the application developer so that an underrun just occurs, when the 
playback buffer is empty? If yes, how can I get to know about the required minimum buffer 
filling level before an underrun occurs?

Regards,
Christian

-- 
---------------------------------------------------------------
Dipl.-Ing. Christian Gruber
voiceINTERconnect GmbH
Ammonstraße 35
01067 Dresden
Germany

Tel.:   +49 (0) 351 - 407 526 67
Fax.:   +49 (0) 351 - 407 526 55
---------------------------------------------------------------
www.voiceinterconnect.de
... smart signal processing for electronic devices

Geschäftsführung:               Eingetragen im Handelsregister:
Dr.-Ing. Diane Hirschfeld,      Amtsgericht Dresden HRB 19466
Ludwig Linkenheil

Re: Buffer underrun in a not empty playback buffer

[Clemens Ladisch]

Christian Gruber wrote:
> I had a problem with an ALSA-driver, which causes an underrun in the
> playback stream before the playback buffer was completely empty
> (snd_pcm_avail() < playback buffer size). The driver developer told
> me, that this is correct, since for correct DMA transfer a minimum
> buffer filling level is required.

There is indeed a minimum buffer filling level.  If the device reads
data out of the buffer x bytes at a time, then you'd better make sure
that there are at least x bytes available.

> Is this an allowed ALSA-driver behaviour

This has nothing to do with the driver itself; the ALSA framework checks
for underruns.

Furthermore, the underrun does not happen before the buffer is empty;
underruns are alway detected after the fact.  It's just that your
application will never be able to read snd_pcm_avail()==0 because that
value would automatically trigger the underrun detection.

(Or does that driver, which you did not name, do additional checks?)

> how can I get to know about the required minimum buffer filling level
> before an underrun occurs?

The minimum buffer filling level _before_ an underrun is one frame.
However, to ensure that the device has enough data available, and to
protect against random scheduling delays, your application should
try to keep the buffer always as much filled as possible.

There is no function to read the device's read block size.  However, for
large block sizes, snd_pcm_hw_params_is_block_transfer() returns 1, and
the block size cannot be larger than one period.  (Quite a few embedded
devices indeed transfer entire periods.)


Regards,
Clemens

Re: Buffer underrun in a not empty playback buffer

[Christian Gruber]

Am 25.07.2012 09:01, schrieb Clemens Ladisch:
> Christian Gruber wrote:
>> I had a problem with an ALSA-driver, which causes an underrun in the
>> playback stream before the playback buffer was completely empty
>> (snd_pcm_avail() < playback buffer size). The driver developer told
>> me, that this is correct, since for correct DMA transfer a minimum
>> buffer filling level is required.
> There is indeed a minimum buffer filling level.  If the device reads
> data out of the buffer x bytes at a time, then you'd better make sure
> that there are at least x bytes available.
Ok, this is understandable and clear to me.
>
>> Is this an allowed ALSA-driver behaviour
> This has nothing to do with the driver itself; the ALSA framework checks
> for underruns.
>
> Furthermore, the underrun does not happen before the buffer is empty;
> underruns are alway detected after the fact.  It's just that your
> application will never be able to read snd_pcm_avail()==0 because that
> value would automatically trigger the underrun detection.
That's clear, too.
>
> (Or does that driver, which you did not name, do additional checks?)
The mentioned driver is an ALSA-driver, which was originally developed by Texas 
Instruments for their Audio-Codec family TLV320AIC3x, but was adapted to a specific 
customer board.
>
>> how can I get to know about the required minimum buffer filling level
>> before an underrun occurs?
> The minimum buffer filling level _before_ an underrun is one frame.
> However, to ensure that the device has enough data available, and to
> protect against random scheduling delays, your application should
> try to keep the buffer always as much filled as possible.
>
> There is no function to read the device's read block size.  However, for
> large block sizes, snd_pcm_hw_params_is_block_transfer() returns 1, and
> the block size cannot be larger than one period.  (Quite a few embedded
> devices indeed transfer entire periods.)
You are right, I did not refer to the frame size and the period size. But the behaviour of 
the mentioned driver is, that an underrun occurs, even when there are lots of periods (> 6 
periods) inside the playback buffer. And this is not correct, isn't it?
>
>
> Regards,
> Clemens


-- 
---------------------------------------------------------------
Dipl.-Ing. Christian Gruber
voiceINTERconnect GmbH
Ammonstraße 35
01067 Dresden
Germany

Tel.:   +49 (0) 351 - 407 526 67
Fax.:   +49 (0) 351 - 407 526 55
---------------------------------------------------------------
www.voiceinterconnect.de
... smart signal processing for electronic devices

Geschäftsführung:               Eingetragen im Handelsregister:
Dr.-Ing. Diane Hirschfeld,      Amtsgericht Dresden HRB 19466
Ludwig Linkenheil

Re: Buffer underrun in a not empty playback buffer

[Clemens Ladisch]

Christian Gruber wrote:
> Am 25.07.2012 09:01, schrieb Clemens Ladisch:
>> (Or does that driver, which you did not name, do additional checks?)
>
> The mentioned driver is an ALSA-driver, which was originally developed
> by Texas Instruments for their Audio-Codec family TLV320AIC3x, but was
> adapted to a specific customer board.

The TLV320AIC3x are I²S codecs.  DMA and buffering are done by the
controller, which is managed by the platform driver.

> But the behaviour of the mentioned driver is, that an underrun occurs,
> even when there are lots of periods (> 6 periods) inside the playback
> buffer. And this is not correct, isn't it?

This is indeed not correct (if there isn't much time between reading
the buffer fill level and the underrun).

It's likely that the platform driver does not report the buffer position
correctly.


Regards,
Clemens