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

[Takashi Sakamoto <o-takashi@sakamocchi.jp>]

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.


Thanks

Takashi Sakamoto