Re: Master Plan on rewinding

[Takashi Iwai <tiwai@suse.de>]

At Mon, 15 Sep 2014 23:14:41 +0600,
Alexander E. Patrakov wrote:
> 
> 15.09.2014 23:01, Pierre-Louis Bossart wrote:
> >
> >>> What remains not fully understood for me is the claim that the
> >>> information already exposed by every driver (in the form of the minimal
> >>> period size) is not useful. I understand that two people are against
> >>> this idea, so it must be bad. But I must understand why. Is it because
> >>> the minimum period size reported by some drivers (which ones are
> >>> suspected, if any?) may be a lie?
> >>
> >> A kind of yes.  Many drivers, especially the old ones, set the minimal
> >> period size without actually knowing the real limit.  It tends to be
> >> smaller than the hardware really supports.  This is, in most cases,
> >> just because no hardware spec defines that.  So, it can't be blindly
> >> taken as the bottom line, unfortunately.  That's why I suggested the
> >> new field would be optional; we simply don't know the value.
> >
> > Agree with Takashi, even recent audio IP tend to be reused in various
> > ways (buses, system agents, arbiters, DMA controllers, DDR controllers)
> > and no one really knows what the rewind granularity is, it's not a
> > metric that's tracked.
> >
> > I actually liked the heuristic that's present in PulseAudio: constrain
> > the safeguard to 256 bytes or 1ms (the last part would actually be
> > fixed, it's currently not dependent on the sink actual rate and number
> > of channels). we could introduce an optional query drivers for this but
> > I wonder if it's worth the effort.
> 
> OK, a direct question then.
> 
> The "256 bytes or 1 ms" heuristic is known not to work on ymfpci. Should 
> we bump it to "5.3 ms or 256 samples", or make configurable, or ask the 
> ymfpci maintainer to add the INFO_BATCH flag to that driver?

Adding INFO_BATCH would be a quick solution, indeed, although this
isn't 100% right.


Takashi