Vienna Symphonic Library Forum
Forum Statistics

200,782 users have contributed to 43,212 threads and 259,132 posts.

In the past 24 hours, we have 3 new thread(s), 9 new post(s) and 48 new user(s).

  • i personally don't like USB too much because in most cases too many devices share USB and the (serial and time-sliced) protocol is not what i would wish to stream samples. actually FW 400 gives better results in *real life*, better would be FW 800 of course.
    as mentioned above sATA would be best, since it puts less CPU load on the system than even firewire. you can proove this by yourself copying a file from/to a firewire-drive and looking at CPU usage.
    christian

    and remember: only a CRAY can run an endless loop in just three seconds.
  • I'll add my vote with Christian's for FW. USB was too unreliable and variable in speed for me, and once i swapped my sample drive into an external FW enclosure, everything settled down, became a lot more consistent, and i had less hiccups in the DAW.
    It's interesting that on my little laptop, USB can handle up to 4 external devices before it really starts to suffer in terms of speed and consistent transfer rates, yet firewire (400) just keeps going with little or no effect on transfer rates when adding another device. I suspect if we were to meter USB rates and variability on a larger box, there would be the same inconsistency.
    I'm also about to add an external SATA drive, through cardbus, as the transfer rates are consistent with/faster than firewire with a maintained bandwidth that's more reliable than USB.

    And I'm still waiting for a midi controller company to turn out an ethernet midi controller, as getting midi out of ethernet instead of USB would add even greater speed and consistency. (IMHO) I also have the impression that a lightning fast Midi controller would take pressure off the CPU, as anything i'm writing with dense midi data tends to clog the system up, and slow everything down.

    Just two roubles worth.

    Regards,

    Alex.

  • alex, the problem is not USB or ethernet (converted to classic MIDI), but the opto-couplers ... midi protocol has been developed for 9.600 kbit/s (serial ports) and seperating the DIN-cable electrically using such opto-couplers which have by design a very high latency and slow transfer rate.

    you could avoid this by sending MIDI between machines using eg. musiclab's Midi-over-Lan and connecting your input device (aka. keyboard) directly with USB so avoiding classical MIDI cables.

    though i have to add we've noticed some issues on a network lately using many MoL devices and streaming over ethernet simultaneously, though gigabit. my assumption is that because MoL uses UDP instead of TCP (in simple terms: UDP does not garantee an ethernet-packet to be delivered), but this has to be checked in detail ...
    christian

    and remember: only a CRAY can run an endless loop in just three seconds.
  • Christian,
    Thanks.
    I just learnt something, and will carefully file the info away for future reference (My midi keyboards are both USB). To be blunt, i didn't know MIDI was transmitted at such a low Kb rate.

    But then i'm still fond of parchment!

    Regards,
    Alex.

  • The setup I was getting was to have my keyboard connected through USB, but then use a 4 USB hub to hold the key for Logic Pro 7, VSL, and the connection for external hard drive. Will this be any sort of overload for one USB drive? My macbook pro only has 2. Would there be a better use of the two USB ports? Thanks

  • Once again I would suggest avoiding both firewire and USB for external drives meant to be used for sample librariies. This is especially true with laptop machines since they will likely be used with firewire audio interfaces. On MacBook Pros with firewire 400 & 800 if both ports are accessed, both function as firewire 400 ports. Two port SATA adapters for laptops are available in both Cardbus and ExpressCard form factors for about $120. If you go with eSATA, you avoid conflict or competition for resources between a firewire audio interface and the drive streaming the samples. Also, recent SATA drives have a theoretical transfer rate of 3GBS - - several times faster than 480MBS or 400MBS rates of firewire or USB drives - - of course all these rates are theoretical - - in practice no existing drives come near these limits. I also suggest dealing with companies that know computers and make reliable products. For example, every La Cie firewire drive I have owned has fried its bridge circuit within a year after the 1 year warranty expired. None of my Other World Computing firewire enclosures - two of which are now inhabited by drives that were once inside the La Cie enclosures - has EVER fried its bridge circuit. OWC has a knowlegable technical staff and, in my experience, is highly responsive to customers. It also has low prices.

  • Thanks so much for all the information. Hugely helpful.

  • Thanks all. It looks like eSata may be the way to go. My G5 is a Dual 2.7 with pci-X slots. In addition to the G5 (main DAW machine with DP 5.11) I have a PC slave (pipped in via ADAT) and a laptop (w/ Sonar as the DAW running on Windows XP) for travel.

    Any thoughts on formatting the drives? FAT32 so all computers can read the samples or would that result in performance and/or file access problems? Of course, I could greatly simplify things by buying a Mac laptop, but... [[;)]]

  • last edited
    last edited

    @cm said:


    though i have to add we've noticed some issues on a network lately using many MoL devices and streaming over ethernet simultaneously, though gigabit. my assumption is that because MoL uses UDP instead of TCP (in simple terms: UDP does not garantee an ethernet-packet to be delivered), but this has to be checked in detail ...
    christian


    The problem you're experiencing with latency is not UDP (Midi-Over-Lan is TCP) but is likely due to your networking hardware. First, make sure that you are using a switch, and not a hub, because hubs broadcast all incoming data to every connected node, whereas a switch will make sure the data is routed to the correct destination. Hub's can cause severe packet collision which results in poor performance.

    Second, make sure the switch you are using operates on Layer 2 (reffering to TCP/IP) and not a Layer 3. The difference here is that Layer 2 does not look at the actual data and only routes packets based on a computer's MAC address, whereas Layer 3 switches route based on reading packet headers. While Layer 3 sorting is more accurate, it slows down traffic significantly and is generally not needed.

    Finally, make sure you are using a professional router. I reccomend Cisco's Gigabit Catylist switches. As well as operating on Layer 2, Cisco takes special care to ensure optimum bandwidth through innovative features and technologies. A 24-port gigabit switch runs around $900.00

    That should clear up most of your latency problems.

  • thanks for the hints [;)] if you read some of my posts you can see i'm not too dumb in networking ...
    of course its a switch (there are no hubs for gigabit), of course it is layer2 (actually using mac adressing after learned instead of IP), and there is no router in the setup (why should there be one?) - it is a dedicated network for 6 machines with an uplink to a server using jumbo packets if needed.

    btw: not too fond of CISCOs - i don't like their kind of configuration and there have been a series of severe security leaks during the last year
    thx anyway, christian

    and remember: only a CRAY can run an endless loop in just three seconds.