At Tue, 22 Dec 2009 16:34:32 +0900, jassi brar wrote:
On Mon, Dec 21, 2009 at 8:28 PM, Takashi Iwai tiwai@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@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@suse.de wrote:
At Thu, 17 Dec 2009 15:00:02 +0900, jassisinghbrar@gmail.com wrote: > > From: Jassi Brar jassi.brar@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...
Takashi