If there is a project to add alsa support for these cards, I'd like to help out. I have a USB Duo. Has anybody asked for the specs yet?
cheers, reynald Paul Davis wrote: >>>I think a more exact description of the gphoto approach is: >>>application<->gphoto-lib<->usb-lib<->low-level-generic-USB driver. >>> >>>Only the low-level kernel USB drivers and the usbdevfs filesystem are in >>>kernel space, beyond that the hardware driving is done via the user-space >>>libusb. I'm not sure whether this would have low-enough latency for audio >>>use, after all, digital cameras aren't timing-critical for the sort of things >>>that gphoto aims to do. >> > > If usb-lib is written properly and low-level-generic-USB-driver is > written correctly, there are no latency issues. Latency issues don't > arise from the number of layers of code unless one of the layers of > code is astonishingly badly written. They arise from designs that > buffer data along the way or delay execution of a thread. The system > outlined above doesn't inherently have any such problems. > > >>I think that there is support in gphoto for capturing video streams but I have >>n't used it so I don't know if that is correct. Anyway if I am correct then la >>tency issues would have been solved already. > > > Not at all. arecord(1) can capture audio, but it can't capture 26 > channels of audio at 64 frames/interrupt. Handling latency is partly > an application issue, partly a kernel issue, and partly a requirement > that libraries in the way don't get in the way. It has very little to > do with whether you can do certain generic tasks or not. > > --p > >
