On 2014-09-08 10:46, Alexander E. Patrakov wrote:
08.09.2014 13:59, David Henningsson wrote:
(First of all, a big thanks for being the first to talk constructively about the important problem of rewindability classes!)
On 2014-09-07 17:16, Alexander E. Patrakov wrote:
Hello.
(TL;DR: nothing really new except the strawman proposal about threads and the note about interaction of variable sample rate with rewindability)
So, having looked this through another time, it looks like we have three categories of ALSA devices, from rewindability point of view:
Not rewindable at all.
Rewindable down to the period size.
Rewindable even further than the nearest period, down to DMA
transfer sizes or something else. This also requires the .pointer to have better granularity than the period size.
So I think any is_seekable() call or flag should indicate whether the device is case 1), 2) or 3). And for case 3) perhaps also some indicator of the actual rewind granularity and/or safeguard. This should be enough for PA to be able to pick a suitable default latency.
So far, I agree. The big question now is: do we have enough correct data from the kernel to decide between cases 2 and 3? I am definitely not qualified enough to answer this or to add such interface, though.
I'm quite certain that we don't have enough information coming through from the kernel. It's something we need to add if we end up deciding to implement hw_params_is_seekable.
Case 1) is simple. Just let snd_pcm_rewindable return 0 and snd_pcm_rewind fail. If it doesn't, just fix it. (The extplug problem could be solved by PA having ifdefs depending on alsa-lib version, rather than making snd_pcm_rewind and snd_pcm_rewindable behave inconsistent.)
OK. But I don't think that the ifdef proposal is sufficient. If I understand correctly, it only covers the "new PA on old alsa-lib" problem, because we can't add these ifdefs to old PA. That's still progress! But the "keep the old implementation of rewind" was for the opposite problem - old PA on new alsa-lib which rightfully refuses to rewind.
For case 2) you seem to suggest to emulate case 3) by using either a low-latency thread, or by increasing the number of interrupts from the hardware. Either method will inevitably increase power consumption, and the former might also increase the risk of glitches. Therefore I think this is replacing something bad with something worse, because I would value low power consumption higher than better rewinding.
There is a slight misunderstanding above. I indeed proposed (and retracted the proposal when I knew that it happens on mobile devices) to emulate case 3 in case 2 by increasing the number of interrupts from the hardware. The proposal of a low-latency background thread was about emulating case 3 on case 1, and, so far, I have not retracted it, but I may do so in the future.
Right. I guess the low-latency background thread can be used to emulate 3) on top of both 1) and 2).
This, if enabled unconditionally, indeed would lead to unnecessary power consumption increase for those applications that don't use rewinds. But for applications that want low latency or dynamic latency, there is no other way to get it, so it is wrong to talk about power consumption increase for such applications.
Uhm, is the set of applications that want "low or dynamic latency" necessarily the same as the set that want rewinds?
But that might be more of an academic question, I guess PA is the only one that does rewinds currently. Or are there more apps out there that do rewinds?
I'm not sure I buy this point completely, but I can't come up with a good counterexample either, so maybe you're right.
My argument is that, in the case of PulseAudio, these emulations would just create an unnecessary layer of complexity. PulseAudio actively wants to know the device type (via the is_seekable() call), so it is reasonable for it to also deal with consequences, without the need for additional processing in the driver or for an extra thread.
Agreed.
I understand that you have a mathematically perfect approach to this, as well as other algorithms. This would indeed be the best goal, but given an imperfect world, where we're forced to choose between
- no rewinding at all
- imperfect rewinding in the sense that it sometimes can produce
hearable artifacts
...I'm not sure 1) is always the right choice...
Should we have a snd_pcm_open (or whatever else) flag for accepting imperfect rewind results? [anyway, I would say "no" to using it in PulseAudio]
Well, if we had one, and it defaulted to the old behaviour, I suppose that would solve the new alsa-lib on old PA problem? But I'm not sure it's worth the added complexity.