On Sat, 21 Nov 2015 01:29:24 +0100, Takashi Sakamoto wrote:
In your original statement:
As a result, userspace applications can request PCM substreams at current sampling transfer frequency. Therefore, when users want to start PCM substreams at different rate, they should set the rate in advance by the other ways (i.e. ffado-dbus-server/ffado-mixer).
So, an application cannot change the PCM rate other than the value currently set by another tool. Is it correct?
Correct.
The single rate restriction is fairly common among many drivers. As this appears like a hardware limitation on DICE, it's fine, per se. But, requiring a special tool to set the sample rate is different; it sounds strange to me.
Why it must be *only* by another tool, not by PCM interface itself? Suppose you playing a single application. Kernel driver also knows that it's currently only a single process accessing the hardware. What prevents it changing the sample rate?
And, even if we implement in that way -- allowing only the locked sample rate -- by some reason (e.g. due to the code complexity), why can't it be controlled via a more common interface like a normal mixer element or such? Some drivers do so, simply by providing an enum control for the master sample rate.
So again: restricting the PCM per one rate itself is understandable. The main question is, however, how to manage the current sample rate. If the first-user-allowed rule is applied, there won't be a big regression, for example.
thanks,
Takashi