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

Takashi Iwai tiwai at suse.de
Mon Dec 21 12:28:03 CET 2009


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...


Takashi


More information about the Alsa-devel mailing list