Roon reports incorrect sample rate for 48kHz-sampled AAC stream, and apparently resamples [Resolved - Build 216]

Roon reports the incorrect sample rate (44.1kHz) for a 48kHz-sampled AAC Internet Radio stream, and apparently resamples to 44.1k:

This is a 256kbps, 48kHz-sampling-rate AAC stream (per the configuration setting it up, and confirmed by the info displays when VLC and JRiver play it back), but Roon is somehow pretending it’s sampled at 44.1kHz.

It isn’t just an erroneous signal path display, because based on observing whether or not the DAC does its sample-rate-change click, I believe this is being delivered to the DAC at 44.1kHz.

Thanks Jeffrey,
Let’s drop a flag for @brian to see if he can confirm. Can you provide a link to the stream ?

Sure! The only reason I didn’t in the original report is that this particular stream is one I’m dicking around with the configuration of, and expect I might change or take down or rename in the near future; but I’ll endeavor to leave it up long enough for some testing. Here we go:

http://stream0.wfmu.org/soap.aac

HANG ON: I’m not entirely sure I’ve configured this stream correctly; if some aspect of my audio plumbing is stubbornly insisting on converting to 44.1 on my end, it’s entirely possible I’m streaming something which is actually a 44.1k-sampled stream surrounded by stream metadata claiming that it’s 48k. Still investigating, and apologies for wasting people’s time if I’ve botched this up.

Thanks @Jeffrey_Moore, we were able to reproduce this case, let’s wait for the development team feedback.

Excellent! I’ll feel even better if I hear you’ve reproduced it with someone else’s known-good AAC stream sampled at 48k, because while I think this stream I have up has a decent chance of being as I advertise it, I’m by no means entirely certain yet. I’m currently wandering in a maze of twisty little alsa and liquidsoap passages, and haven’t yet mapped the territory properly.

Hey, guys - I know you’ve just rolled out a metric pantload of cool new code (which I’m very enthusiastic about), but I just wanted to mention that this bug discussed in July of 2016 is still present in Roon 1.3 (build 200) of February 2017. My particular install is RoonServer on Linux.

For either of two 48kHz-sampling-rate AAC streams I just tried, Roon reports something like this:

The streams I’ve tried recently are this one from Sweden:

http://sverigesradio.se/topsy/direkt/132-hi-aac.pls

…and this one I set up (which link I don’t guarantee will be up forever, since it’s a work in progress)

http://stream0.wfmu.org/archie.aac

Both are reported as 44.1k by Roon, both are reported as and played at 48k by JRiver.

[Now… I don’t understand a thing about what goes on under the covers of a lossy codec like AAC or MP3, and honestly don’t know if sampling rate even has the meaning I expect from straightforward PCM formats once something’s been through the mill of AAC encode / decode - do they really do some demonic transform from time to the frequency domain and back again, and if so is the original sampling rate indeed as sticky as I’d assume? - but in my naïve world, I’m conditioned to expect things to come out at the same sampling rate they went in as. Also I think my 48k stream as played back by Roon has an an unexpected edge to the sound, although I haven’t controlled the variables well enough to be really sure about that.]

If a stream not a file, the bit rate – including the sample rate – may be negotiated by the source and the sink. In other words, Roon may handshake on one rate while another player/streamer/component handshakes on a different rate. Perhaps…

AJ

I have this problem also, that the 48 kHz AAC streams from sverigesradio are received as 44.1 kHz.

Also this problem started when I moved the Core to the recommended NUC+Ubuntu+external USB setup to prepare for ROCK.

When I had core on Windows the stream was 48kHz also if I pick the same channel in MP3 the stream is correctly received as 48 kHz.

Thanks for the feedback, this issue is still under investigation.

1 Like

Appears to be fixed in 1.3 (build 216)!

Thanks, guys.

1 Like