[pulseaudio-discuss] [PATCH] Don't use tsched on unsafe ALSA plugins

[Alexander E. Patrakov]

20.04.2014 20:44, David Henningsson wrote:
> In addition, there is a snd_pcm_rewindable function, but we don't use
> it, and I don't know how well the different ALSA pcm types work with it.
> But it seems to me like the best course of action could be to make sure
> it reports the correct value for all ALSA pcm types, and then for
> PulseAudio to start using it?

The idea to use this function would not work even on a hypothetical 100% 
non-buggy version of ALSA. So we need a different function. And here is why.

PulseAudio needs to know whether to enable time-based scheduling right 
after opening the PCM and setting hardware parameters. However, at that 
point, even for a true hardware device, snd_pcm_rewindable() would 
rightfully return 0. In fact, it does so today. The reason is that at 
this moment the hardware pointer and the application pointer are the 
same and point just before the first sample in the hardware buffer. In 
other words, the card is just at the underrun boundary and no safe 
rewind is possible.

Thus, it is not possible to tell the hardware device (that can use 
rewinds) from a properly wrapped software encoder (that can't rewind and 
doesn't pretend to be able to rewind), because for both cases 
snd_pcm_rewindable() would return 0 at the moment PulseAudio needs to 
make a decision.

Thus, I take back my prior statement that I will try fixing 
snd_pcm_rewindable, until further discussion. A task that has higher 
priority is to develop a suitable API that would allow PulseAudio to 
make a decision, and also to decide what to do on old ALSA versions.

In fact, I think that there are two bits of theoretical interest here, 
of which the second one is the only one interesting to PulseAudio.

  * Whether the device supports non-zero-sized rewinds at all, in the 
sense that rewinding and rewriting different data yields the same sound 
as if there were no rewinds.

  * Whether the device supports full rewinds back to the hardware 
pointer, in the same sense.

-- 
Alexander E. Patrakov