[alsa-devel] Master Plan on rewinding

[Takashi Iwai]

At Mon, 15 Sep 2014 15:58:42 +0600,
Alexander E. Patrakov wrote:
> 
> 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?

The whole hw_params_*() descriptions are something like bot-style
tweets, we need a bit better texts there :)

The batch parameter was (and partly is) indeed very ambiguous.  Its
usage has been materialized a few years ago.

> 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?

A kind of yes.  Many drivers, especially the old ones, set the minimal
period size without actually knowing the real limit.  It tends to be
smaller than the hardware really supports.  This is, in most cases, 
just because no hardware spec defines that.  So, it can't be blindly
taken as the bottom line, unfortunately.  That's why I suggested the
new field would be optional; we simply don't know the value.


Takashi

> 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
>