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.