2 Way Audio over IP

[djmatthill]

Hello

I need a simple software solution that will enable us to stream (near broadcast quality speech) audio from a laptop with a 3g modem to a studio PC again running windows with a broadband connection.

 

The tricky bit is needing a return talk back return feed from studio.

 

This is going to be used for live OB stuff for a community radio station and needs to be low cost (or even free if poss)

 

Iv got the hardware sorted but am looking for a cheap software package similar to Luci Live but less expensive!

 

Have any of you done this successfully on a budget ?

 

Thanks

 

 

Matt

[bruce]

Does the talkback need to be broadcast quality?

[djmatthill]

Does the talkback need to be broadcast quality?

 

Hi Bruce ... No mate the returns just so the presenter at studio can chat to the OB presenter etc .

 

 

Matt

[niloc887]

How about Mumble/Murmur?

I've used it as a wifi relay via raspberry pi to remote speakers in fairly close to real time (10-20ms). You can adjust the quality settings to limit the bandwidth on the return?

I haven't used it over an internet connection but it is designed to do so. Also it's open source, so that's a bonus.

Cheers

Colin

 

[dosxuk]

VLC

 

Windows Media Encoder / Expression Encoder

 

Flash Media Live Encoder

 

All available for free and capable of on-the-fly audio streaming. Not particularly simple to set up, but once you've worked it out it's fine, but then again, does a cheap/simple/good solution exist anywhere for anything?

[Dan Gruner]

Hi Matt,

 

I am Technical Director for a community radio station in Dorset. Drop me a PM and I can run over (low cost) ways we do this.

 

Thanks,

 

Dan

[henny]

Hi Matt,

 

I am Technical Director for a community radio station in Dorset. Drop me a PM and I can run over (low cost) ways we do this.

 

Thanks,

 

Dan

 

Dan - any chance of sharing on there for the good of us all

[bruce]

I also am involved with Community Radio. It's a bit like real radio, but usually on a shoestring budget. It's also predominantly staffed by "amateurs" - and I don't mean that disrespectfully - but having a TO (Technical Operator) is an unusual luxury. Your system has got to be simple, and pretty much idiot proof.

 

Very few CR stations have the luxury of Comrex etc.

 

I recall doing a broadcast from a venue a few years ago. I got the train there, with our entire "OB kit" - encoder, mixer, play out system, mics and cables - in a small rucksack. When I arrived, the very helpful caretaker said "The BBC were here doing a broadcast last week, and they parked their truck over there". He had coned off half the car park for me!

 

 

We regularly do live outside broadcasts from all sorts of venues, ranging from 2000 seat concert halls to rooms above pubs, to fields.

 

In general, we find that the hassles involved in getting a stable and reliable 2 way low latency link outweigh the benefits. I'd much rather have a reliable link back to the studio, even if it's only one direction and high latency. More on that later.

 

If you just need a "talkback" channel for cueing and general comms, then that's what mobile phones are for. Or Skype.

 

If you want to do an interactive "handover' to the OB, or maybe do a quick chat before the main event, again, use phones, running through your desk TBO. Once the event is up and running, switch to the "proper" link.

 

 

3G sounds like a great idea in terms of flexibility - but a wired connection is always preferable to either wifi or 3G,

 

 

 

Setting up a one way link is usually quite straightforward - use the same sort of arrangement that you use for your general internet streaming - typically an icecast or shoutcast server. By doing it that way, you don't have to worry too much about firewalls and NAT etc. Set it up right, and it becomes plug and play.

 

 

My preferred setup for any OB is to use something like a Barix instreamer. http://www.barix.com/products/instreamer-family

I've got a couple of these, configured to send a stream back to the studio. Take it to just about any venue which has wired internet with DHCP, plug it on, and it'll start. Usually no configuration needed. One occasion, our team pitched up at a music festival in a town square, and the promised network connection wasn't available. We basically asked around the shops and pubs in the area to see if we could "borrow" someone's broadband. A pub obliged, we plugged into the router, and we were up and running from their beer garden! No significant IT skills needed.

 

Latency depends largely on the buffer size at the receive end (usually I use winamp or VLC) - bigger buffer means more latency, but less susceptibility to dropouts. I'm usually happy with a latency of around 5 secs.

 

 

I've also used one of these to broadcast a gig from a festival with none of our team present! We were invited to broadcast a series of concerts from 5pm-7pm each day for a week from a fairly well known music festival. It was over an hours drive from us - we couldn't guarantee to have people there each night, and couldn't have anyone there the first day. So I stuck the in streamer in a jiffy bag and posted it to the sound engineer. Gave him basic instructions ("Plug it into the broadband router. If you get a green light, it's working. Squirt audio into the box at line level, then phone me and I'll check the levels and link back to base") - and all was well!

 

Alternatively, a laptop running windows and something like edcast/butt/etc can do a similar job. A bit more configureable, which gives you more flexibility, but also gives people more to fiddle with. Also more boxes and wires. But basic Windows networking skills are common enough - just tell whoever's setting it up to "get it onto the network somehow, once you've established that a web browser works, click this button to start streaming".

 

The other advantage of using a laptop is that it gives you the opportunity to use wifi or 3G connections. These will work, but you're working with a network that you can't control. I recall an event a few months ago, where the promised wired connection was unavailable, but there was wifi. There also was 3G. We tested both, and both worked really well. But that was before the event started. Once the audience arrived, both became unusable.

 

On that occasion, we recorded the gig and broadcast it later. Sometimes, the benefit of doing it "live" is outweighed by the hassle!

 

Sometimes, you'll need to drop the bandwidth down from where you'd ideally like to be. If you can, using aac rather than mp3 also helps.

 

 

We now find that for most of our outside broadcasts, we don't worry about a "talkback channel", and quite often don't have anyone in the studio. We do it all "on the clock" from the scheduling system. So suppose I've got an OB scheduled from 12.00-14.00. I push something into the scheduler saying "12.00 start playing OB link, wait until 14.00, stop link and continue with play out". At the OB end, we start sending some instrumental music about 5 minutes before the scheduled start time, and just start broadcasting at the designated start time.

 

 

If I really needed a low latency bidirectional link, I'd think about using something like "trx" - but the need for bidirectional UDP via whatever NAT is in the way (remember with 3G, you've often got double NAT) and the need for a linux environment means you will need a reasonably skilled TO for even the most basic setup.

[djmatthill]

Hi Bruce thanks for the very detailed reply ... A lot to go on there.

 

The barix solution looks very interesting.. a couple of questions if I may.

 

Doe the barix solution used as a tx and rx pair need to use a third party server like shoutcast etc or is it simply plug and go?

 

Can a barix tx used on it's own be received and played out on vlc or equivalent media player at studio end ?

 

Is there an easy way to connect the barix tx to a mobile or 3g connection for truly mobile use ?

 

 

Sorry for all the questions but I'm very interested in this soulution

matt

[henny]

Take a look at http://jamesharrison.github.io/openob/index.html

It will run on a raspberry pi

[bruce]

Yes, the openOB stuff looks interesting. I played around with an earlier version a few years ago. But you do need to either have control of the router at the rx end to set up port forwarding, or run a vpn tunnel between the 2 ends.

 

 

Regarding Barix - it can do a wide range of comms protocols between the transmit and receive box. You can do direct streams between 2 boxes over UDP or RTP, or their proprietary BRTP (which makes fire walling a little more straightforward). Or you can runs web server on the transmit box and pull the stream over http. Or you can do a TCP icecast stream via an intermediate server. You can do "raw" streams (i.e. like .wav) or mp3 compressed. Lots of options.

 

I generally use an icecast-based MP3 stream, simply because it's the simplest - and I already have an icecast server running for other purposes. It's the option that gives fewest firewalling challenges, and you have the option to easily monitor the live stream. Firewalling doesn't really worry me - I'm a network engineer - but it's best to keep the model as simple as possible.

 

 

One clever feature that the Barix devices have: there's no display. It's configured via a web interface. It typically gets its address via DHCP, so how do you know its IP address? Easy - it tells you! Stick a part of headphones in, power it up, and it'll "speak" it's address, in a germanic accent!

 

 

I've found the Barix units to be extremely useful, and reliable. They're becoming quite common for studio-transmitter links. I recently decommissioned one of the extreamer units (the "receive end" of the link) and the system had been up for about a year and a half! You could of course do the same with a laptop and vlc or winamp, but I'm impressed with the reliability and robustness of the Barix devices compared to a general purpose computer.

[dbuckley]

As Bruce has explained, latency is everything; low-fi solutions like Skype have low latency, similar to a mobile phone, but as the quality goes up, solutions tend to use more buffering at the receive end, so as to ensure continuous high quality audio, but at the expense of latency. Sometimes, latency doesn't matter, but if you are trying to get a chat going betwixt studio and OB, then latency is a killer. The presenters are happy to use Skype on air, but it isn't a high quality audio solution, it's about the same as phone audio.

 

The community station I work with has half a great solution for some OBs; we have a Marti RF link, which has zero latency decent quality mono audio from OB to studio. If mono is good enough, and the remote is in RF range of the studio, then it is a great solution. However... there is no talkback. And a pair of Marti boxes are not cheap.

 

Talkback being such a big issue, I've got a proposal in the works to add a SCA^* generator to the RF chain, so that we can put the talkback out "hidden" within the broadcast signal, so with a suitable SCA receiver, anywhere one can get decent FM reception of the station one can have zero latency talkback. It's not full audio quality, but mono with 5KHz bandwidth is perfectly adequate for talkback, better than a phone line. This isn't zero cost, but looks a very effective way of doing talkback "properly". Of course, being a community station, theres a minor matter of funding...

 

*) SCA is an abbreviation for sub-carrier authority. Subcarriers are transmitted "alongside" the main broadcast carriers. The 'A' in SCA is because in the USA one needed special permission to use subcarriers, hence one got subcarreir authority, so the whole technology got named after a piece of bureaucracy. Most jurisdictions just give the station bandwidth limits, and as long as the transmissions are within the limits they dont care in detail what you transmit. RDS is an example of SCA in action; the RDS data is transmitted as a (57KHz), and one can add a couple more subcarriers, 67KHz and 92KHz being the usual frequencies.

[bruce]

Clever scheme. If you were in the UK, ofcom would not permit it...

 

From the Ofcom Site Engineering Code for Analogue Radio Broadcast Transmission Systems:

2.9 Supplementary Signals (RDS, Additional Services and Control/Monitoring Functions)

No supplementary subcarrier systems other than those conforming to the RDS specification IEC 62106 are currently permitted.

(note: The BBC has an in-house subcarrier system used for telemetry purposes which is exempt from this provision.)

[dbuckley]

Thats really mean!

 

Or, perhaps, moneygrabbing; during a government consultation on FM station frequency spacing some years ago here in NZ, some submitters suggested that those who wanted to use subcarriers should pay for the spectrum on a normal commercial basis...

[djmatthill]

Hi Iv tried streaming using my laptop and and icecast programme and works well on wired and wi go but when I try and tether my phone to use it's 3g data I have issues because there are no ports 80 or 88 etc open...

 

How do I get around this little issue ?

 

 

Matt