Sounds like the mp3 stream
Sounds like the mp3 stream.
That’s strange. I guess you’re still listening to the standard vTuner available stations.
I’m listening to Naim Jazz right now, and that’s what I see:
I also checked the other stations you mentioned and they’re all reporting 1411kb/s
With a ping of 300ms you’d think you would be experiencing significant buffering issues on a 272 given what @Stevesky said about 50ms being the threshold for good performance but that clearly isn’t the case…
Exactly!
Below was from an older article, so dont know if that would included a NAC272, but presumably the larger buffer would help.
“The newer streamer products that have the 50MB buffer are:
- atom
- star
- nova
- nd5xs
- ndx2
- nd555
Full article:
My network speed is pretty robust (below), not sure if that helps. My (limited) understanding is that latency is key, but is overall network performance a combination of latency plus speed?
PING ms
4
DOWNLOAD Mbps
616.40
UPLOAD Mbps
310.70
Impressive figures! You live in the datacenter itself? 
It’s indeed an AND story of low latency and high network bandwidth and a robust hardware network infrastructure and no noisy neighbours, like children downloading or watching huge bandwidth demanding things, and some other things I would have forgotten.
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.