Am Sonntag, den 24.10.2010, 16:17 -0400 schrieb Alan Stern: > The lsusb output for your sound card shows that it doesn't distinguish > between 44.1 KHz and 48 KHz when listing its bandwidth requirements; it > asks for the same amount of bandwidth in either case. In particular, > it requires 192 bytes/frame for 16-bit transfers and 296 bytes/frame > for 24-bit transfers (a frame is 1 ms). Don't ask me why the second > number is 8 bytes larger than it should be -- I don't know. > > The information in section 5.11.3 of the USB-2.0 specification shows > how to compute the amount of USB bus time based on the size of a > transfer. For 192 bytes isochronous OUT this comes to a little over > 153 us, and for 296 bytes iso OUT it comes to a little over 237 us. > IN transfers require about 1 us more. You can get reasonably close to > these numbers just by realizing that full-speed USB runs at 12 Mb/s or > 2/3 us per byte and that bit-stuffing requires all the times to be > increased by a factor of 7/6 -- and keep in mind that the protocol has > some overhead. > > For full-speed transfers, you are allowed to allocate up to 90% of the > total frame time for periodic transfers like the isochronous transfers > used for audio. Hence 900 us per frame is available for your audio > data. > > With 16-bit audio, this means there is enough capacity for 900/153 > streams, i.e., less than 6. So you should be okay allocating up to 5 > streams but there isn't enough bandwidth to accomodate 6 streams. > Similarly, with 24-bit audio there is capacity for 900/237 or 3 streams > but not 4. > > Which makes me a little concerned about lines 2, 3, 8, and 9 in your > table above. According to these calculations they shouldn't work. On > the other hand, I know that the 2.6.35 kernel has a bug causing it > to overestimate the available bandwidth for periodic transfers. This > bug has been fixed in 2.6.36; it would be interesting to see what > happens if you run the tests under the newer kernel. > > As for your audio requirements, it looks like there simply is no way to > do what you want using that sound card. If you can find a card that > supports high-speed USB transfers, it should work okay. Or a card that > accurately lists the bandwidth requirements for 44.1 KHz audio, since 6 > streams at 44.1 KHz should fit even though at 48 KHz they don't. Or > you could use two cards of the sort you've got, although you'd have to > plug at least one of them into a separate external USB hub. The vendor writes in the manual: "The Omega is compatible with USB 2.0 ports, but the USB 2.0 bus will switch to the slower USB v1.1 speed to work with the Omega." This is very strange. How should 4+2 mode then be possible? Tried kernels 2.6.31 up to 2.6.36 (64 bit for this machine) and the problem always remains the same. However on another (older) machine with 32 bit kernel 2.6.31, it works like a charm in 4+2 44100 24bit! Double-checked it; the audio really goes through. 4-track recording and simultaneous 2-track playback works perfectly. lsusb -v of the working 32 bit machine and the not working 64 bit machine is attached, maybe it helps... If necessary I can recompile the kernel on the working machine with usb debugging. I saw that on the old machine, there is a 1.1 hub explicitly listed, beside the 2.0 hubs. On the new (not working) machine, there are only 2.0 hubs.
Attachment:
lsusb_twoMachines.tar.gz
Description: application/compressed-tar
