Songs terminating prematurely - an investigation of streaming from Tidal via Roonserver to a RAAT endpoint

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).

Interesting breakdown - is this an RPI3 or RPI4? I found the WiFi on the 3B unusable but after adding a very cheap dongle I have never had a dropout that wasn’t explained by some other circumstance.

Any RPi’s weakness is the onboard WiFi. Using external WiFi and a usb dac just as bad as both use the USB ports resources. If you really want the best get a windows/Linux based Celeron affect pc or Nuc but a RPi 4 might just suffice too.

@dhusky this is a 3b.

Hi @wizardofoz - I’m not using any USB devices on my Pi. The Dac is an IQAudio DAC Pro hat.

But yes - I think my result is the same as yours. The issue was unstable wifi, it drops off the network for some seconds before reassociating.

I pulled Ethernet through the roof and sanity returned and my music is now working properly again.

I do think that RoonServer could do more to point the finger to the right place. The only error message that is showing says something about “Tidal content loading slowly”, which definitely wasn’t the problem.

Steve

Loading slowly is a bit of a catch all and invariably leads to either an external network issue like DNS delays, network slow or local wireless (typically) bandwidth or stability or possibly EoP adapters causing issues.

1 Like

HI,

I hear you - and see on the Support forum @dylan suggesting all kinds of things since the error doesn’t point to what is really wrong so lots of time has to be wasted guessing and trying things.

So feels like some time at Roon HQ to make more specific error messages saying what did actually happen would help to get much quicker to the real problem.

wish they had a default response in the “Tidal login failed - please restart your Roon Core” that would save about 1 support thread every couple of days :grin:

1 Like