On Thu, Dec 17, 2009 at 4:43 PM, Takashi Iwai <tiwai@xxxxxxx> 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@xxxxxxx> wrote: >> > At Thu, 17 Dec 2009 15:00:02 +0900, >> > jassisinghbrar@xxxxxxxxx wrote: >> >> >> >> From: Jassi Brar <jassi.brar@xxxxxxxxxxx> >> >> >> >> 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. If you have time, could u please confirm/correct my understanding? Thanks. >> >> An example of such situation is snd_pcm_lib_read1/write1 consuming some space >> >> of the period and going to sleep from wait_for_avail_min upon syncing with >> >> the DMA pointer. Clearly just the remainder of period size is needed, but >> >> wake_up is called only after _two_ periodic interrupts from that point. >> > >> > In that case, the original behavior is correct. >> going by current implementation, that is correct, but is that desirable? > > Correct = working as designed. > > > Takashi > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
