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