On 2014-04-20 21:26, Alexander E. Patrakov wrote: > 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. The moment PulseAudio needs to make a decision is when a rewind is requested. Whether or not to enable tsched should not matter in this case, unless I'm missing something. (And this is probably what Raymond is trying to say too.) Or, put in another way, why would it be better for the ALSA device to be in interrupt driven mode just because it can't rewind? // David
