Re: Master Plan on rewinding

["Alexander E. Patrakov" <patrakov@gmail.com>]

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?

-- 
Alexander E. Patrakov