There have been other topics on Qobuz stuttering but they all seem to be closed. Excuse me if that isn’t the case and I can redirect there.
I’ve been suffering from poor playback of Qobuz playlists for several months now.
The symptom is that some (but not all) tracks fail to play properly. A failed track continues to stutter for the full duration of the track. The next track in the play queue may play perfectly OK. Individual songs always play OK. It’s play lists that are the problem.
I’ve been doing a deep dive into packet captures to see if I can see what’s going on.
A couple of conclusions are:
The Qobuz app on a PC behaves completely differently to the Qobuz client on the NDX2. You cannot capture on a PC and translate any findings to the NDX2. You can also have zero problems with PC app + airplay, and still encounter problems with native Qobuz on the NDX2.
The PC app downloads ‘chunks’ of songs in approx 2MB over an encrypted channel to the cache. The cache is then played. Presumably to ensure you continue to pay subscription and don’t just cache everything.
The NDX2 native Qobuz app has some encrypted set up over TLS (presumably to ensure you’ve paid) but after that the file is server via a standard HTTP (unencrypted) download from Akamai as a FLAC encoded file in one chunk over a single TCP stream.
Download speeds are throttled by the NDX2 (via TCP 0 window size). Typical speed is around 6 Mbps which is less than 10% of the Internet link capacity available. That on its own doesn’t seem to be any issue.
The failing files do show some packet retransmits and the TCP session stalls for a second or two, but the transfer then recovers normally at the TCP layer. However, playback stutters badly.
The player continues to stutter long after the file download has completed (suggesting there’s some problem with buffer under-run handling.)
Your experience will vary: the use of the Akamai CDN means you could be talking to completely different download servers per song per client per day.
I’m only using standard quality files and still have the problem.
I’ve shared my findings with Naim and offered to share the packet captures and comments.
My own take on this is that, especially early in the FLAC file download, that the buffering is very sensitive to short term overloads or packet loss on the Internet (between my own ISP and the Akamai CDN server)
I personally think this could be improved e.g. by kicking the download off earlier before the previous song finishes playing (to allow more time for the buffer to fill with the second song) or implementing a more aggressive caching, or parallel download streams, or improved i/o on the streaming board. I really can’t imagine there’s less than 2* 40MB of memory free on the streaming card to hold two entire songs [typical songs seem to be around 30MB in FLAC]. I also think buffer under-run could be handled better. e.g. by increasing the recovery time and ensuring the buffer is well-filled before resuming play back. And also checking what is going on when the file has completed download, but the stuttering is continuing (sounds like a buffer pointer under-run or scheduling error).
Any comments or questions, please feel to ask.
regards,
Typical (failing) TCP stream shown below. You can see the couple of seconds stall in the progress of the ACKs.
I’m sure there’ll be people who say: “improve your Internet”. Well yes, I shall of course try to do that. But the Internet is a big place, and there are always packet drops and session stalls. Streaming audio should be resilient in the face of that IMVHO.
A couple of thoughts, are you using an ISP that throttles certain data port types, like Plusnet? Also before starting your tests, did you power off your NDX2 (at the plug end) for a few minutes. And I suppose the same question to your router?
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
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.
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…
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.
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:
at start if play we aim to buffer at least 3 secs of audio at a rate of upto 50mbits/sec
we then do a dynamic throttle based on buffering bare min 2x playback rate / max 8x rate.
we don’t hit the link for full bandwidth as on some home network equipment this can cause them to block other traffic and starve the whole network. Cheap/free isp routers are free for a good reason and we have to support them - they are a curse.
during a gapless transition we allow upto 10secs for one track to join on to the other data wise.
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.
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.
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.
