[alsa-devel] [PATCH 1/2] ALSA: pcm - Ensure wakeup at each periodic interrupt

[jassi brar]

On Tue, Dec 22, 2009 at 4:50 PM, Takashi Iwai <tiwai at suse.de> wrote:
> At Tue, 22 Dec 2009 16:34:32 +0900,
> jassi brar wrote:
>>
>> On Mon, Dec 21, 2009 at 8:28 PM, Takashi Iwai <tiwai at suse.de> wrote:
>> > At Thu, 17 Dec 2009 17:21:28 +0900,
>> > jassi brar wrote:
>> >>
>> >> On Thu, Dec 17, 2009 at 4:43 PM, Takashi Iwai <tiwai at suse.de> wrote:
>> >> > At Thu, 17 Dec 2009 16:31:08 +0900,
>> >> > jassi brar wrote:
>> >> >>
>> >> >> On Thu, Dec 17, 2009 at 4:02 PM, Takashi Iwai <tiwai at suse.de> wrote:
>> >> >> > At Thu, 17 Dec 2009 15:00:02 +0900,
>> >> >> > jassisinghbrar at gmail.com wrote:
>> >> >> >>
>> >> >> >> From: Jassi Brar <jassi.brar at samsung.com>
>> >> >> >>
>> >> >> >> The check for at least 'avail_min' available data before calling wake_up
>> >> >> >> doesn't always hold good as it does not guarantee callbacks at each periodic
>> >> >> >> interrupt.
>> >> >> >
>> >> >> > Well, avail_min can be greater than period_size.  And, avail_min won't be
>> >> >> > less than period size.
>> >> >> >
>> >> >> > For example, when avail_min = 2.5 x period_size, the driver wakes up
>> >> >> > in periods like 3, 2, 3, 2, ...
>> >> >> correct, but if we ensure wake_up's after each period and let the 'sleepers'
>> >> >> track if the data available is enough or not, we will have more fine grained
>> >> >> control.
>> >> >> The point is:- Waking up _after_ avail_min is working, but does waking up before
>> >> >> avail_min(but at period boundary) break the system?
>> >> >
>> >> > PulseAudio may complain :)
>> >> I meant effects on ALSA state-machine within the kernel.
>> >> >From what i have seen, every use of sleep is just to kill some time,
>> >> i.e, wake_up
>> >> is not taken as indication of completion of the purpose.
>> >
>> > It's used also for poll.
>> >
>> > Meanwhile, we may change snd_pcm_*_poll() function itself, too...
>> How about employing a new snd_pcm_runtime member (say, need_min) which
>> denote the _exact_ minimum amount of data needed to serve purpose
>> of last sleep ?
>>
>> Quick idea of what i mean, follows. If you like it, i will resend the
>> patches again
>> Thanks.
>
> Well, I don't know.  This clearly changes the semantics of avail_min
> in the write case.  That is, this leads to slight incompatibilities.
> Whether such a difference is acceptable on all possible situations is
> another question...
I think, only applications, that don't call snd_pcm_wait() before
blocking writes
 _and_ count upon the blocking times of such writes, may be affected.
Clearly not a serious crime against such apps.

Regards.