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
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
