Re: Misusing snd_pcm_avail_update()

[Clemens Ladisch <clemens@ladisch.de>]

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.  :-)


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.
* 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").


Best regards,
Clemens