On 2014-04-21 09:04, Alexander E. Patrakov wrote:
21.04.2014 07:49, David Henningsson wrote:
On 2014-04-20 21:26, Alexander E. Patrakov wrote:
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.
No. The decision definitely needs to be at the device-open time.
Otherwise this will happen:
"""
Now I need to rewind in order to accommodate a new low-latency client.
Oops, I can't, and I have so much wrong data in my hardware buffer! I
should not have created such a big buffer, but now it too late to change
anything.
"""
So you want to always go low-latency (and high CPU/power consumption),
in case rewind is not possible?
This sounds like a trade-off.
The other possibility would be to just wait until the hw buffer is empty
and then continue with low latency. If "accomodate a new low latency
client" happens rarely, and the maximum buffer size is < 2 seconds, then
maybe this is not much of an issue, compared to the drawback of forcing
low latency when it's not needed.
And indeed, the current code already has logic to choose different
buffer sizes for tstamp and irq-driven modes:
http://cgit.freedesktop.org/pulseaudio/pulseaudio/tree/src/modules/alsa/alsa-util.c#n298
On my hardware, the buffer sizes for these two modes differ by a factor
of 1000.
What hardware is that? If we don't do that already, we should cap the
tsched buffer size to ~ 2 seconds, or we'll just use more memory than we
need. Divide that with 1000 and you claim to have a irq-driven buffer
size of 2 ms. Which is way too low.
So what I want is really not related to tsched. "Don't choose a big
buffer size and high latency, and don't try to rewind, if we know in
advance that ALSA cannot rewind or only pretends to be able to rewind"
would be a better description of my patch.
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?
I have two slightly-conflicting answers to this.
First answer:
Rewinds and timestamp-driven scheduling are only the means to get
dynamically reconfigurable latency, which is useful for less dropouts
when there are no low-latency clients, lower power usage, and possibly
other good things. Due to the inability to do rewinds, the "dynamic
client-driven latency" goal becomes unachievable, so there is simply no
good point to use timestamp-based scheduling in this case.
Of course timestamp-based scheduling will work without rewinds, but, as
PulseAudio would then need (due to inability to do rewinds) to lock into
the constant minimum latency, the wakeup points will be evenly spaced in
time. And that's almost equivalent to the IRQ-based scheduling (with a
small exception listed in the second answer).
Or to put it another way. Currently, PulseAudio supports two models:
"big buffer + timestamp-based scheduling + rewinds" and "small buffer +
IRQ-driven scheduling + no rewinds". Intermediate models such as "small
buffer + timestamp-based scheduling + no rewinds" are possible, but they
would IMHO only unnecessarily inflate the test matrix.
Eh? Rewinds are not disabled under IRQ-driven scheduling.
Second answer:
Well, it is not better. In timestamp-based scheduling mode, we can
dynamically adjust latency. The limitation is that, without rewinds, our
decisions to reduce latency (e.g. due to a new client) would apply too
late. But even with this limitation, it means that we can try to keep as
low latency as it actually works on the given hardware (similar to the
current watermark logic), disregarding any client-specified latency.
The problem is that, if one wants to use timestamp-based scheduling
without rewinds, one needs to decouple the current watermark logic, the
buffer size choice logic, and the "don't use latency lower than
requested by any client" logic, because the later only makes sense when
rewinds are possible.
I think we can still dynamically switch latency even without rewinds.
It'll just take slightly longer to start new streams.
Anyway, here's another idea:
During PulseAudio's first five seconds, all streams are running as some
kind of "startup test". How about we use that to probe the rewind too?
And if snd_pcm_rewindable says we can't rewind even with a full buffer,
then we choose a medium latency as our highest latency, e g 150 - 200
ms, instead of the 2 seconds?
// David
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
