[alsa-devel] Master Plan on rewinding

[Alexander E. Patrakov]

15.09.2014 15:19, Takashi Iwai wrote:
> At Sun, 14 Sep 2014 18:07:23 +0600,
> Alexander E. Patrakov wrote:
>>
>> 14.09.2014 17:37, Raymond Yau wrote:
>>>
>>>   >
>>>   >
>>>   >> === On the rewind safeguard ===
>>>   >
>>>   >
>>>   > Result 1: it has been decided that the return value of
>>> snd_pcm_rewindable() is not changed, and the safeguard is returned by a
>>> separate function.
>>>
>>> It is unlikely to return any value which is safe, it is the
>>> responsiability of the application to decide how much can be rewind
>>
>> You are placing a responsibility on an application without giving it any
>> means to make an informed decision. E.g. 4 ms is OK on snd-hda-intel,
>> but definitely not OK on ymfpci even on infinitely fast CPU (because of
>> the fixed 5 ms interrupt interval). The whole question here is: how is
>> an application supposed to know that?
>
> Well, maybe the word "safeguard" is somewhat confusing to be used as
> a driver API.  There is no "safety" at all there.  There is only
> "theoretically minimal" (and it often lies even if the hardware chip
> says so).  How much value to be taken as "safeguard" is rather a
> choice by each application or sound backend.

I agree with this "bad wording" remark. Let's talk about the 
"theoretically minimal non-rewindable amount of samples" from now on.

> Right now, the only information we give from the sound driver is
> INFO_BATCH flag.  And I agree with a bit more detailed information to
> be exposed from the driver -- but only if possible.  This must be an
> optional information and not mandatory.

Here I mostly agree.

Indeed, this INFO_BATCH flag exists. However, its documentation is so 
vague that IMHO a documentation patch is needed to legitimize its use as 
a "you must not leave less than one period when rewinding" indicator. 
Also, the documentation says about snd_pcm_hw_params_is_batch(): "This 
function should only be called when the configuration space contains a 
single configuration" - I believe that it is an error (and PulseAudio 
calls it without obeying this restriction), because this function is 
helpful exactly for choosing hardware parameters such as period size. 
May I write "if the configuration space contains more than one 
configuration, the result indicates whether a configuration exists where 
such double-buffering is done"? Also the documentation talks about 
"hardware", should I extend it to the whole plugin chain?

As for the desire to export other information if available, it is 
certainly good.

What remains not fully understood for me is the claim that the 
information already exposed by every driver (in the form of the minimal 
period size) is not useful. I understand that two people are against 
this idea, so it must be bad. But I must understand why. Is it because 
the minimum period size reported by some drivers (which ones are 
suspected, if any?) may be a lie?

Clemens Ladisch mentioned USB as a counterexample, but it is a batch 
device for which the current period size is more relevant than the 
minimal one. Pierre-Louis Bossart just said that it is "really asking 
for trouble" without much explanation.

Can anyone name a sound controller that is not of a batch variety, where 
the theoretically minimal non-rewindable amount of samples is, at some 
settings, higher than the reported minimum period size at the same 
number of channels, sample rate and sample format?

[and yes, I understand that I can always cheat and say: let's change the 
definition of INFO_BATCH so that it includes such cases]

-- 
Alexander E. Patrakov