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

[Takashi Iwai]

On Fri, 20 Nov 2015 12:19:44 +0100,
Takashi Sakamoto wrote:
> 
> On Nov 20 2015 18:25, Takashi Iwai wrote:
> >> As a result of applying this patchset, userspace applications cannot
> >> start PCM substreams at sampling rates except for current sampling
> >> transfer frequency. Instead, they gain stability to start PCM substreams
> >> and to probe Dice-based models.
> > 
> > Please put this sort of information in the changelog (after some
> > digestion).  It's important to know what you're changing by the patch,
> > but more importantly why you're changing it.
> > 
> >> At a glance, it looks the backwards or the regressions.
> > 
> > Well, it *is* a regression :)
> > 
> > So, the question is why this driver cannot change the clock stably by
> > itself while other way works?  Can't it be implemented in the driver
> > itself?
> 
> The driver can do it with patch 06-08. The limitation comes from PCM
> rules. With patch 01-05, ALSA dice driver has just one PCM rule for
> rate/channels at current sampling transfer frequency.
> 
> 
> Dice framework gives no ways for drivers to get supported combination
> between rate/channels. We cannot change this design, of cource.
> 
> Current ALSA dice driver manage to change the state of clock to generate
> the supported combinations. But this does not always work well with some
> technical reasons. Additionally, this is not preferrable for some users
> who set their configurations to actual device in advance because the
> state of clock is changed unexpectedly.
> 
> This is a reason for patch 01-05.

Well, it's still not clear what you're changing.  With this change,
what will be fixed, what will be broken and what will keep working at
all?  Please explain them concisely.

It's pretty common that a single clock and setup is used for multiple
streams.  Such a restriction is found on many drivers.  What I don't
understand is what makes this so special.

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?


thanks,

Takashi