08.09.2014 15:26, David Henningsson wrote:
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.
OK, but, given that we need this interface in order to avoid seeking on the DTS encoder (and to avoid creating a big buffer on it), I'd rather have this sooner than later. As a compromise, let's design the API with case 2 in mind, but only return cases 1 and 3 until we have enough information from the kernel to detect case 2 reliably. And, unless someone sends out a constructive proposal, let's defer the discussion of case 2 detection to the miniconference.
(And users do complain about rewinding on dcaenc, because this rewind creates one or two invalid DTS frames in the middle of every volume change, and some receivers are slow to resynchronize).
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?
It is a superset. Applications that want low latency don't necessarily want rewinds, but they want high interrupt rate => high power consumption anyway. Applications that want dynamic latency will do rewinds, because this is the only way to get it, except always defaulting to sometimes-unnecessary low latency.
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?
Right now it is indeed an academic question. However, earlier in this year I was contacted by Andrew Eikum who was trying to use rewinds in Wine and insisted that it is an ALSA bug when I told him that they cannot work on the default device. I am not sure whether I convinced him, because I did not use the "unsend bluetooth packets" wording back then. I cannot quote him now, because this was via IM, so quoting would be impolite. And, the log is on the other PC anyway.
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.
Understood. Yes, it would solve the problem, and I have no opinion so far whether it is worth the cost of complexity and of the bad default.
This phrase from the documentation of snd_pcm_rewindable is also something to think about:
""" Note: The snd_pcm_rewind() can accept bigger value than returned by this function. But it is not guaranteed that output stream will be consistent with bigger value. """