>>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 _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
