On Fri, 23.01.09 18:56, Clemens Ladisch (clemens@ladisch.de) wrote:
Takashi Iwai wrote:
[...] My main concern is what kernel <-> user API is needed in addition or needed to be changed.
If it's a question how to pass the granularity to user-space, usually it's a constant value, and thus it can be put somewhere in the existing struct, or add a single ioctl.
Most PCI devices have 32 bytes; wavetable chips have a constant time (5.33 ms, i.e., resampled to 256 framesat 48 kHz). But the interesting cases are where the granularity is dependent on the period size, or where the application could choose some arbitrary value (USB). For these cases, it would be very useful to have the granularity as an interval in the PCM hardware parameters (or probably three: bytes/ frames/time).
In the case of granularity==period, this allows PulseAudio to detect that it has to work with small periods after it has set a small upper bound for the granularity. (This is exactly what the hw_param dependencies were designed for.)
OTOH, if it has to be implemented as a form of snd_pcm_busy_for(), the kernel needs the compuation like the above. That's my concern.
Instead of writing a callback in the USB driver to compute the time until the next underrun, I'd rather rip out that fast start code. So, no kernel computation is needed. :-)
While I think it would be good not have this kind of double-buffering I wonder if this is really future-proof. i.e. can this done with every driver that uses 'fast starts'?
Anyway, regardless of how the API looks, I see two compatibility concerns:
- For many devices (legacy ISA, etc.), we just don't know the correct value.
But it should be possible to pick a safe boundary, shouldn't it?
- What should alsa-lib do when it runs on an old kernel? It could return a worst-case estimate (period size), but this would cause PA to use small periods. Perhaps it would be better to return some error ("don't know").
If we'd do it the the busy_for() API we could simply return buffer_size - avail_update() - extra_margin. Or simply return ENOSUPP. That would be fine too.
Lennart