[pulseaudio-discuss] Effects of avail_min in ALSA kernel stack

[jassi brar]

On Wed, Dec 23, 2009 at 5:02 AM, pl bossart <bossart.nospam at gmail.com> wrote:
>>    I recently submitted two patches for ALSA kernel stack that
>> will guarantee wake_ups to happen at each periodic interrupt.
>> Currently that is not the case when avail_min is greater than
>> period size.
>
> It's unclear to me why you would want to set avail_min to more than a
> period and still get a wake-up for each period.
For blocking read/writes there is unnecessary wait of one 'extra'
period before returning(see the control flow from
snd_pcm_lib_read/write1 -> wait_for_avail_min)
, clear all that is needed is 'size' amount of data while entering
wait_for_avail_min, my patches were aimed at just that:- minimize
sleep times as much as possible.

> avail_min is supposed
> to amount to the interval during which which you don't want to be
> awaken. Somehow isn't your period duration not well configured?
Yes, but not every sleep needs to be for avail_min.
snd_pcm_*_poll does need at least avail_min but not so with
snd_pcm_lib_read/write1, as I explain above.

>>  The patch doesn't seem to cause regression but might break
>> applications that depend on non-standard use of ALSA API.
>>
>> Takashi Iwai noted that PulseAudio might complain about the change
>> (not that PulseAudio use non-standard methods).
>
> PulseAudio sets avail_min to the equivalent of the sleep time (with
> timer-based scheduling) or enables period events with regular
> interrupt-based scheduling. In the latter case the value of avail_min
> shouldn't matter. Sounds like your patch would have no effect on PA.
So does it seem to me.
If anything, my patches should make blocking read/writes to take time
 not much more than that needed to playback/capture equal amount of data.

Thanks