[AndreasModerator]

one second recording of 18 channels at 48kHz with 24 bit is about 2.5MBytes, just to mention (18*48000*3)…
a warning potentially could be displayed at 50% fill level, so the operator has one second to recognize, understand and act…

[AndreasModerator]

…and using FX units hosted on PC/MAC should work as well when patching MixOuts to USB Sends and return wet signal via USB back to channels.

[AndreasModerator]

Exactly, FAT updates, which require additional transactions are the problem, not the write speed. Additionally the stick may need additional time to handle internal wearing issues. Don’t forget that these types of Flash Drives (and SSDs as well) use NAND flashes which degrade over time and therefore needs some special care to maintain integrity. Contrary to FAT updates this is totally undeterministic. This is not critical for regular use, but may hit you in realtime applications like audio streaming.

[AndreasModerator]

hmm, wouldn’t this be a nice feature request: adding an (optional) steep bandpass filter to the noise generator with the frequencies of the GEQ along with next/prev selection when active in GEQ mode. …no need for the CD… 😉
Anyway: Clever idea GCumbee, thanks!

[AndreasModerator]

2.4MB/s is only the bandwidth required to write the audio data, but maintaining the drive integrity more reads/writes are required (cluster allocation, FAT management). These updates will occur in bunches (18 FAT updates for 18 Tracks) and if this takes too long, the Qu may run out of buffers (even with clever buffer management and delayed FAT updates). So the margin is not as large as it seems to be…

[AndreasModerator]

From his last post Koksi01 is referring to a CruzerFit (USB2.0) and not an UltraFit (USB3.0). Would be indeed interesting to see multitrack recording on this rather slow stick (~4.5MB/s write speed as stated in some reviews)

[AndreasModerator]

Ok, just spliced a USB cable to do some power measurements. USB Power is not the issue with the Ultra Fit (64GB), it only draws about 100mA from the port. My external HDD has a peak consumption of about 700mA which is way above USB specs, but runs fine with the Qu. So the good info is, it looks like a software problem which should be possible to fix. I’ll redo some diagnostics on the USB side next days, maybe someone on A&H listens… 😉

[AndreasModerator]

The 4h recording limit comes from the FAT32 filesystem which restricts filesize to 4GBytes each. Recording stereo with 24 Bit at 48kHz produces about a Gig per hour (2*48000*3*60*60). Multitrack recording limit is 8 hours per session, since 18 mono files are recorded.

[AndreasModerator]

Its not the write speed (the UltraFit does not even enumerate properly, communication lost right in the middle), and when a cable/right-angle is required, we’ll also could use the Extreme. Once you saw the UltraFit plugged into the Qu you really want this combination to work, but I doubt there’s a solution for existing units (just guessing!!!).

[AndreasModerator]

Same issue here, I guess the power consumtion of the Ultra Fit is simply too high for the Qu socket.

[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…

[AndreasModerator]

Currently I’m fine since my 32Ch have some space to record Groups and separated channels in parallel, so I can easily record the individuals from Ch19 and up and map my premixes to the lower streams (works quite fine!). But events will come that need recording of nearly all channels available and these are the ones I really have to ensure there is some high level recording in the end, even if the host recording fails for some reasons (happened once in a video production, luckily files could been recovered manually…).

Not sure if independent mappings will consume more DSP power, since audio streaming and USB Block Devices handled pretty different. I assume there is only very little to be shared regarding performance.

But, hey, this is only a feature suggestion, not an urgent issue… 😉

[AndreasModerator]

…technically no difference to an analog console with four FX units in the siderack…

[AndreasModerator]

…and don’t forget to check DCA assignment… hit me once… 😉

[AndreasModerator]

Not sure its worth discussing updateability of the AR from PC or Qu. I don’t expect too much computing inside which needs regular updates, only expect some adaption to the dSnake protocol. If it works, no update necessary.
Buying a used AR may require to check it is properly updated before.

[Author]

Posts