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

[Takashi Iwai]

On Fri, 20 Nov 2015 05:11:24 +0100,
Takashi Sakamoto wrote:
> 
> Hi,
> 
> On Nov 19 2015 19:19, Takashi Iwai wrote:
> > More specifically, although this patchset can be seen as a "bug fix",
> > the bug you're trying to address isn't clear.  And then, what impact
> > this patchset has for users isn't described enough.  If there is no
> > usage change, it should be mentioned clearly.  If any usage change is
> > expected, it must be written.
> 
> I have frequently got private messages from owners of dice-based models
> since below patchset was merged to mainline, .
> 
> [alsa-devel] [PATCH 00/15 v5] ALSA: Enhancement for existed FireWire drivers
> http://mailman.alsa-project.org/pipermail/alsa-devel/2014-December/085142.html
> 
> Some of them addressed that ALSA dice driver fails to handle their
> models. Their experiences are not the same. The summary:
>  * detecting packet discontinuity at starting streaming
>  * ETIMEOUT at starting streaming
>  * ETIMEOUT at probing snd-dice
>  * no sound even if streaming
> 
> This patchset is my solution for the issues. In my understanging, the
> packet discontinuity means that clock generator is not phase-locked, and
> it costs higher for some models to change the state of clock. The
> ETIMEOUT means that the driver receive no notification till timeout, and
> implies the occurence of bus-resets. A part of reasons of no-sound issue
> is a mismatch of data channel formation in AMDTP packet, and implies
> failure in probe processing. All of them indicate that it easily occurs
> to fail to change the state of clock. For the detail, I hope readers to
> read comments in this patchset.

Readers would, but users wouldn't.

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


thanks,

Takashi