qu shootout

[Dick ReesParticipant]

The so-called YouTube shootout/demo was sponsored by the Sonic Sense dealership, but the video should have been called “Sonic Nonsense”. Total consumer oriented hogwash. The “engineers””credits” were speedily discredited by the abysmal mixes, but in his defense the musicians were very low on the talent totem pole.

The entire endeavor was a BWOT.

[f428Participant]

I understand about 2.0 being fast enough for the pc for up to 38? Into the pc for the qu-32. Maybe it’s just something that I’m over thinking, though it already meets its limits for the qu-drive. Too bad that wasn’t usb3.

I also heard that the mixer doesn’t display gain reduction for the compressors? True?

After owning the SL and nearly using every gesture on it (not that there are many), I’m becoming quite particular about what my next digital console should do.

How does the M5 stack up in terms of features? I know it’s much more expensive, but simply in terms of features…more, less, similar?

[[XAP]BobParticipant]

Qu-Drive doesn’t need USB3 any more than the USB B streaming does, it handles the same data – I still think that Qu-Drive needs to be able to choose how many tracks to use, then you could choose how much your storage could handle…

[AndreasModerator]

Before its getting more into myth about USB 2.0 I maybe should clarify some aspects from their technical standpoints (implemented both host and device protocols for years now), but not before stating that I recently did a 32Ch recording via USB on an old laptop and a 18 Ch QuDrive Multitrack for backup purposes in parallel. Works absolutely flawless for the required 3 hours.

USB 2.0 uses a physical bitrate of 480MBit/s, 32 Ch Audio Stream at 48kHz, 24 Bit consume 48000*3*32 = 4.6MBytes/s resp. 36.8MBit/s bandwith, this is below 10% what USB 2.0 theoretically could handle. Really plenty of bandwith headroom on USB 2.0 even when sending the 32 Ch back to the desk in the same moment (which also works very well).

QuDrive recording and USB Streaming are two totally different scenarios. The QuDrive operates as a block device, updates are done on multiples for sector sizes (512 Bytes), the desk really is in need of a significant amount of memory to prepare sectors from the internal audio streams which then could be written to the drive. Since more samples are created while one sector is written, at least two buffers are required per stream. For the QuDrive this is at least 18*2*512 = 18kBytes. To handle varying seek times on HDDs and slow write times on flash devices probably more buffers are used per stream.

USB 2.0 High Speed Audio Streaming in contrast operates in a so called isochronous mode, where each 125µSec a bunch of samples are transmitted between host and device. At 48kHz each packet contains exactly 6 Samples resp. 6*32*3 = 576 Bytes on a Qu32. On this type of connection there is a size limitation per transaction, which is 1kBytes (may be raised to 3kBytes to be precise, but let’s stay with the 1kByte here), still allowing about 56 parallel Channels to be streamed per direction. This limitation does not exist for block devices like the QuDrive!

I really do not have any concern when it comes to USB audio streaming. I the past, where USB was limited to FullSpeed, FireWire of course was the only choice for multichannel recording, but these days are over for years now…

[[XAP]BobParticipant]

Thanks for the detail there – I’ll read it again when I have some brain space 😉

[Author]

Posts