At Thu, 17 Dec 2009 17:21:28 +0900, jassi brar wrote: > > 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. It's used also for poll. Meanwhile, we may change snd_pcm_*_poll() function itself, too... Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
