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
