20 Sep
2005
20 Sep
'05
11:20 a.m.
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:
--
Matt Rockwell- Technical Director
University of Wisconsin- WSUM Student Radio
http://www.wsum.org/ PGP ID:0x290719C7
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.