Hi,
On Nov 18 2015 23:13, Takashi Iwai wrote:
On Sun, 15 Nov 2015 10:25:28 +0100,
Takashi Sakamoto wrote:
Hi,
This patchset adds a constrain to ALSA dice driver to start PCM
substreams and AMDTP packet transferring just at current sampling
transfer frequency.
Dice hardware doesn't allow drivers to get supported combinations
between sampling rate and PCM channels. ALSA dice driver should follow
to the hardware design, though current ALSA driver has some
over-specifications. As a result, the driver has several issue and
brings inconvenience to users.
This patchset consists of two parts:
* 01-05: to add constrain to current sampling transfer frequency and related
code cleanup
* 06-08: to ensure and stabilize AMDTP packet transmission
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).
This sounds rather like a step backward. Why can't the driver set the
rate if it's the only first and exclusive user?
I think you misunderstanding about the main reason of this patch.
Users are allowed to set their favorite sampling rate to Dice device.
But it should be achieved by ways except for PCM functionality in ALSA
dice driver, due to some reasons.
Which part of this patchset should I explain? I described all of the
reasons in each patch. Due to Dice framewotk, due to the design of unit
drivers in Linux FireWire subsystem, due to basic principle for driver
developers, and so on.
Thanks
Takashi Sakamoto
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
