Subject: [linux-audio-dev] Re: [Alsa-devel] Fwd: Re: USB Quattro Linux support
From: Paul Davis (pbd_AT_Op.Net)
Date: Mon Apr 15 2002 - 16:30:31 EEST
>>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
This archive was generated by hypermail 2b28 : Mon Apr 15 2002 - 16:15:51 EEST