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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
