At Fri, 23 Jan 2009 18:56:38 +0100, Clemens Ladisch 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).
Right. I noticed it when I wrote a patch for snd_pcm_delay() extension for usb-audio device.
Contradicting to my previous comment, but the variable granularity is one thing we can consider. But, it may be dependent how accurate it must be. If snd_pcm_busy_for() should return the maximal safe sleep time, then a constant value would work well.
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.)
Hm, this reminds me that a granularity isn't only what hardware provides but also what app can request, directly or indirectly. It's a good point. On some hardwares, you can't abandon the small period size if you want a smaller granularity.
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. :-)
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.
Right. But for these we can assume granularity=1 unless someone detects the breakage.
- 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").
I think returning undefined is a better choice.
thanks,
Takashi