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