4 Feb
2010
4 Feb
'10
6:24 a.m.
Pieter Palmers wrote:
Clemens Ladisch wrote:
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. :-)
Pieter Palmers wrote:
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. 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. [...]
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