Is this ARC resampling necessary?

I agree you can’t cover every possible permutation here but I think it could do better in certain circumstances.

I remember reading about this when arc was in beta.

Here is a quote from @brian, I think he may be high enough in the chain to be considered a good source. It was from Jun ‘22. I’m assuming it’s ok to post this as there is no secret info. I’m sure he has enough pull in the company to remove the post if he’d like.

Brian Luczkiewicz Roon Labs Founder

There is no perfect option, but we definitely put some thought into this.

There are really only four choices for lossy codecs:

  • MP3
  • Vorbis
  • Opus
  • AAC

AAC was eliminated immediately because we cannot afford to pay for an AAC encoder license for every existing Roon Core on the day we release this product. So that one is simple, at least.

It’s important to separate your experience using Opus for voice from what we are doing here. I’m not exactly sure why they jammed SILK and CELT into one thing called Opus, but they are totally different animals.

SILK is optimized for voice, ultra-low bandwidth, low latency, packet loss handling, etc. Not right for our application.

CELT is Vorbis-next. It’s optimized for music like Vorbis is. It’s much more conservative and less weird because it’s trying to solve a significantly less constrained problem than SILK.

In the measurements that we found from others and in our investigations–

  • At higher bitrates (say ~256kbit), Opus/CELT appeared to roughly match AAC and was superior to MP3 and Vorbis
  • At lower bitrates (say ~96kbit), Opus/CELT was the clear winner

Having a low-bandwidth setting (and making it as good as possible) is important. Sure, the quality-focused people won’t use it, but many people pay for metered data and need to manage that, and others have more restrictive quality bottlenecks like automotive systems, bone conduction headphones, etc.

The only real negative we could find with Opus, other than the fact that people aren’t as familiar with it, is the 48kHz requirement. As it turns out this is not much of a downside because we live in a 48kHz world.

The OS mixer on your iOS or Android phone? 48kHz. Your USB/Lightning to 3.5mm adapter? 48kHz. Your brand new shiny Mac? 48kHz unless you change the setting by hand. Same with a Windows laptop. 48kHz is the standard for hardware unless you’re tweaking settings on a PC/Mac or using an audiophile-oriented DAC.

Once you realize that sample rate conversion is an inevitability for 44.1kHz content 99% of the time, there are two ways to get it done–

  • Use a high-quality (but not very energy efficient) sample rate converter in the Roon Core prior to the Opus encoder, and have the device decode straight to 48kHz, which is preserved all the way to the output.
  • Encode at the original sample rate in the Roon Core, then pass it to the phone and let the OS resample it using a sample rate converter optimized for energy efficiency over quality.

We went with the first one because it wins in terms of both sound quality and battery life. So while I’d like Opus a little bit better if it weren’t pegged to 48kHz, for our application it is not a major downside. The people who are tweaking at the level that gets them a clean 44.1kHz output path on an Android or iOS device would probably be better served by avoiding lossy codecs entirely.

If it wasn’t Opus, it probably would have been Vorbis. If AAC was not patent encumbered it probably would have been AAC. MP3 only really won one column–ease of implementation.

As for who else is using it–the main example I can think of is PlexAMP, which will be one of ARC’s main competitors :wink:

1 Like

Thanks. I did go back and read this one. The devil is in the details, and they don’t specify the most important aspect of the decision: how they compared those codecs. I agree that newer codecs like AAC are better than MP3, but only at lower rates. Once you reach 256kbps, you can’t really squeeze any audible difference anymore.

Yeah but clearly they wanted to maximize quality at lower bitrates

Having a low-bandwidth setting (and making it as good as possible) is important.

2 Likes

So what is going on here then?

Seems to be broken. Looks like it resampling to the os native first then from that to Bluetooth 44.1. I am sure it’s not supposed to do that. Are you on the early access build with the new DSP engine?

1 Like

No I’m on production. Ironically I bailed on Early Access due to the lack of stability!

If the Android audio subsystem requires 48 kHz and the Bluetooth audio stack requires 44.1 kHz, how is that multiple sample rate conversion “broken”? That is the way it is. If that is a problem, do not use Bluetooth. Or use Bluetooth with hardware and codec support for 48 kHz.

AJ

1 Like

Just curious: why is bit reduction from 64 to 24 performed before the last sample rate conversion?

1 Like

Well it’s iOS if that makes a difference. But it’s broken because it is performing a totally unnecessary conversion since the source is already 44.1, there is no need to convert to 48 at all. Broken logic there. Additionally other tracks in the same format don’t do it, it happens occasionally for some opaque reason.

Edit: for example

1 Like

Because it’s broken?

I have never seen it do it on my iPhone.

No Roon knows what the BT takes so no need to make it 48/24 as it misses out the internal DAC completely with BT connected so it’s an unnecessary step. I have had ARC sending 96/24 directly to an LDAC device via BT and no intermediate to 48/24 was involved. Bit depth conversion I get as it likely decodes mp3 to 24bit like full Roon does.

No such conversion here on iPhone.

1 Like

I see it often enough to notice. Just adds to the feeling that ARC is more demanding to run than it needs to be at times.

I don’t check mine often really but I have only seen an extra step when it’s a 24bit source like when it sends Opus. But somethings off with it as it should be consistent as to what it is actually doing.

1 Like

Necessary sample rate conversion has nothing to do with the DAC. It is because the mobile OS audio subsystem operates at a fixed rate, usually 48 kHz. That fixed rate is necessary for the OS mixer to incorporate phone audio, notifications, etc.

AJ

Well sorry but Roon nor Arc shows no resampling to 48 via BT at all. Here’s Roon to same headset at i showed from ARC.

Same track via ARC

Same track to speaker will resample as expected
.

The behaviour reported above is not correct.

1 Like

You suggested that mobile OS resampling had something to do with the internal DAC. That was wrong. I corrected it.

I do not know exactly what is occurring or not occurring in some of these mobile OS examples. What is true, though, is that sample rate conversion outside of Roon is not always visible to Roon. To illustrate on a desktop OS, try playing to the OS mixer. Roon will not display any resampling, but resampling to the OS internal audio rate is happening, as can be evidenced on an external DAC display.

AJ

Also, see Brian’s quote reposted earlier in this very thread:

AJ

I know all that commented on it several times in this thread. But Roon shows nothing for BT if it’s a 44.1/16 source as we have shown. I don’t care what happens in the iOS BT stack outside of Roon, but Roon or ARC doesn’t display a sample rate conversion for BT connections unless it’s the wrong sample rate or bit depth it supports.Yet it did show a spurious resample for a 44.1 mp3 which is what we have been on about in Tims example.

1 Like