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?