Clemens Ladisch wrote: > Pieter Palmers wrote: >> Talking about mixer controls: do you intend to expose all mixer controls > > Yes. > >> to ALSA, > > x*y monitoring controls would suck in a 'normal' mixer application. > >> or would a custom application still be the way to go for mixers? > > Yes. In theory, it shouldn't be difficult to make the existing (if any) > custom mixer work with both drivers. > >> Can ALSA handle mixer capabilities that change with changing device >> configurations? > > Yes; mixer controls can be changed, created and destroyed at runtime. > >>> Hotplugging and device aggregation should work just fine, although not >>> both together, i.e., ALSA doesn't allow changing the stream format while >>> the stream is running. Is this possible with FFADO+Jack? >> With the current version of FFADO this is not possible as bus resets are >> not handled properly. But there is no technical reason that prevents >> this. Jack ports can be created and destroyed at run-time, and that's >> all it takes. >> >> The major use-case I'm thinking of is where a user inadvertently unplugs >> the device. With current FFADO this is a show stopper, but I'd like to >> see a system that keeps running and restores everything once the device >> is re-attached. > > If Jack cannot fix a xrun immediately by restarting, it dies. If the > device stays unplugged, waiting indefinitely for it to reappear would > make no sense. This cannot be handled without asking the user. To me it makes perfect sense. I unplug the device, jack keeps running in "dummy mode", I re-plug the device and we're good to go. Why would jack have to die? Even more: I plug in another device and it shows up as a new interface in the jack graph. Just like what happens if I start a new jack client. Note that I make abstraction of the technical implementation here, this is merely the perspective of an end-user who couldn't care less about technical details. > >>>> So maybe you should worry more about the confusion that might cause... >>> While potential users might disagree, I think more choice is better. >> Most likely users won't care as long as it works (at least that's how I >> look at things I didn't develop myself). The challenge will therefore be >> to ensure that both systems can co-exist. > > I can see the bug report: "I started both Jack+firewire and some ALSA > program, but the output wasn't properly mixed." ;-) The horror... Personally I would not mind to use ALSA for all the streaming (and mixer control for that matter) if it is up for it. The user support of parallel implementations is simply too much work. But it might take some time for that to happen (as we also have e.g. MOTU and RME streaming protocols to take care off). The same goes for mixer control and maybe even device discovery: if it can be built upon ALSA, why not? I'm personally a bit skeptical about whether you'd want (or get) the required code for this into the kernel though. Especially for BeBoB devices its a significant. Maximum user experience with minimal effort is what I'd like to see, and if I have to ditch all of the current FFADO code, so be it. Linux audio is enough of a mess already. Greets, Pieter _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
