27 Jan
2010
27 Jan
'10
3:59 a.m.
Pieter Palmers wrote:
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.
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." ;-)
Best regards,
Clemens
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. So maybe you should worry more about the confusion
that might cause...
While potential users might disagree, I think more choice is better.