On Friday 16 September 2005 15:32, Matt Rockwell wrote: Ahh broadcast, something I know about. I would be looking at pulling a **LOT** of ethernet cable, and leave the final decision as to what the protocol will be until nearer the time. There are really two reasons for this: 1: Your requirements **WILL** change over that period, for example, it might be that you end up needing more remote inputs from an on campus venue, and need lower latency which would at the moment favour ethersound over cobranet IMHO. 2: There are several competing technologies at present and it is not at all clear to me which will become most common in each market for example, apart from the obvious Cobranet and Ethersound there is the Axia audio stuff which is aimed squarely at broadcast as is the Arakis product (amongst others), maybe SAS will bring out something useful.... One tip, if you are specifying network infrastructure, have them wire it with foil screened cable, that way, if you need to run a quick and dirty feed to somewhere, you can just use the network wiring to carry line level audio. Ohh and put some coax runs from your rack room to each studio as well (word clock and possibly video feeds). As new as all this stuff is, I would wait a year before getting too detailed about what to hang on the end of the cables, the technology will be much more mature in a year and it will be far easier to find product that is a good fit. Ethersound has the same problem, but also does distributed routing and uses standard ethernet layer 2 hardware. Give it a year, then attend NAB and possibly IBC. The Rivendell mob are working on it (Disclaimer, I am one of them)! The patching is probably best not handled at the DJ level at all, why not just have everything hooked up to a router all the time and just select what the control surface channel -> router mapping is. That way all the heavy lifting can be done in the rack room, and you get the vast majority of the heat load out of the studios. On that subject, don't forget to slap the mechanical design team around about noise transmission from ductwork, they never understand why this matters! Also make sure your rack room has ample cooling for everything you might ever possibly want in there... A Raised floor in the rack room is **GOOD**. The rack room cooling needs to be on the protected power supply, if the aircon goes down with the mains supply, you are off the air in short order even if the racks are on a UPS/Generator combo. Talk to IT about experience in server room design, it is pretty similar for the main rack room (Buy them scotch, it usually works). Ohh, run some (lots more then you need) ,N type terminated cables from the rack room to the roof, these are useful for whatever random RF needs you have. say you need a new sat. downlink, or need to monitor for a emergency broadcast system feed, these will be useful. Use good cable for this, I like Westflex 103 if the run is not too long, of one of the smaller andrews cables if it is. Just my random thoughts on broadcast... Your milage may differ. HTH. Regards, Dan.

I have also been searching for a solution to IP audio tranport mechanisms (over ethernet) as well, but have only found cobranet and ethersound as Dan mentioned, both of which appear to be propietary formats. I experimented with using jack.udp a while back, but it seems like it would hardly be sufficient for transferring multiple channels of audio (say 16 like cobranet). Perhapse the linux community can start to develop and open-source set of standards that could be used for transporting uncompressed audio over ethernet, perhaps using regular ethernet adapters? Has anybody heard of ethernet striping? A way to combine ethernet cards to increase throughput? I found this on the cinerella site, http://heroinewarrior.com/firehose.php3 Could we write a protocol for transporting audio that wouldn't get bogged down by traffic from other protocols, or would this even be a problem (I'm still learning about how IP works...) ben racher

I have also been searching for a solution to IP audio tranport mechanisms (over ethernet) as well, but have only found cobranet and ethersound as Dan mentioned, both of which appear to be propietary formats. I experimented with using jack.udp a while back, but it seems like it would hardly be sufficient for transferring multiple channels of audio (say 16 like cobranet). Perhapse the linux community can start to develop and open-source set of standards that could be used for transporting uncompressed audio over ethernet, perhaps using regular ethernet adapters?

Could we write a protocol for transporting audio that wouldn't get bogged down by traffic from other protocols, or would this even be a problem (I'm still learning about how IP works...)

On Wednesday 21 September 2005 02:12, Benjamin Racher wrote: probably not at this sort of performance level, besides there just is not that much spare bandwidth! Regards, Dan (Who has far more projects then he does time!).