Hey folks,

I want to use Stereo Tool to generate a stereo MPX with RDS but am wondering where exactly in the chain it needs to go as I want to stream my audio over IP to the transmitter...

Can I generate the MPX with Stereo Tool and then stream this with Icecast/Ogg or something to the TX, or does the Stereo Tool output really need to be fed directly to the exciter using a completely lossless format?

Anyone doing anything similar?

Hi Gum

Audio codecs such as vorbis, aac etc are optimised to work with conventional audio frequencies and some use other tricks to squeeze out every last bit of bandwidth e.g. taking into account the position of certain ranges of frequencies within the stereo image. No point coding something up twice if you don't need to. That's why you'll be hard pressed to find a codec designed to compress signals such as FM stereo multiplex which contains multiple copies of essentially the same intelligence.

So, if you want to use stereo tool to do your audio processing and generation of the multiplex, you will need two instances, one at the studio end, whose output you would encode and then stream using your icecast server. You'd need your other instance of stereo tool at the TX or midpoint, generating the multiplex from the decoded stream output. That's a bit of a waste of a PC if you ask me, I'd use something simpler at the midpoint if all you're doing is generating stereo multiplex and RDS.

Thanks shuffy, that's kind of what I suspected... I'm wondering if you could get away with it using something like FLAC. It's supposed to be completely lossless and I guess the key is just being able to get the "audio" out the other end untouched at 192 kHz, or whatever.

I'd like to embed a small amount of processing power at the transmitter itself, just enough to make a WiFi connection and stream the signal out through a DAC though (something like an ES9023) - definitely not enough to run Stereo Tool.

I was planning to run Stereo Tool on the same server that's used to host the stream, so I guess the question is really how much bandwidth you would need at the TX site?

192kHz x 16 bits x 1 channel (mono) = a little under 3 Mbps - anyone done anything similar and have any idea how little bandwidth you can realistically get away with?

I don't know much about FLAC to be honest but a quick look at the spec shows that in theory, you ought to be able to compress your 192KHz multiplex from Stereo Tool. Typical FLAC streaming bitrates are about 1Mb/s but that's for conventional audio, presumably 16 bit sampled at 44.1 KHz. So taking into account the increased bitrate and the fact that you're only using one channel, we're probably looking at a little over 2Mb/s. If I were you I'd FLAC your Stereo Tool output using various settings and see if you can still end up with nice multiplex when you've decoded it again. Then you can worry about data bandwidths only when you're certain it can work.

Your embedded processing will have to receive the stream, decode the FLAC and whack that out to your DAC - I wouldn't imagine the decoding is a great overhead but you're probably going to have to do some hacking around with buffer sizes, audio chunk sizes etc to make sure you don't get over/underrun.

I have tested (not quite successfully) something similar, but using standard stereo lower bit rate compression, ogg's good at lower bit rates under 100Kb/s. Software then decodes this into PCM, upsamples to 192 and adds stereo multiplex and RDS using wave tables to generate the 19, 38 and 57KHz signals and further lookup table for the RDS pulse shaping. The DAC's a PCM5122 so similar to what you have in mind. At the end of the day it's a trade-off between processing grunt needed to do the Modulation/RDS and your data bandwidth, which may be a limitation.

Hmm... that sounds interesting...

I was thinking that I would try to code something at the TX that keeps an eye on the buffering and fires off a short-ish recording if the is an underrun. If the buffer has filled back up to a pre-set level by the time the recording finishes playing, the live stream would then cut back in again. If not, another recording would play.

I think I need to just bite the bullet and begin experimenting...

Loads of different possibilities, so go for it. It sounds like you're thinking about an entirely different application for buffering. I was talking about a ring buffer used to feed the DAC. It gets emptied whilst the software is doing its thing generating multiplex "on the fly" to dump the next chunk of audio into the buffer. The buffer I was using in the last version of my test code was only 100,000us - twice the size of one chunk of audio!

The playback stuff in my code was using alsa/asoundlib. It can monitor the amount of data available in the buffer and detect underruns when you've played a frame. If there's an underrun, there's a function in asoundlib which can recover from it, but you hear a slight glitch. My problem was, I didn't have quite enough processing grunt to ensure the whole thing ran smoothly from a compressed stream. No problem from local uncompressed files, but just too many glitches when streaming to be noticeable. Consequently I shelved this project!

Hi,have totally anybody done it streaming mpx?
If yes could i have some help because i'm trying the same with no success

Hi,

Yes, I done it.

StereoTool running on a linux box with the output generating a FLAC stream (120 Khz sample rate) in a OGG container, to a Raspberry Pi 2 with a Wolfson board.

The MPX stereo and RDS signal remained intact.

I even ran it across an internet link without any issue.

Very neat solution as long as you have the bandwidth (around 2Mbps).

Cheers!

That sounds like a pretty nifty solution. Can you give details of how you've done it? I have a project coming up in the near future that could use a stereo online-based link system like this.

SolderingOn wrote:Hi,

Yes, I done it.

StereoTool running on a linux box with the output generating a FLAC stream (120 Khz sample rate) in a OGG container, to a Raspberry Pi 2 with a Wolfson board.

The MPX stereo and RDS signal remained intact.

I even ran it across an internet link without any issue.

Very neat solution as long as you have the bandwidth (around 2Mbps).

Cheers!

Hi,
i have 2 raspberry pi 3 which i'm trying to do the same but till now i have no success....i stream with liquidsoap at an icecast server %oqq(%flac and only at 44.1khz i get only stereo pilot,at any other samplerate only a mono stream. At the other side i receive with mplayer. Could you please help me a little where maybe is my mistake?
Both raspberry have Cirrus Logic 192khz soundcard and iteself each one with stereo tool works perfect,at the streaming i have the problem

Telos reckon they can stream MPX over as little as 320kbps:-

https://www.telosalliance.com/images/Om ... erence.pdf

But they do say this is absolute minimum, and they are more aiming around 1Mbps territory. If you have a good 5GHz link though, why bother compressing, you've got ample bandwidth not to bother (if you can find any software that streams a 192kHz signal!)

Stereo tool is not as processor demanding as you may think. I've had it running fine on an old Celeron laptop - a Dell which had a surprisingly good sound card - plenty good enough for perfect MPX generation. You could probably pick one up for pennies on Ebay. Have a similar laptop using Edcast or similar to stream at studio end and you are sorted for not much dosh. One tip - if you are processing remotely at TX, you want the very best stream quality into it possible. Ideally uncompressed wav, but you could probably get away with 320 mp3. If you tried 128 or below the processor will exaggerate all the (digital) compression artifacts and it will sound horrible!

Oh and use one of the better presets on Stereo Tool and dial it back a bit - most of them are waaay over the top! Even a leisurely preset on ST can sound just as loud as commercial stations without cheating on peak deviation.

@NOYB i have already for years now purchased stereo tool and i'm very happy for its use.
I use an analog link which transfers mpx from studio to the mountain that is my antenna. But because of quality i want to change that link with an ip link *2 raspberries* one taking mpx and stream it to the other via wifi link. I have already try it but with no success and maybe my decoder settings are wrong or i totally use wrong software. As Dear SolderingOn have done this maybe he can give me some more infos with which programm could i broadcast and with which i can receive this stream.
I have try %ogg(%flac at liquidsoap but only at 44.1khz i get stereo pilot with no stereo,at any other samplerate i get only mono and nothing else. Maybe wrong settings,maybe wrong software.....

lelos09 wrote:(%flac at liquidsoap but only at 44.1khz i get stereo pilot with no stereo,at any other samplerate i get only mono and nothing else.

When you say any other sample rate, do you mean above 44.1? Only with 192kHz will you get the stereo and RDS.

When you say any other sample rate, do you mean above 44.1? Only with 192kHz will you get the stereo and RDS.

At 44.1khz i have 19khz pilot of stereo but not stereo only mono.
Above 44.1khz till 192khz i have not pilot no stereo only mono sound at all.
Mplayer write that it receive stream at 192khz for example but nothing from Stereo or Rds works.
Where could be the problem?
My liquidsoap 3 different setups are :
output.icecast(
%ogg(%flac(samplerate=44100)) or %ogg(%flac(samplerate=120000)) %ogg(%flac(samplerate=192000))
host = "localhost",
port = 8000,
password = "hackme",
mount = "radio_flac",
input.alsa()

Right, I don't have this setup at the moment but here's some hacked together configs from my notes. You'll need to add the appropriate input.jack / input.alsa, convert stereo to mono, etc.

For the send side, the important commands are -

set("frame.audio.samplerate",192000)
set("frame.audio.channels",2)

output.harbor(
%flac(samplerate=128000,channels=1,compression=5, bits_per_sample=16),
port=1234,
mount="mpx",
url="http://127.0.0.1",
icy_metadata="false",
protocol="icy",
mpx_ip)

For the receive side -

set("frame.audio.samplerate",192000)
set("frame.audio.channels",2)

remoteurl = "http://127.0.0.1/mpx"

test_op = mksafe(input.http(id="ip-remote",remoteurl,buffer=5., max=20.))

test_op = audio_to_stereo(test_op)

output.alsa(test_op)

I was using alsa + jack on the transmit side (a linux box running stereo tool).

For the receive side, a Pi2 with a Wolfson board. I was just using straight alsa rather than adding the jack layer.

You can get the latency quite low, but the example keeps the buffers quite high.

First of all thanks for your help!!!!
I done with icecast with my example working with liquidsoap at the receive end.
One problem with your example.....the variable mpx_ip used here has not been previously
defined.
Do you know why is it happens?

lelos09 wrote:... link with an ip link *2 raspberries* ....

My understanding was that the sound card on Raspberries was not recommended for normal audio, let alone MPX. So you'd likely need external soundcards to use with the Raspberries if you are not using those already.

I too would be interested to know details of how to reliably stream MPX over IP - ideally without having to get into the murky world that is Linux! Anyone got an "idiot's guide" (Windows or Linux leaving nothing out!)?

NOYB wrote:ideally without having to get into the murky world that is Linux!

Linux is a bright, shiny, open world. It's the horrible, closed, insecure, unstable, expensive Windoze world that is murky!

Windows is now just an irrelevant, insecure, unreliable client for a Unix world. You're better off - in every way - using Linux or BSD. We've got to the point that it Just Works™, without the endless screwing around with pointless third-party "security" software that you have to do in Windoze to stop it nagging you about its lack of "protection".

FYI - if a Windoze computer is connected to the interweb, it takes around 10 seconds to gain full remote control of it. You can then do whatever you like with it, including logging Bank Account and Credit Card details, change the registered address of the user, and order lots of nice, expensive stuff to be delivered to the address of your choice. This is (apparently) the most common scam at the moment, and is netting the Romanians and Russians massive amounts of money......

If you don't care about your own personal security, use Windoze - after all, you have nothing to hide, do you?

Deleted

Albert H wrote:

NOYB wrote:ideally without having to get into the murky world that is Linux!

Linux is a bright, shiny, open world. It's the horrible, closed, insecure, unstable, expensive Windoze world that is murky!

I judge myself to be reasonably computer savvy, but I ALWAYS get stuck when I try to do stuff on Linux. Maybe "It just works" for a simple Ubuntu office install, but try to do anything else and I've always got very stuck - and I mean dead-end stuck having tried many many different suggestions.

Yes open is great. I hate windows as next as the next man, but until I have a degree in computer science (ain't going to happen), or Linux and its advocates dumb things down to "real world" levels of assistance, then it isn't for me.