On Tue, 24 Nov 2015 16:04:22 +0100, Takashi Sakamoto wrote:
Hi,
On Nov 21 2015 18:46, Takashi Iwai wrote:
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.
The first-user-allowed rule is also common in all of drivers in ALSA firewire stack, so as ALSA dice module. The first process to access hardware via ALSA PCM interface is dominant for deciding sampling transfer frequency.
So, in your model, the first user *is* allowed to change the rate, or not? This was never clear in your description. It appeared as if PCM can never change the rate by itself except for an external tool.
For ALSA firewire stack, we, at least I and Clemens, have an agreement to implement driver functionality except for packet streaming in userspace as much as possible. This is due to the consideration about the difference of functionalities in models which applies the same communication chipset. The much model-dependent codes increses codes in kernel driver. And the codes make it hard to maintain it because they're for model-dependent functionalities. Owners of the models has a possibility to know mechanisms for the functionalities, while we don't touch all of models and investigate them. Userspace is good in this case.
Well, the clock management itself is in kernel. It's just how it's called. I'm not trying to sell it, but the whole picture you've shown was too ambiguous.
BTW, your patch changes the code to read the current rate directly from the hardware. How is it guaranteed to be race free, if the rate is controlled outside the sound device? (It's a pure question.)
To the question about the tools except for ALSA PCM interface, I answer that Dice framework doesn't allow drivers to get all of combinations for PCM rate/channels. In this case, ALSA driver cannot have enough PCM rules to tell all of the combinations and ALSA PCM applications cannot decide to use which PCM rates or channels. This is not related to the code complexity at all.
The reason not to use ALSA Control elements to change the state of clock is that it can be achieved in userspace, so as FFADO does via fw character devices. If ALSA dice driver had the ALSA Control elements, application developers should use both of ALSA Control interface and Linux FireWire character interface. The cost of the study becomes higher than simply using Linux FireWire character interface. If I were the developer, I might not use ALSA Control interface because what I want is too simple to understand many APIs which alsa-lib produces.
I don't have a strong opinion which API to be used or what. But having two different APIs are worse in general.
Overall, see now how many text you could add more in the changelog? :) Let's brush up the texts and give more such information to *users*. Also, remember that the commit texts are only for developers. That is, if you'd change the existing behavior visibly, it's better to be documented in a text file located in Documentation/sound/alsa. There you have freedom to write up the details as you like.
Takashi