[alsa-devel] [RFC][PATCH 0/8] ALSA: dice: constrain PCM substreams to current sampling transfer frequency

[Takashi Sakamoto]

Hi,

On Nov 25 2015 00:33, Takashi Iwai wrote:
> 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.

Every processes can change the state of clock via Linux FireWire
character device while ALSA dice driver receives/transfers packets
from/to devices.

You can see similar discussions in this thread about firewire-digi00x
module:
http://mailman.alsa-project.org/pipermail/alsa-devel/2015-March/089353.html

Currently, we have no framework to prevent this. For the moment, we
produce 'streaming' notification via ALSA hwdep interface to tell
current status of kernel streaming to userspace. But this is not ideal
solution, because application devlopers can ignore it, so as FFADO
currently does.

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

No guarantee for the race free, so as the other drivers in ALSA firewire
stack. We, including developers in Linux FireWire subsystem, have no
solution to it, and what we can do is to prey that application
developers and users consider about it.

I hope every related persons (developers and users) consider about the
number of developers for this category of devices.


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

Of cource, OK. I don't think that this patchset is easily approved at
all. I realized this issue and solution in this patchset when working
for this patchiset.
http://mailman.alsa-project.org/pipermail/alsa-devel/2014-December/085092.html

Since then, I've been considering about it because it looks a
regression. Although, in fact, some users cannot handle their devices
with ALSA dice module. I think what we should do is to enable all of
users to handle their devices, not a part of them. I believe this is
acceptable trade-off in this subssystem.

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

I'll do it after finishing my work for 'firewire-rme' module for RME
FireFace 400. It will appear in the end of this year.


Thanks

Takashi Sakamoto