[alsa-devel] Misusing snd_pcm_avail_update()

[Takashi Iwai]

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