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
