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]