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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
