External HDD for audio samples

[Andrew Tarpinian]

This is all kinda what I was thinking, but was not sure if I was  
correct in all my assumptions.

I will use USB for now but I think I will pick up an express card  
FW800 or eSATA at some point - mine as well use the slot if I got it,

thanks,

On Feb 18, 2010, at 6:54 AM, ibi sum wrote:

> The deal with the bus question is this: USB does require that the host
> CPU be involved in moving data to and from the devices.  This ties the
> USB host controller and your CPU together during all i/o operations
> and reduces the amount of processing power your CPU has to deliver for
> other things, like synthesis.  The CPU has to be involved in each
> transfer between devices - one transaction to receive the data,
> another to send it on to the next device.  On modern multi-Ghz CPU's
> this isn't "really" a big deal .. but in the days of 400mhz CPU's and
> so on, it was a bit of a concern.  You can definitely bog a WinXP
> machine (fixed a little bit in Win7) by having lots of file copies
> going on between disks across different USB Hubs, also - the OS has to
> behave itself during these i/o operations, and for some older variants
> of Windows there were definite performance hits during bulk transfers.
> There is also some care required for how you position your USB
> devices on a hub - USB devices can interfere with each other a lot
> easier than Firewire can, and the conditions for this interference are
> quite easy to come across.
>
> With Firewire, things can be different - the Firewire controller
> hardware itself is involved in the process of shunting data between
> two nodes on the Firewire bus - the CPU can be removed from the
> process of transfer save for a 'check-in' function (seeing if things
> are completed), and this does *not* use as much CPU.  If you get a
> decent Firewire-based disk system set up, you can pretty much do
> copies and i/o on those disks without having a significant impact on
> CPU time.
>
> With USB, also, it is important to realize that the more USB devices
> talking on a single Hub, the more likely that collisions/contention
> occurs, which needs the CPU to arbitrate.  If you design your USB
> system well, however, you can drastically minimize the overall impact
> this contention will have on your system - if you're on a PC that has
> the slots, get a PCI->USB card *just* for your Audio devices .. MIDI
> and Audio USB interfaces on one Hub, Mice/Joysticks/keyboards on
> another hub, Disks and storage on another separate hub .. also, make
> sure you isolate USB2 devices from USB1.1 devices, as the presence of
> a 1.1 device on a Hub with other 2.0 devices degrades performance
> completely .. this is a common gotcha.
>
> In short, with modern USB2 and CPU speeds being what they are, you can
> definitely use USB2-based disks in a production capacity, but you do
> have to isolate things if you want the absolute best performance ..
> with Firewire, its a bit easier to just set and forget, however.  My
> option would always be to use Firewire instead of USB, but certainly
> you can get away with USB-only.
>
> Also, one thing about ExpressCard as an expansion option: deep down
> inside, its just USB2 and PCI-E bundled together in a fancy package.
> You might find yourself getting a good performance boost if you get an
> ExpressCard->USB2 interface, however, as ExpressCard slots are usually
> implemented as their own USB Hub, separate from the other USB Hubs in
> the system - not always the case, but you can check if you get a USB
> node dump tool (in Linux its quite easy to walk the USB tree in /sys
> or use lsusb to do it) and count the Hub nodes.  The more there are in
> your system, the better.
>
>
> On 2/18/10, K9 Kai Niggemann <canine at waf80.de> wrote:
>>
>> On 18.02.2010, at 00:59, Joost Schuttelaar wrote:
>>
>>> USB will do fine. Just get a 99 USD xTB USB drive and don't look  
>>> back.
>>
>>
>> actually at the price these drives are: just get two and back up  
>> all sounds
>> on a regular basis...!
>>
>> Kai
>>
>>
>> _______________________________________________
>> music-bar mailing list
>> music-bar at lists.music-bar.org
>> http://lists.music-bar.org/cgi-bin/mailman/listinfo/music-bar
>>
> _______________________________________________
> music-bar mailing list
> music-bar at lists.music-bar.org
> http://lists.music-bar.org/cgi-bin/mailman/listinfo/music-bar