Roon 1.2 (128) plays TIDAL AAC 22.05kHz 16bit 2ch wrong[Ticket in]

Many (seems that all, but not completely sure) records from Tidal which are served in AAC 22.05kHz 16bit 2ch do not play correctly - they play too slow (so with too low pitch). Example: Oddatteee “Steely Drakglasses”, U-Cef “Halalwood”,

Roon server is installed on Linux and playing to builtin ALSA card.

This problem does not occur for 44.1 kHz FLACs.

A bug in sample rate conversion perhaps? This is a step shown between the source and RAAT.

Also, just noticed: Tidal AAC 48kHz 16bit 2ch do not play at all - the player goes into state “beginning playback” (0:00 time mark on the progress bar), but the playback does not start (and there is no sound, and the progress bar does not move).
After such playback attempt, no future attempts to play music succeed:

  • from Tidal (even normal FLAC albums that played a moment ago) fail - the player goes almost into “playback” state (on the progress bar there is a blur of color going back and forth and the time marker does never appear on the bar)
  • from local files - the play button in in the “playing” state, playback does not start, time marker (this tiny ) does not appear on the progress bar.

Restart of Roon server is required to restore the playback capability.

Hey @Grzegorz_Grudzinski,

  • Would you mind to tell us what country do you live in?
  • Can you also paste here links to tidal albums which Roon can’t playback at normal speed?

Thanks in advance.

I don’t mind providing any information which may help in solving the problem!
I live in Poland.

The links are:
Oddateee “Steely Drakglasses”:
U-Cef “Halalwood”:

Unfortunately I did not write down links to albums in AAC 48kHz, but if I find one, I will post it here.

If you need my logs, I will be happy to provide them.

For me, Tidal AAC 22.05kHz tracks won’t play at all. The signal path briefly appears (I took a quick picture of it)

and then goes away.

For me they play with exactly the signal path shown (and the output is wrong). Also there is a funny thing - the calculation of the length is wrong, so the actual progress bar is rendered twice as the space for it allows, drawing over the UI (on iPad).

For AAC 48kHz, the signal path displayed is simpler - no upconversion step - but it does not even start playing, staying at 0:00 (as I mentioned in my first post).

Thanks for the report guys – we’ve reproduced and opened a ticket in our bug tracker. We’ll take a look at this soon.

If it helps, I found some records on TIDAL with AAC 48kHz, all so far cause Roon to stop playing until a restart.

  • a video of Gorillaz “Dirty Harry (feat. Bootie Brown)”: (it’s a bit funny that Roon does not show that some singles are actually videos?)

  • another video (actually, all of videos of Danger Mouse): this one for instance h

The funny thing with the indicator of quality is that once it lights up for playback of 48kHz AAC, it stays on even if you stop the (non-happening) playback - until Roon server is restarted.

I checked that it does not matter what playback backend is selected, all the symptoms are exactly the same (only the signal path is different, given below):

  • AirPlay - the signal path is Source (TIDAL AAC 48kHz 16bit 2ch) -> SRC (48kHz to 44.1kHz) -> Truncate (24bit to 16bit) -> Output (AirPlay Streaming), and it seems to be the same for all such files

  • local Alsa - the signal path is simpler in this case: Source (TIDAL AAC 48kHz 16bit 2ch) -> RAAT -> Output (Alsa).

5+ years later I can experience similar problems with AAC content:

According to Roon that’s TIDAL AAC 22.05kHz 24bit 2ch. Roon is unable to play them via Airplay and Squezebox bridge. Such tracks are being stopped or playback stops at 0:00.

Is there any way to make Roon properly treating such content?


Roon 1.8 build 806 on QNAP.

FYI for Roon Labs. From Lumin Tidal Connect, it’s actually AAC 44.1kHz.

HEOS native apps plays it as AAC 96kbps but I’m not sure whether it performs any transformations on the way.

Is there any effective way to contact Roon support? This one doesn’t seem to work…

As there is already a ticket so support already knew, you just need to wait.

The same behavior on 1.8 build 814.

Is that normal that there is no answer from support for such a long time also for a paying customers or am I treated specially as a Trial user?

That was ffmpeg-related problem.

Replacement of ffmpeg from QNAP distribution to the latest build resolved that problem.
Anyway I’m more than a bit disappointed that nobody from Support responded to that thread :frowning: