24 Jan
2010
24 Jan
'10
3:32 p.m.
Hi,
On Saturday 23 January 2010 23:05:16 Pieter Palmers wrote:
PS: An ALSA driver for firewire devices will solve
quite some issues
with respect to user experience and compatibility. Nevertheless I'm
personally still inclined to maintain and improve the userspace jack
streaming engine, and also port it to the new firewire stack. I'm not
convinced that things like hot-plugging, device aggregation and
sample-accurate midi will be easy to implement using
jack->ALSA->firewire. So maybe you should worry more about the confusion
that might cause...
I once started thinking about this:
- Does alsa support devices where channels are added and removed during
runtime? If yes, firewire would be one big device and the channels are added
when the stream is established (and the sync is stable). If not, things will
get nasty...
- Users are already confused when they have to start special mixer apps to
get their detected card running, doing the detection in some userspace to get
the device is probably more confusing for the entry-level. But that detection
app can probably be run by udev like the firmware loaders for some usb-devices.
But if alsa doesn't support adding channels at runtime, a complex configuration
app is needed...
- Why can't each firewire-device be one alsa-device? fw allows very easy
syncing of multiple cards (two ways for sync are already in the firewire
protocol), so this is widely used. When each device has its own alsa-device,
apps would need to open several devices and still get all their callbacks
combined at once (or as one callback). I don't know about the alsa internals,
but I think its easier to open one device instead of opening several and keep
track of the sync.
Have fun,
Arnold