HQPlayer / iZotope upsampling + Roon metadata = Killer combo [VST/AU Plugins]

Feedback Feature Suggestions
1

Two bits here:

1- It would be great if Roon could somehow use an iZotope plugin or HQPlayer like filter to upsample. Currently Roon can stream to HQPlayer which in turn plays the stream after upsampling - this works very well. But something a little more integrated that would let Roon route the final stream would be better I think - eg would work with all RoonReady devices.

2- Upsampling algorithms have parameters - iZotope exposes these, HQPlayer likely has parameters but also has many different filter types - and these parameters/filter types can be tuned to the type of music you’re listening to. Roon is in a unique position to include metadata such as provenance, music style, etc, etc that would optimize such process.

Any opinions?

Thx.

2 Likes
2

I would very much like to see this happen.

3

I’ve been having a side discussion about cross-feed for headphones in another thread. I know people also want a way to implement room correction, EQing, the list goes on and on. I know Roon developers want to implement something but I don’t know if they have an elegant way to do it yet that will work cross platform and easily fit into their current design/implementation methodology.

4

Yes good point, I would like any post-processing to be possible. This might be an architectural difficulty for Roon, but if the flow diagram you get when you click on the white dot is any indication of the underlying architecture (which I would expect), then it seems like not such a big lift to allow this to happen.

Obviously this would mean that plugins would need to be available to hook into Roon. Plugins I would be happy to pay for.

Did anyone say “Apple economy”? :astonished:

5

@brian talked about why it’s not so straightforward in reference to Dirac AU/VST plugins, and it seems to apply across the board…

Continuing the discussion from Any plans for convolution and parametric EQ in Roon?:

VST/AU have a very annoying technical limitation:

Both plugin architectures allow plugins to provide user interfaces for configuration, and apps that support plugins generically must display these interfaces. The way that the VST/AU folks chose to do this requires that the user interface be displayed in the same process where the plugin is loaded.

This is a big problem for Roon, since for many users, the server and the UI are running in different processes (RoonServer vs Roon) or different machines, and often not even on the same platform.

It’s frustrating that the vendors of these plugin systems didn’t think bigger, or consider that architectures other than “standalone app with UI” might exist one day.

Anyways, that’s why, as much as we’d like to do it, I don’t think VST/AU are in the near future for Roon.

6

After that discussion, I thought of another potential solution: host the plugin inside of RoonBridge, and pipe the audio through that process. Plugin configuration would happen locally on the machine where RoonBridge was running.

Not perfect, but probably the appropriate compromise for supporting pre-existing plugin systems with architectural limitations.

7 Likes
7

Can’t say I fully understand it, but that’s the thing with genius…

Go on, you know it makes sense, and we have complete faith :wink:

8

Interesting… So what is the RoonBridge in these cases?
1- Roon client running on a mac, Roon Core on a different mac
2- Roon running on a mac streaming to a RoonReady device such as an Auralic Aries

If not VST I think you’d be going into uncharted (and desolate) territory, but I do understand the gripe about people not thinking things through.

9

It’s only a compromise in that the implementation would only work with Windows and OSX RoonBridge hosts.

10

Isn’t RoonBridge the new name for RoonSpeakers? I assumed it’s a software endpoint for Windows, OSX, and eventually mobile as well.

If my assumption is correct. 2. wouldn’t work as the endpoint is the VST/Audio Unit host.

11

Firstly I have to say I don’t know how VST plugins work. But given these things can be concatenated (such as in SampleManager which I use), what stops you from doing something like:

Roon => VST plugin => Roon (same Roon process) => RoonBridge

That is, I expect that the VST plugin takes in a PCM stream, massages it, returns the stream to Roon, which then carries on just as if there was no VST massaging in between…

Obviously I am missing something…

12

It’s only a compromise in that the implementation would only work with Windows and OSX RoonBridge hosts.

Yeah exactly.

If you’ve got a Linux-based server, it would need to pipe the audio over to a mac to apply headphone processing/etc in an AudioUnit, pipe it back to the Linux machine, then distribute it.

You would also need to be in front of the machine that hosts the plugin if you want to play with plugin settings. So no adjusting VST/AU parameters on the iPad from the couch.

There’s no loss in fidelity there, and it should all work OK…it’s just a little bit hokey for the multi-room/whole-home use cases because we’re integrating with legacy plugin systems that weren’t built for distributed apps like Roon.

Isn’t RoonBridge the new name for RoonSpeakers?

Concretely, that’s what RoonBridge does right now.

Abstractly, RoonBridge bridges some of Roon’s capabilities onto a device that isn’t running the Roon Core.

Unless we want to create yet-another-package to download, install, and keep up-to-date, It’s the most logical place to put this sort of capability.

13

It’s already been decided hosting VSTs and Audio Units in Roon itself isn’t going to happen, these plugins have custom configuration screens that don’t confirm to their user interface design standards and simply wouldn’t work from the mobile apps.

Not putting words into Brian’s mouth, I think RoonBridge is rather unique to it’s host so having implemtations for Audio Units or VST plugins on the osx version and vst plugins on the windows version is something they could live with .

14

Obviously I am missing something…

There are two architectural friction points:

  • VST and AU plugins have built-in user interfaces for settings/tweaking. They do not provide a way to display the user interfaces in a different place than where the audio processing takes place. Meaning, we couldn’t run the plugin on the server and show you the settings screen on an iPad.

  • VSTs run on Windows + Mac. AudioUnits run on Mac only.

If you use Roon like you’d use Audirvana or Foobar, these won’t seem like a big problem. Everything you’re doing with Roon runs on one machine, and the plugins run there too. This use case should work out roughly the same as what you’re used to.

But, our vision is a lot bigger than that, and we need to consider all of the configurations we support now, as well as the ones we plan to support in the future.

Roon’s Core runs on Macs, Windows, Linux, and Appliances. Remote controls run on Mac, Windows, Android, and iOS. Audio outputs run on all of the above.

The most sensible place to put audio processing is in Roon’s Core. It’s where the most CPU horsepower is likely to be available. But that’s not possible in general–Roon’s core is frequently run without any user interface (RoonServer), and it runs on platforms where VST and AU don’t work, and on locked-down appliances that might not allow plugin installs even if the plugin were compatible.

The solution I proposed is to let the plugins have the illusion of a “one PC/Mac + one app” world by making the plugins part of RoonBridge. Why RoonBridge? It runs on PCs and Macs, it has a user interface, and it’s involved in audio processing already–these are the things you must have if you want to host VST and AU plugins.

Not putting words into Brian’s mouth, I think RoonBridge is rather unique to it’s host so having implemtations for Audio Units or VST plugins on the osx version and vst plugins on the windows version is something they could live with .

Yeah, you’ve got it.

2 Likes
15

I very much welcome the idea of having plugin support, it adds much more flexibility. Though HQP can be used for EQ or room correction, for anything more sophisticated, I had to turn to Jriver (Roon -> Jriver ASIO-> Jriver VST plugins -> DAC). And if I wanted a good upsampler , I would also try (Roon -> Jriver ASIO-> Jriver VST plugins -> foobar_dsd_asio -> DAC).

How do you envision handling DSD streams at RoonBridge if it is going to be put through a plugin?

16

How do you envision handling DSD streams at RoonBridge if it is going to be put through a plugin?

Neither neither VST nor AU support DSD processing explicitly. VST makes a hard assumption that samples are 32bit floats. AU is more flexible, but not DSD aware to my knowledge.

If the goal were DSD input + output with plugins in the middle, that might look like DSD Stream -> LPF -> VST/AU plugins -> S-D modulator -> DAC. Assuming the plugins will accept those sample rates and can keep up, there’s nothing infeasible about doing the rest of it in real-time. This general processing trajectory is described in some more detail in in this paper.

Downsampling to high-rate PCM prior to the plugins, then sticking with PCM the rest of the way is another option.

17

@brian Thanks for the reference.

The reason I had raised the question regarding DSD was to see what approach you would take, RoonBridge would implement 1) LPF + remodulation , 2) downsample to PCM or 3) not support DSD while using plugins.

18

I don’t think we would ever release (3)–it violates the basic principle that all content must play on all zones somehow.

For the most part, I prefer (1). Ideally we’d be flexible enough to allow for both (1) and (2). The best choice might vary based on the plugin and DAC in question.

19

Firstly, thx Brian for such a clear and concise answer.

[quote=“brian, post:14, topic:8113”]
The most sensible place to put audio processing is in Roon’s Core. It’s where the most CPU horsepower is likely to be available. But that’s not possible in general–Roon’s core is frequently run without any user interface (RoonServer), and it runs on platforms where VST and AU don’t work, and on locked-down appliances that might not allow plugin installs even if the plugin were compatible.[/quote]
Is it at all viable to develop an API that allows for plugins that will:
1- Support any stream (PCM, DSD, or otherwise)
2- Have a “describe” method so the plugin can self-describe the parameters it requires so an interface can be rendered anywhere
3- Have the ability to store configurations in the metadata of songs/albums/etc
4- Have the ability to script such configuration - eg if genre==“classical” use these iZotope params
5- Roon might (eventually) be able to provide metadata for optimal iZotope/HQPlayer parameters based on provenance, etc.

Obviously this API would not be the current VST/AU but Roon-specific. People such as iZotope/Signalyst/etc could not only provide such plugins (and be payed for this) but also provide optimized configurations.

20

Technically viable? Sure, for the most part.

From a business standpoint, I don’t think an “app store” of DSP plugins for Roon users would create enough incentive for DSP vendors solely take on the risk of developing plugins. It’s more likely that we would end up doing a lot of the integration work and would have to work with pre-existing plugins in their current state.

Let me do a little discussion on each point:

Support any stream (PCM, DSD, or otherwise)

Sure…individual plugins would only support a subset of the available formats, but the system as a whole could support many.

Have a “describe” method so the plugin can self-describe the parameters it requires so an interface can be rendered anywhere

There are compromises here. Offering them a whole platform-independent remote-display-capable UI toolkit is literally man-years of work. You could do something based on web technologies (with one set of compromises). You could do something based on a simple set of parameters (with another set of compromises). This is a difficult problem.

Have the ability to store configurations in the metadata of songs/albums/etc
Have the ability to script such configuration - eg if genre==“classical” use these iZotope params

How to switch on/off DSP based on content is a tricky, tricky product question. If you’re used to thinking about single-zone apps like Audirvana/HQPlayer, it may not seem that way at first.

Some DSP choices are related to the content.
Some DSP choices are related to the room/environment.
Some DSP choices are related to the DAC.
Some DSP choices only make sense when certain capabilities are present elsewhere in the playback chain.

Attaching a DSP chain to a music file or genre isn’t a powerful enough concept to meet all four kinds of constraints.

Lets say I have four zones:

  • AirPlay speaker (44.1k pcm only)
  • 2ch system using DSD-capable DAC with Room Correction
  • 2ch networked Meridian system (max 96k PCM) that supports MQA
  • DSD-capable Headphone amp in conjunction with DSP crossfeed plugin that only supports PCM sample rates

And three pieces of content:

  • Bernstein/Mahler (DSD64), which wants a linear-phase up-sampling filter
  • Nirvana - Nevermind (Redbook), which wants a min-phase apodizing up-sampling filter
  • Mozart Violin Concerto (MQA-encapsulated FLAC), which can’t endure DSP without undoing MQA’s benefits.

So we have 12 combinations. Neither the room, nor the content can completely describe the “right thing” to do in each situation. AirPlay can’t do up-sampling (it’s pegged to 44.1k). The Redbook content wants an apodizing filter to remove mastering artifacts, but the DSD64/MQA files don’t need it. The headphone zone needs to have its plugin driven by PCM, but might want an up-sampling stage post-plugin so that the oversampling in the DAC can by bypassed. When playing back MQA through the Meridian system, you may want to use MQA/Meridian up-sampling and not your own even if the usual playback chain for the zone does up-sample.

It’s a complicated world. The media-related concerns sort of “cut across” the design of the playback chain as a whole. They mean something more like “if you happen to be up-sampling in this playback chain, these are my preferences” than “use these iZotope parameters”.

I’m not sure what this is going to look like. We are thinking about these problems. I don’t think a simple “content-based switch” or “genre-based switch” is going to be powerful enough.

Roon might (eventually) be able to provide metadata for optimal iZotope/HQPlayer parameters based on provenance, etc.

Sure, or our users could do it. It would be nice if DSP configurations could be easily shared. No reason to centralize us as the source of advice.

2 Likes