Very nice work 
In can tell you that the buffer size in current Naim streamers is 50 MB. Other than that, I never had the problem with the Naim app when I used it, but that was until 1.5 years ago. My ISP download bandwidth changed at the time from 50 to 250 Mbps, but 50 worked just fine.
(Since then have been using Roon and never a problem either, but obviously this works completely different)
Yes. NDX2 and ISP router rebooted several times as I first suspected a memory leak. Symptoms remain the same.
ISP does not provide any throttling. Proven with Speedtest etc.
The TCP window was closing at the NDX2 end. That was providing the throughput throttling. Not the ISP. See this link for an explanation: TCP Zero Window Size
It’s not speed/throughput. Not getting anywhere near a throughput limit on the ISP link.
It’s also not latency. The Akamai server is also only around 11 mSec away.
It’s minimal packet loss causing a TCP session stall = “goodput”
I know it’s not speed and 50 Mbps is just fine if stable. I’m just telling you all that I know and it was a remark on the side because it came to mind. My main point was to inform you about the 50 MB buffer size.
You did some fine analysis and I think it’s now up to Naim support
Thanks. 50MB seems very small.
Do you happen to know where that limit is?
Is that on the TCP stream entering the streaming card, or is that a buffer after decoding the stream feeding into the DAC board?
It’s considered sufficient 
and I don’t know but if I had to buffer more than that for it to play without stuttering, I would switch ISP. What you are describing is not a common complaint on the forum in any case.
I don’t know about the exact buffer strategy and you made good points. Naim’s software director is your man here, paging @Stevesky. If you search for this user name and buffer you will find several posts, like these and others. There is not much detail but maybe something on these threads sheds some light:
There’s a bit more in one of his posts in the beta room, but as it’s not public I can’t link. I hope Steve will respond and clarify regarding your findings.
This (successful) download of the next track in the play list certainly looks like adaptive traffic shaping: more aggressive at the beginning and then throttling later once the buffer fills.
I should also clarify that the whole NDX2 becomes very unresponsive for the whole song when it stutters (gui + remote control). Then it fully recovers for the next track.
50 megabytes is enough for ~5 minutes of cd-quality uncompressed audio, so doesn’t seem that small generally speaking. Even at 24/192 that’s 45 seconds of raw audio. However I doubt it is filling it completely before playback.
Perhaps the streamer is too optimistic about getting a sustained data rate: it gets the first chunk very quickly so thinks it is safe to start playing, but then the stream dries up… and it never manages to catch up. Is there something about when the ‘flat spot’ happens that is an indicator of issues: i.e. reading less that 6mb in the first 3 seconds == stuttering?
Difficult to say. Obviously it’s a ring buffer. The buffer is getting filled indirectly by the TCP stream. The buffer definitely isn’t “full” before playback starts.
Before the TCP stream even starts there’s a few seconds start up (DNS, contact Qobuz, locate file on Akamai, DNS to find Akamai server). For the failed file that’s 5 seconds. For the others it’s around 3 seconds. I can’t see what’s happening internally in that time.
Then there’s the raw HTTP file transfer data of a FLAC file. FLAC uses compression at block level which has to be undone. Max block size in FLAC is 65536 samples = ± 1 second. I haven’t looked at that in the decodes.
The audio data is finally translated into a PCM bitstream. So the ring buffer is emptied into the audio DAC at a clock rate determined by the DAC.
The stutter seems to start when the ring buffer empties, but getting exact timing is tough. However, the stuttering doesn’t cease when the buffer is refilling because the file transfer completes after 38 seconds, which is long before the song finishes playing (3 or 4 minutes).
I have been using Qobuz since it was introduced into the US market a few years ago. I use Qobuz the majority of time when listening to music, albums, play lists and internet radio, without any problems. Located in Seattle, Washington USA. The other listening is via my NAS from ripped CD’s.
On some of the playlists a album will no longer play since it has been removed from the catalogue but cannot recall any problems with the streaming. I do hope you get to the bottom of your problem and report findings.
Do not rely on Ookla Speedtest. I ran the test in both a browser and in their App using the same server and got very different results. One reported twice the download speed. I repeated the test several times with the same results.
Importantly I reported it to Speedtest and sent three e-mail reminders but not a single response.
Whilst I would not rely on Ookla alone as a benchmark If your using WiFi on a device then you will get different speeds each time you check anyway. WiFi is never constant speed its up and down all the time.
Hi, I’ve been busy with this for a few weeks already.
The NDX2 and my PC are wired so there’s no WiFi variability.
Because the HTTP stream is not encrypted, you can extract the URI the NDX2 is using to download the audio media from the packet capture. So I also downloaded the URI for the FLAC file on my mac using the same Akamai server. It plays fine on VLC. But the NDX2 also plays individual songs just fine. So this just seems to be a timing issue with Qobuz play lists when there’s packet loss early in the download.
Hi there.
There we are. I’m experiencing something very similar with Tidal on my NDX2 since the release of the last official firmware update (v 3.8.1).
Naim technical support (software) is working on it, studying the logs and something else. I also as crazy making diagnoses trying to discard the different parts of the installation and set up, wich has benn working properly for the last 3 years so far; but for now, plunged into uncertainty…
I’m very interested in your evolution…
Just want to clarify the stream definitely “catches up”.
I see the HTTP/1.1 200 OK response confirming the file download completion after 38 seconds, which is long before the song finishes playing. There is some more time (approx 62 seconds) before the last FIN ACK, ACK normal session closure. But that’s completely normal on modern HTTP clients that may re-use a single TCP session for multiple requests. The idle TCP session is being closed normally by the client end = NDX2: not the server. It’s also before the end of the track playback.
Hi @MeToo
Can you email me on steve.harris@naimaudio.com and Ideally send me a wireshark of a problematic qobuz transfer and the track/album/artist.
I’ve got a feeling there maybe a twist here, like a dns timeout issue going on which is causing a thread to block.
To clear up facts in this thread:
Best regards
Steve Harris
Software Director
Naim Audio Ltd.
Hi Steve, will email direct.
It could be many things of course as it looks more like timing related than anything else. DNS is certainly a possibility and I’m going to try some experiments there. There’s also a lot going on “under the hood” in Akamai and there may also be some geo-location quirks that mean the download is not coming from the optimal server. I was getting very consistent deterministic results with one particular play list though.
regards
Phew. I don’t know WTF all this stuff is about. But I do know with my Nova Qobuz did the same thing. So I always acess Qobuz through the Naim app…never a problem doing that.
Very interesting thread and I hope you fix your Qobuz issue. Please do keep us updated on your investigation.
Lots to learn as many elements of end-to-end path a file takes from server to player are not transparent without a networking background, and therefore hard to know what helps or hindering performance, as in this case, and what can be done to improve.
The problem has been identified and solved. Kudos to Steve Harris.
I wrote “there’s a lot going on under the hood in Akamai” and so it turned out to be exactly that.
NDX2 working as designed. My LAN and ISP link working as designed. Qobuz app and playlists working as designed.
Problem was in the Akamai content delivery network. By examining the packet traces I provided and zooming in on one particular song download in a playlist, Steve identified a mis-configured retransmit timer on a server in Haarlem that was messing up the packet shaping on the file transfer required for smooth playback.
The is pretty unusual, and not something most users are going to come across, nor be able to diagnose, and certainly not a configuration item they can fix themselves.
Now time to just sit back and enjoy the music.
regards,
