I am in the process of migrating my RoonServer off my QNAP NAS and onto a separate Ubuntu box.
At the same time I have moved my music setup to a new room which does not have fixed ethernet yet. So my Raspberry Pi is now in there and over Wifi instead of fixed ethernet.
AND I replaced my Allo DigiOne transport with a IQAudio DAC Pro.
So lots changed.
Now I am having problems with songs going silent, and then Roon jumps to the next track. Mostly with Tidal Hifi tracks, and often I will see the “loading slowly” message.
The TL;DR version is that the problem is that the Pi is having wifi problems - it actually seems to drop off the network perhaps due to the level of traffic, or power supply voltage issue (even though it is a 3A supply. As simple as that - nothing to do with performance of the stream from Tidal, nothing to do with which DNS servers you use…
But the investigation was interesting and helps me understand things better so I’ll share it in case it is interesting for others.
I reproduced the problem while capturing all network traffic on my Roon server box with tcpdump. I then picked through that capture in Wireshark to see what was happening.
So interestingly when I start playing a track I see RoonServer make two requests to http://sp-pr-ak.audio.tidal.com/mediatracks/…
In my case one was for
/mediatracks/CAEaKRInMzVlYmJkYTJmOGNhYjkwZjUxYmRlYjE4ZGI0MTc4ZmFfNjEubXA0/0.flac?hdnts=exp=1572554614~hmac=9866111de23ee386ad48bd1521028ac1f261acbe1bee7b3a22c07b27939b41ed
and the other
/mediatracks/CAEaKRInYWI1YzBkMDU4NGViNmI2MTk4M2JkYTdkODU5ZTZiM2FfNjEubXA0/0.flac?hdnts=exp=1572554614~hmac=74e1cd1febd117f1a0bb4431098eaa0fcc67d2134ca924c891d208de5a9ca579
(Obviously you can’t just fetch these - there is an authentication process that I didn’t look into).
Both gets return FLAC content - you can see from the start of the response. One is a 72,287,579 byte response, the other is 26,452,255 bytes in size.
I’m not clear why two files are fetched.
Despite the claim that Tidal is loading slowly, in actual fact the whole 26M file is downloaded in 6.5 seconds (32 megabits/sec) and the whole 72M file arrives in 11 seconds (52.3 megabits/sec).
This isn’t that surprising since I have 200Mb fibre service and the content is coming from Akamai’s edge right here in Cape Town just a couple of hops and <2ms away.
Roonserver opens a TCP connection to the playback Pi and starts pushing the audio. I see that in parallel with the TCP data RAAT also sends UDP packets containing “RAATCLKQ” and a sequence number. and the Pi sends “RAATCLKR” which I think is a reply/acknowledgment and I assume also sends back some position in the stream or playout latency info or something.
So while the audio is being sent in a TCP stream seems like the pacing is being done separately using these UDP packets.
What I see on that flow is that at the point where the audio stops you can see that the Wifi is causing problems - TCP ACKs from the Pi back to the RoonServer are retransmitted, and eventually nothing is coming back from the client and the transmission stops. At that point there are 121632 bytes in the unacknowleged TCP window, The Pi was advertising a TCP window of 1434624 so the window was far far from full.
At 21:46:07.944881 we receive a RAATCLKR UDP packet from the client. Roonserver sends further tcp data and clocks but from 21:46:07.952789 it is sending RAATCLKQs only. They also stop at 21:46:08.139105.
At 21:46:08.413734 the RoonServer PUSHes another ACK on the tcp stream - which is normal TCP behaviour where it seems a packet might have been lost from the other side.
At 21:46:08.809478 a whole lot of RAATLKRs arrive more or less together from the client - 56 of them in a row - and the RAATCLCKQs continue again but nothing further is heard from the client until 21:46:18 by which time the Roon server has given up and closed the TCP connection (FIN).
