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
