From what Steve said above it is latency that is all important rather than bandwidth. It’s your latency to Kurt’s server in Frankfurt that will determine how effectively you can stream from his proxy. Your 4ms ping time must be to somewhere local. With the 300ms ping time you quoted above to Kurt’s server I’m surprised it works at all!
I’ve used the RP main mix station a few times and it’s dropped out on me in each of the short sessions. Also, it’s less obvious with the RP streams but the SQ doesn’t seem as good as my minimserver m3u file streams.
64 bytes from 158.101.168.33: icmp_seq=38 ttl=56 time=163.020 ms
64 bytes from 158.101.168.33: icmp_seq=39 ttl=56 time=165.021 ms
64 bytes from 158.101.168.33: icmp_seq=40 ttl=56 time=169.014 ms
64 bytes from 158.101.168.33: icmp_seq=41 ttl=56 time=165.605 ms
64 bytes from 158.101.168.33: icmp_seq=42 ttl=56 time=162.976 ms
64 bytes from 158.101.168.33: icmp_seq=43 ttl=56 time=231.098 ms
64 bytes from 158.101.168.33: icmp_seq=44 ttl=56 time=162.359 ms
64 bytes from 158.101.168.33: icmp_seq=45 ttl=56 time=163.498 ms
64 bytes from 158.101.168.33: icmp_seq=46 ttl=56 time=163.276 ms
64 bytes from 158.101.168.33: icmp_seq=47 ttl=56 time=171.382 ms
64 bytes from 158.101.168.33: icmp_seq=48 ttl=56 time=162.877 ms
64 bytes from 158.101.168.33: icmp_seq=49 ttl=56 time=164.461 ms
64 bytes from 158.101.168.33: icmp_seq=50 ttl=56 time=166.216 ms
I’m in the states (AZ)
Internet speeds in Thailand are surprisingly good these days. And all for £15/month!
When you consider the Thai approach to ‘cable dressing’, it’s actually surprising anything works at all 
5 Likes
From Dublin I get a ping time of 33ms
Vodafone Cable in Germany is about 25-35ms. Not any problems so far. Streaming with UQ2 and US. The wav stream (Naim Jazz and Classical) is easy noticable better SQ than mp3 stream.
All stations are buffering repeatedly for me now here in the states. Not even streamable. Not sure what’s changed.
The system is running for 7 days and I haven’t touched anything.
At the moment of writing I’m listening to Naim Jazz and this works without drops. Probably the latency between the US and Germany.
Hi Kurt, do you still plan to publish the code on Github so that people can run the proxy locally to minimise latency? Making it available as a Docker image might also make it simple for people to install and run locally.
Yes I’ll do!
Reason(s) why it’s not there yet are:
- Currently I rely on ffmpeg to do the transcoding. I’m looking into the Ogg format to do this straight away in Java in the application itself. This doesn’t progress as expected.
- I’ve to clean-up and document things
Docker would be overkill. The application is 1 jar without dependencies to other libraries. Next to that it requires JDK/JRE 11 and ffmpeg installed and that’s it.
It runs on linux only as I rely on some linux specific commands to kill stale processes when needed.
As soon as I’m there I’ll post all information here.
Sounds good. When I was looking into doing something like this I was thinking of using the Jave2 library that wraps ffmpeg for Java, but removing the ffmpeg dependency altogether would be much simpler!
My pings are still in the triple digits. It’d be great to be able to run locally if that’s possible.
I also considered that approach, but I don’t see a lot of added value as the Java wrapper still needs ffmpeg underneath.
Just to give you some updates on where I’m with this.
I didn’t stand still! The proxy I wrote seems to do what’s supposed to do; actually more than I ever had in mind. I initially wrote this for myself as I couldn’t believe a Gen 1 device was not capable of processing hi res streams (despite what naim says). It was a challenge and at some time, middle in the night, it made some noise on my system J
This was also the moment I thought that I probably was not the only one embarrassed with this, so I decided to share it with other people being in a similar situation. After all, those devices aren’t cheap, and from 1 day to another, naim decides you’re not playing in the premier league anymore. For me this is/was fun to program this in my free time. It makes me smiling seeing that 24/7 there are always people listening to some streams. Not sure if this legal, I’m not aware, but anyhow, if I’ve to shut this down, with minimal effort you’ll be able to install this locally, run it on a Cloud and share it with friends, as it’s multi user, multi station, by design.
I state “it works”, but I know someone in Arizona is suffering with latency. Amazed to read a connection to Thailand is better than mine from Belgium to Frankfurt (where the proxy is running). Although, also for this, there’s an explanation; I’ll document this behavior. Thanks for those who contributed; fun after all. 
I promised to make it public and I know some of you are waiting for this. I also firmly believe this will be the solution for our Arizona friend, as he can run it at home or in the US. Truly, I’m not a bad guy and I’ll live up to my promises. Last effort (still ongoing) is to eleminate the need for the external transcoder (ffmpeg) by studying the Ogg format, the OggFlac mapping and Flac format myself. I have it working seamlessly on VLC, but the naim doesn’t like it. More on that in the next article.
So, yes, I’ll publish the whole thing on github - promised once again, and, yes, today I’ve started writing the documentation on how the thing works, how to setup the current version on your NAS, raspberry, cloud, linux pc, actually anything being capable of running Java 11 on Linux/Unix based systems.
As a Tech guy, for me the challenge is to make it also accessible for non tech people.
Plan today is:
- Finish the documentation
- Provide a link via this forum how to download the complete starter package; docs and binaries – will be Google Drive kind of thing.
- Get the whole thing, sources etc, on github for everyone.
I got the message naim doesn’t like this; more on this later, but if I ever get kicked out here, note: kurt dot lefevre at gmail dot com.
Keep you posted!
6 Likes
Well I think I’m the guy in AZ to whom you refer and I appreciate your efforts. My understanding of this is pretty limited but I can say that the limitations with ffmpeg on my QNAP were easily resolved by installing a container. This container made transcoding possible with the Bubble app I use for Tidal hi res playback and works without a hitch. I don’t know how hard it is to create one of these containers though.
Yep, could be you. What “container” do you mean?
Fact is that a container infrastructure adds an additional resource consumption - read: slowing down things - compared to bare/native.
It’s a docker hub container I don’t really know much about it to be honest.
I run six containers on my QNAP, it has 8gb of RAM doesn’t drop a beat it also runs, Asset and many other QNAP services for backup purposes and other apps. Containers if done well don’t take too much resources at all. They are easy for the user to install as long as all dependancies are included. The only issues are updates that need to be thought about so the app itself can do this within the container or you the user has to rebuild them each time a new release comes out.
Good to hear! The application is fairly simple; just 1 jar and a configuration file.
They need to be run in host mode though so the container can access network resources the NAS or computer running is on it as it will be on its own virtual network if not. This is just a step the user has to do when creating the container on the NAS. So this needs to be communicated well in any instructions.
Hi Kurt, the only objection I can see Naim having with this is that you are proxying commercial broadcast streams with a cloud-hosted server. No such issues for personal use, of course.
I suggested packaging using a container to address installation issues for less tech savvy users. Many people here run a NAS from either Synology or QNAP to host their audio files and run a UPnP server, and they both provide very intuitive UIs for running Docker containers. Packaging the app with all the dependencies hides the complexity of having to install Java, set up scripts, issues with ffmpeg and so on. It might be an idea to also provide a Docker image for simple setup as well as the Github option for those that want to run on bare metal.