Headphone Features

Presumably @brian, if you were streaming an MQA file to a Roon remote with private zone (e.g. Explorer 1 which does not have MQA decoding), then the destination zone could do whatever PCM processing it wanted with it?

And, if playing MQA to the analogue output on a Mac running Roon (though why you would want to do this is not clear!), Roon could decode the MQA to 24/192 and then perform DSP on it?

Don’t worry, I’m happy to test lots of combinations!

1 Like

Haha!

Good points.

If the Mac’s DAC is certifed then MQA should correct for it’s abberations (aka noise). I would be excited to see this, but rather buy a Meridian Explorer2 and use a remote (as @Physh360 does…)

Presumably @brian, if you were streaming an MQA file to a Roon remote with private zone (e.g. Explorer 1 which does not have MQA decoding), then the destination zone could do whatever PCM processing it wanted with it?

Sure.

And, if playing MQA to the analogue output on a Mac running Roon (though why you would want to do this is not clear!), Roon could decode the MQA to 24/192 and then perform DSP on it?

A decoded MQA stream is optimized for bit-perfect playback on a known DAC model. It seems unlikely that we would be allowed to light up the “MQA Authenticated” light if we were processing the bits at all.

During authenticated MQA (the bitstream format) playback, MQA (the company) is taking responsibility for the overall quality of experience. In order to do this, they must be in a position to dictate what we are and aren’t allowed to do with decoded MQA streams. At this stage, I don’t have a firm enough idea of what the rules are going to be to comment concretely.

Yes, that an interesting point which brings to mind that the (excellent IMO) cross-feed in the Meridian Prime Headphone Amp is analogue/post-DAC…

Did not know the Prime had a crossfeed. There is no listing for MQA on it’s website?

I would get the Meridian Prime over the McIntosh MHA100 if I knew MQA was an integral feature. Further that Roon has a good relationship with Meridian, the MQA brand, and Tidal. McIntosh is only partnered with Tidal.

This sounds like a rights/legal discussion that will take some time to be able to tell, me, the consumer about. I don’t care. I want MQA and headphone features, best of luck working together through this issue.

[quote=“o0OBillO0o, post:25, topic:2008”]
I would get the Meridian Prime over the McIntosh MHA100 if I knew MQA was an integral feature. [/quote]

It is. The Prime needs a firmware upgrade, but the 4th light on the Prime is the MQA light…

1 Like

Crossfeed would make a big difference to my enjoyment of Roon too (I only listen through headphones).

Crossfeed was a nice to have but is now more critical as I just moved into a condo and don’t want to piss the neighbours off.

It looks like I’m going to have to play Roon through JRiver until some solution is implemented in Roon itself. I hope the JRiver ASIO driver issues have been resolved?

After hours of fighting with JRiver buffers, I finally have Roon feeding JRiver via ASIO with 112db’s Redline monitor VST doing crossfeed and JRiver converting everything to 4xDSD for fun.

I’d do the same with HQPlayer if I could get the VST in there somehow.

It annoys me to no end that you have to stack two players to get the sound that you want (and worse–that what you really want is to stack up three players). It is inelegant and brittle.

For reasons unrelated to audio, but more about product design and architecture, VST/AU are a poor fit in Roon. When I look in my crystal ball, I see VST/AU support as a big piece of work that ends in a product/ux with too many limitations/compromises to make a good experience. I would like to be wrong about that, but the way those systems work is so stuck in the world of pro audio 15 years ago. They did not consider multi-platform, distributed network systems like Roon.

It’s also not reasonable for Roon to be the sole DSP vendor in your life.

We have been thinking a lot about this problem lately. It’s become more acute with RAAT/RoonReady. At least in a PC audio situation you have the option to stack players, but when we own networking all the way to the endpoint, that option goes away. The moment @andybob realized that he wouldn’t be able to use HQPlayer and his RoonReady Aries at the same time, my heart sank a bit.

I have been thinking about this a lot, and pushing discussions forward over here. We don’t know how we are going to address this problem yet, but it is not something that we intend to ignore.

2 Likes

Normally it’s not something I like to do either and yes it’s a very brittle solution. Headphones are the only reason I need it for very obvious reasons.

I hope you guys find a solution of some sort. If Miska would add an optional cross feed dsp in hqplayer all my problems would be solved… :grinning:

How about “Audio Units” in OSX and eventually iOS roonspeaker implementation? I’ll ditch windows if I can use canopener studio AU plugin.

https://goodhertz.co/canopener-studio

AU and VST have exactly the same problems. I can’t put the config UI on a remote, or have any way to let you configure that plugin in a headless install.

I just had an idea about AU/VST…we could build an out-of-process plugin host. Like, a systray/menubar thing that you run on a windows/mac thing somewhere, and then Roon pipes the audio through it over sockets. You have to set up the plugins on the machine doing the processing, not from Roon. In Roon you would just be able to pick them. Or something like that.

It’s a little clunky, but it would work, at least for mac/pc and au/vst.

3 Likes

Sounds good to me, jriver was way overkill for it. I think it would make allot of other people happy that like to EQ etc.

Of course DSD would have to be decoded prior but those doing DSD aren’t wanting any post processing anyway.

Those wanting a solution for AUs on OSX can look at using soundflower and AU Lab, it’s even clunkier than jriver on windows but I just got it working hosting can opener studio.

Yeah, DSD and processing not getting along is an annoying thing, especially when it comes to 3rd party stuff, but so long as we aren’t the source of the limitations, I don’t mind if people use what they want.

We have machinery for DSD->PCM conversions now (it’s recently improved a lot, but we didn’t release the new one in Build 94 because I wanted it to spend more time in alpha). It’s likely that we will eventually provide the reverse path, too, since there’s demand for it and it’s difficult to do using 3rd party plugin systems.

It’s totally debatable whether or not that’s a good idea. From a product standpoint, particularly in the high-end market where luxury trumps sense more often than not, there is something appealing about being able to start and end the chain with DSD even if some processing is required.

It is also possible to do something resembling direct processing of DSD. The technique basically amounts to processing DSD as if it were ultra-high-rate PCM after filtering out the inherent quantization noise. At the end of the processing you end up with a multi-bit signal at the DSD sample rate, and then you re-modulate the signal to create a 1-bit DSD stream again. The key thing with this approach is that you aren’t downsampling it to a typical PCM sample rate, so you can keep the impulse response characteristics of DSD. It is slightly lossy, so you don’t want to build a cascade of these, but many times with music playback that’s not the goal anyways.

Of course if Roon gets built in DSP processing, in particular a good headphone crossfeed I’m happy to. It’s the only DSPing I do.

1 Like

Sounds like a great workaround!

Well I’ve given up using a virtual sound device and hosting an audio unit. I just can’t get it stable in OSX.

I’ve been going through my music collection and using Roon to tag albums I have that are mastered well, aka “Easy on the Ears” roon album tag. :relaxed: I’m going to export these out of roon into another folder and use audirvana and canopener studio dsp until @brian maybe gets us an external hosted dsp engine for Roon as he suggested above.