I have all the stations running. The RPs sound good but the Chillout Zone seems off. The stations I run through minimserver sound great on my 272. Is this the station you use?
Nice work, @Kurt!
I’ve been thinking that MinimServer/Streamer is a bit of a sledgehammer to crack a nut just to play FLAC radio streams and that a lighter-weight ffmpeg proxy wouldn’t be that hard to build – you beat me to it!
I look forward to playing with the code in the Git repo. Presumably one would need either a static IP or dynamic DNS and port forwarding on port 9000 to host this locally?
@stevesky: As Kurt has shown, it isn’t that hard to build a proxy for first gen streamers that would enable them to play FLAC radio streams. I think you’ve said there are problems adding Ogg-Flac unpacking and buffer issues for the Gen 1 streamers to add this as a firmware update. Might you could consider hosting an industrialised version of Kurt’s proxy for Naim’s curated list of Naim’s Choice and HD radio stations?
2 Likes
Thanks! 
Well, as said earlier I set this up as a hobby project on a free cloud tier (Oracle Cloud Free Tier | Oracle). For this I had to open in the cloud port 9000 for the music and port 9001 which is the monitor port.
At home I run it on a spare PI I configured with a static IP address for ease of use.
When running it locally there’s a strange thing I noticed in the naim app. When my proxy is in the same network range (192.168.1.x) as my naims and I select the added radio station, the app switches to the UPnP tab. It works, but this is strange behavior. It looks like the app sees the custom radio station as a UPnP device when it is in the same network range as the player or as the app.
However, at home I’ve also another network range (192.168.0.x) which is accessible from 192.168.1.x. When I put the proxy in that network, the custom radio stations are considered as it should. Strange things happen … 
And this is exactly what is quite time consuming. The way the naim app functions and the way the streamer does/expects the handshake with the music services is naim specific and is not documented (which makes some sense). I noticed for example a different behavior when connecting with a naim versus VLC. When I output flac, the naim doesn’t like it and closes the stream. VLC however, has no issue with it.
So, before publically putting everything in github, I’ll first try to get it working for flac and 2) I’ll need to document and cleanup the code.
At home I run it on a spare PI I configured with a static IP address for ease of use.
But don’t you also need to have a static IP from your ISP (with port 9000 forwarded to your Pi) in order to point vTuner at your local instance?
Hi @Adrian_P
The flaw in this strategy is that the problem isn’t really the OGG/FLAC support (we could in theory add that to gen1 streams), but rather the inherent TCP/IP window size supported by the Bridgeco silicon inside those streamers means that the streamer is sensitive to internet network latency. In the case of the Bridgeco chips its limit is due to a limit on some internal RAM inside the chip that can be used by the DMA controller to move data from the Ethernet peripheral to the CPU. Once TCP packet overhead is removed a TCP Windows of about 6Kbytes is possible. This means it can accept 6K of data and then must do the acks, then repeat. As data rates go up and distance from device to server increase then the ability to get the data from A to B in time becomes technically impossible. If we take a 1Mbit/sec stream (128KBytes/sec). So 21.3x times a sec, 6KBytes need to be sent and ack’d. That means a maximum supported network latency of ~50ms. Due to inherent speed of light from UK to USA is about 100ms. To play with the maths of this see: TCP Throughput Calculator - Tools - SWITCHlan - SWITCH. It’s the reason why Tidal playback can be a bit ‘fringe’ on this platform for some customers as their network link can go outside of these bounds due to network congestion.
Legalities aside of proxying commercial broadcast streams, for this system to work needs a collection of per country servers that are doing the reformatting and buffering, hence the player just sees the latency from the proxy to itself. That is why smarter UPnP servers that run on a modern NAS achieve the same as this.
So overall, this is a cute little side private project, it has limited commercial usablity and best kept as a private project thing in the open source community.
On a side note, on all streamers Naim have made in the last 4 years, they handle huge TCP windows and hence they are quite immune to network latency. The packet flow is far more efficient. They also have large RAM buffers that can store many minutes of music, hence ironing over network issues.
Best
Steve Harris
Software Director
Naim Audio Ltd.
3 Likes
Fascinating explanation Steve!
As an aside this afternoon whilst watching the Chelsea game I decided to answer the question “is there absolutely any way to get the Naim Radio FLAC stream onto my 272”.
Now I have a Synology NAS, and it has an application Audio Station where I can add “internet radio URL”. So I added http://mscp3.live-streams.nl:8360/flac.flac as a new radio station and downloaded the Synology DS Audio app from Play Store. Selected 272 as playback device, pressed play. 272 interrupted what it was doing, but radio stream did not start (guessing as the stream is unsupported).
Thought I was at a dead end until I tried casting to the Sky Q box which is connected to the 272 via optical cable. That worked perfectly. Sky box starts playing the stream, and the 272 fired into life and Naim Radio flac played. Not sure of the technicalities of what a Sky Q box does to the stream or whether there is any downsampling and this is unlikely to tick the “audiophile” box . Don’t think I can tell from the 272 as it is a digital input so just displays “signal lock” or whatever it is under info (EDIT under settings/system status Sample Rate changes to 44.1khz!)
However, using this route any internet radio station which is introduced/moved to hires/flac only could be piped to the 272 via the Sky Q box! Little bit more future proofing.
Nope.
I guess it’s the app or the device that connects to vTuner to get the station info to store it on the device. It cannot be vTuner pushing the config to the device cause this could not work without opening ports on the router.
So once on the device it’s considered as a normal outgoing IP socket connection. Hence you don’t need to open additional ports.
Thanks Kurt, that makes sense – and is certainly preferable to punching holes in the firewall.
It makes running the server locally a viable alternative to Minim while also addressing the point Steve makes about latency and the need for this proxy to be close to your network. No idea what’s going on with the input switching if the proxy is in the same subnet as the streamers though.
@Stevesky thanks for taking the time to write such a detailed and informative response.
This is fixed now. The 128kb info was picked up by the app because this info is in the original metadata of the naim stream. By removing this metadata info, the correct bitrate is shown in the app (1411kb/s).
Sure does! Thanks once more
Well it sounds better than it did though it appears to be a different station.
Also, your name is in the metadata getting presented on this station. In case you didn’t know that.
Here’s the acid test - does the WAV version actually sound better than the 320kbps original?
-
I added Naim Radio to the list. Adding http://158.101.168.33:9000/naim_radio in vTuner should do it.
-
Also now the bit rate is shown correctly on the device/app. Previously the app/device took the “icy-br” metadata tag (128 kbit/s for FLAC) from the stream, which is not correct for WAV.
I know… There’s something strange with this URL.
When the handshake process between the Naim and a music service starts, after the first “Hello!” request from the Naim, a music service typically responds by advertising it capabilities (format, metadata info, etc).
However, in this case, the music service sends a complete HTML page. Obviously not something the Naim expects, causing a “stop”. The trick is to reply to the Naim with a response message the streamer understands. So, I created an “OK” message with some info, amongst it, my name.
This is something the Naim understands and answers with a new request, being “send me the music”. At that point I inject the ChillOutbitstream.
1 Like
Not sure if I get your remark right, but the WAV the proxy sends is an unpacking of the OggFlac, being lossless, where the “320” is likely a lossy stream? If the source is the same, the lossless should sound better, which is also the reason behind my proxy initiative.
I have this issue with lossless and lossy in all formats. I think Spotify Premium sounds really good through my system and so does everyone who hears it. I found no sound quality improvement with Tidal or Qobuz and cancelled both after a months trial. My last hearing test revealed only a slight issue at 8 kHz in one ear. My 24 year old daughter also detected no differences in blind tests involving Spotify Premium, Tidal HiFi, Qobuz HiRes, CD, purchased Flac download, Flac rips from CD with Dbpoweramp, Flac via UpnP and Flac via USB memory stick, loudspeakers and headphones with a dedicated headphone amp. She had no idea of the source and got the same results with both my choice of music and her own favourites.
As I said above and previously in other topics, the sound is already great and I’d love to hear an improvement!
1 Like
My ForwardProxy is running since several days without any issues according my monitoring info.
I also see I’ve some “regular” visitors
As we’ve learned from the very good documented story from @Stevesky on how a streamer deals with streaming data, it’s clear that this involves more than just decoding an Ogg envelope.
The server hosting the ForwardProxy software is hosted in a high-performance Oracle Cloud data center in Frankfurt (DE), although on a free account with limited resources/capacity. The Naim music streams are hosted in the Netherlands (I guess), so that’s not a big deal with regards to latency.
Listening myself +12h a day from Belgium, I have maximum 1 reconnect a day. What about you?
My ping time to the Frankfurt server from the UK is around 40ms. Haven’t had any dropouts when I’ve been listening.
Would be interesting to get some feedback from users in other parts of the world.
Ah, I’m one of them – currently running in a new pair of ProAcs 
Radio Paradise feed runs flawlessly here in Thailand, no dropouts so far. I tried to get a ping time, but got ‘unknown server’ instead.