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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
