[alsa-devel] Driver code with mpc5200 pointer problem.

[Takashi Iwai]

At Tue, 28 Apr 2009 11:56:20 +0200 (CEST),
Jaroslav Kysela wrote:
> 
> On Tue, 28 Apr 2009, Takashi Iwai wrote:
> 
> >> - leave current fifo_size without change (there will be only small FIFO
> >>    values to notify applications about small extra delays before samples
> >>    reaches DAC or leaves ADC)
> >
> > fifo_size field is supposed to be constant, and shouldn't be changed
> > dynamically after open.  This is a problem if the FIFO size varies
> > depending on the parameter.
> 
> The alsa-lib's documentation states that one configuration must be chosen 
> (thus hw_params should be called) to obtain fifo_size. It might depend on 
> hardware parameters, but is static then. I would not propose to change 
> anything with it.

Good.

> >> - add cache_size value to snd_pcm_hardware struct - here will be
> >>    stored area of buffer which might be cached in the hardware for large
> >>    FIFOs including prepared USB's URBs (the upper layer should not work
> >>    with this buffer area - rewind operation etc.)
> >
> > I already submitted a similar patch quite ago.  Actually, it exposes
> > the delay account in snd_pcm_status() delay calculation.  The delay
> > value can be dynamically changed.
> >
> > The current test patches are found on sound unstable tree
> > topic/pcm-delay branch.
> >  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git
> 
> Looks good. Could you pick these patches to your stable tree so we can 
> stack other patches on top? I need to add 'delay' to hdelta in current 
> elapsed callback to avoid false alarms.
> 
> Also, John should initialize this runtime->delay to correct value in 
> frames in the mpc driver.

Well, I think it'd be better, at this moment for 2.6.30, to allow
problematic drivers to skip the jiffies check.  Adding the fundamental
change at this late stage is bad, especially if the change wasn't
tested much by many others and has an influence on user-side API.

So, as I proposed, we can simply add the pcm info check, and add
BATCH flag to needed drivers.  Of course, it still requires some
more testing, but basically it'll take back to the old behavior and
should be safer.

Meanwhile, applying the delay account patch now for 2.6.31 should be
good (ealier is better).  It doesn't conflict with the info flag
check, so we can work parallel.


Takashi