Thanks for the great input. I was actually considering fibrechannel to each of the production studios as well as making sure that all of the copper ethernet was shielded cat6 or better. I have only just discovered the Rivendell package and as soon as I have some time, I am hoping to install it on to my DeMuDi test box and start playing. Lots of RF cable to the roof is definitely in order. I am anticipating having a multitude of listening sources such as shortwave, medium wave, digital counterparts, and satellite radio as well. Like they say, there is no school like the old school! Thanks again for your input. As I continue with plans, I am sure I will be bouncing more questions here. Meanwhile, I am compiling my thoughts here... http://mattrock.net/WSUM/. Matt Dan Mills wrote: > On Friday 16 September 2005 15:32, Matt Rockwell wrote: > >> Greetings, >> I am new to the list and linux audio as I have taken over engineering a >> radio station. We will be building a brand new studio on campus in >> 2008, and I have already started to meet with the architectural >> committee. The more I consider our mission and where broadcast audio >> has the potential to go in the future, the more I find I would like to >> implement an open architecture infrastructure for the facility. >> > > Ahh broadcast, something I know about. > > >> At this point, one of the largest questions I am facing is the transport >> of the audio around the plant, and potentially around campus. The UW >> has invested a tremendous amount of effort in building a multicast >> capable infrastructure to handle communications needs of the campus into >> the future, so we will certainly have pipeline available if we wanted to >> get data from point a to b. The question is what type of transport >> would be capable of interfacing with what type of in-house switching and >> routing? >> > > 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. > > >> The in-house needs would be a system capable of replicating something >> along the lines of what Z-sys:http://www.z-sys.com/pp_routing.html >> equipment is capable of providing. My first choice would be to >> replicate this type of routing in software as well [JACK on a large >> scale]. The question then leads into what will be the transport >> method? Cobranet http://www.peakaudio.com/CobraNet/Background.html is >> certainly promising with actual market availability, but it is still >> proprietary. >> > > 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. > > >> I ultimately envision a system where an artist (DJ) sits at a terminal >> and has the capability to patch their own inputs with ALSA and JACK, >> bring everything up on a control surface for tactile use, and route to >> air, stream, or file. >> > > 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. > > > > -- Matt Rockwell- Technical Director University of Wisconsin- WSUM Student Radio http://www.wsum.org/ PGP ID:0x290719C7
