On Feb 09 Jonathan Woithe wrote:
On Sat, Feb 08, 2014 at 10:22:40PM +0900, Takashi Sakamoto wrote:
I understood from Clemens' comments that ... the mixer applications are supposed to use firewire-cdev for all their other dealings with the audio devices. (Clemens and Jonathan, correct me if I misunderstood or if I forgot other control and status I/O that is only possible with direct cooperation by the ALSA driver.)
I don't know his future plan. But according to his advices, my current work is to focus on streaming driver. Currently the functionality to control device's internal mixer should be implemented in user-land application, not in ALSA drivers.
As per an earlier followup, the current intention is indeed to keep the mixer control in userspace.
Sure, definitely; my point was that the kernel ABI which userspace mixer applications are going to use could be a) the ALSA hwdep interface, or b) the ALSA hwdep interface together with firewire-core's firewire-cdev interface, but I understood that b) is the first choice. Specifically, provide in ALSA hwdep only the absolutely necessary interfaces and do as much as possible via firewire-cdev.
In contrast, it can't be firewire-cdev alone because of streaming on/off state influences what can be controlled, and because some devices embed status into the isochronous stream (MotU? RME?), and because some devices (which ones?) may have write-only registers, of which both streaming driver and mixer application want to know what is being written there. Furthermore, it can't be a kernel interface like sysfs or configfs because of the complexity and variety of control protocols of FireWire audio devices.