[alsa-devel] Echo Fireworks control protocol (was Re: Sample program for hwdep interface)
Stefan Richter
stefanr at s5r6.in-berlin.de
Sun Feb 9 15:51:45 CET 2014
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.
--
Stefan Richter
-=====-====- --=- -=--=
http://arcgraph.de/sr/
More information about the Alsa-devel
mailing list