[alsa-devel] [FFADO-devel] firewire mixer interface -- was Re: [PATCH 11/11] ALSA: digi00x: apply double-oh-three algorism to multiplex PCM samples

[Jonathan Woithe]

On Fri, Mar 20, 2015 at 01:05:16PM +0100, Robin Gareus wrote:
> I was under the impression that the whole point of moving 1394 audio into
> the kernel was to allow seamless integration with the rest of ALSA.

Speaking as a FFADO developer, the primary reason for pushing FFADO's audio
streaming code into the kernel is for performance and reliability reasons:
it is difficult to maintain the necessary timing when running as a userspace
client of the juju ABI.  Being in kernel brings advantages in this respect. 
The mixer side of things is competely orthogonal to the audio streaming
system in FFADO and was therefore peripheral to this.  As a result the
movement of device control into ALSA wasn't really discussed in great
detail: regardless of whether a kernel or user-space streaming engine is
used, the device control component of FFADO (ffado-mixer) will continue to
be functional.

At least in the first instance the thought was to concentrate on getting the
streaming code into the kernel since that would resolve a vast majority of
performance issues that FFADO faces.  Furthermore, kernel streaming is the
only manditory component needed to allow firewire interfaces to be usable
from "ALSA" applications (presently a program must support JACK to make use
of devices supported by FFADO).  For many users of these interfaces, the
fact that they might have to use something other than alsamixer to control
the interface is completely irrelevant.

The idea was that once in-kernel streaming was operational the longer term
mixer situation could then be looked at if it made sense to change it. 
Whether things work out like this remains to be seen.

Regards
  jonathan