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