Pieter Palmers wrote: > Clemens Ladisch wrote: >> Pieter Palmers wrote: >>> 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. So re-plugging can be handled mostly like a new device appearing. This means that the driver doesn't need to have support for this. (Good for me. :-) > [...] > 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. The discovery/mixer code for USB and HDA devices is already in the kernel, and it's just as messy. However, if that code already exists (in userspace), I wouldn't want to duplicate it without a good reason. >> BTW: a first version of the driver is available here: >> git://git.alsa-project.org/alsa-kprivate.git fireworks >> (this branch will be rebased) >> At the moment, it has one fixed sample rate, no mixer controls, and >> capture only Now with playback, but still very experimental; Jack should work. Best regards, Clemens _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
