I want to say that, with the new v1.7 version, there are still issues with mapping 5.0 channel recordings to a 5.1 or 7.1 channel output if a Procedural EQ and/or a Parametric EQ is introduced into the signal path.
I checked our bug tracking system and I see a ticket similar in nature to the issue you are describing. It would be helpful if you could provide clear reproduction steps, along with the “expected” behavior and “observed” behavior as far as the channel mapping is concerned, so that we can get these reports merged and in front of the dev team.
I am using an exaSound e38 8-channel DAC connected by USB and using the exaSound ASIO driver. The output is set in Roon for 5.1 because I have only 5.1 speakers even though the DAC can support 7.1. If I set it for 7.1, the results are the same.
With 5.1 source files (DSF or FLAC), the channels map correctly without fault.
With 5.0 files (the most common MCH format of modern classical recordings), the channels re-map to the standard 5.1 output format correctly, if there are no filters/EQ in the signal path.
If I introduce a procedural EQ (add bass management) and/or a parametric EQ, the mapping of FL, FR and C are correct, LFE gets SL, SL gets SR and SR is silent. The drop-down signal path show that there is re-mapping before and after the filter(s).
BTW, what I was attempting was to implement bass management for which all the tools necessary are available in Roon. It would be great if you could implement a DSP option for bass management so every user will not have to re-invent the wheel.
Thanks again for the clear reproduction steps, I was able to get this in front of the development team for comment. They confirmed that Roon is behaving as designed in the outlined scenario, and asked that I open a feature request ticket for the functionality you are requesting.
Digging deeper, Roon’s Parametric EQ Mix feature needs to work in a multitude of different setups and does not have visibility into previous or proceding DSP operations. Having the Mix behavior change based on previous DSP operations opens up a can of worms that could break the Mix channel mapping in other ways.
As mentioned, a feature request ticket has been opened containing an outline for the behavior you’re requesting. In the interim, you may be able to reduce the friction encountered when playing 5.0 content by using Roon’s DSP Presets feature. You could dave a DSP Preset with the desired mix settings for 5.0 content and another preset for multichannel content with a LFE channel. You will be able to switch between presets on the fly on all platforms, including the Roon Remote app on iOS and Android.
When I look at the signal path, there is a clearly implied orderly sequence of steps, a pipeline. Is this not so? and, if so, changing the order of those steps is all that is is necessary. If that is not so, what does it mean? Also, the exact operations of channel mapping steps that Roon inserts are not revealed.
Thanks. I look forward to a satisfactory resolution.
Not a useful suggestion, imho. This means that I would have to anticipate what channel maps are used by each recording I want to play and then, during playback, invoke a switch. C’mon. The most common discrete multichannel format for classical music is 5.0. Getting it to play properly should be a given or, at least, a high priority.
FWIW, here is the reason for me to bring this up again:
I searched the roonKB and found this:
…Most musical content produced recently is either in either 2.0, 5.0 or 5.1. There is a small amount of 7.1, too, and a small amount of Quadrophonic content. Compared to these four formats, practically everything else qualifies as exotic in an audio/music context.
Channel mapping for 2.0, 5.0, 5.1, and 7.1 is straightforward, since each larger layout simply adds channels to the previous one. In these cases, Roon matches up the channels from the source material with the channels on the output device and fills any unused channels with silence…
Unfortunately, that is not so. I have raised the issue with them and they were able to reproduce the anomaly as I have described it:5.0 channel re-mappingIt is not an issue if one does not do any procedural filters in Roon.However, in order to use the DAC8 Pro in multichannel, one must (as you have indicated) configure it as a 7.1 (8channel) DAC. T
The consequence of this is that, to play it in a 5.1 system, one must set a procedural filter to divert Surround L/R signals to the Back L/R outputs. The result is that one gets incorrect mapping with or without the diversion of the Surround L/R. Either you get only the front L/C/R channels or you get front L/C/R + LS in the sub + RS in the LS speaker and nothing from the RS speaker.
Do you experience the 5.0 issue on both Windows and Linux? If so this is probably a channel mapping issue in Roon.
@mitr (thanks for the response).
I was wondering if that was possible - but how do I do that?
I have the DVD-A which has been ripped with DVD-Audio-Extractor & only shows that it’s a 5-channel 96/24 source file (on the disc) and then rips to a 5-channel FLAC file, but I don’t know how it formats the file to show this crucial information. I don’t see the relevant information in the metadata when I use MediaMonkey - or how to modify the data.
Which other tools are available for checking the FLAC file ‘construction’ / metadata & can be used to change 5.0 to 4.1 or to 5.1?
And wouldn’t adding a ‘silent’ channel actually necessitate adding data - an ‘empty’ channel stream?
Also, my Oppo can clearly send a 4.1 stream (perhaps including some phantom or ‘empty’ channels) through to my 861v8, so I know it’s possible & works…somehow…
The question remains however: @support why does Roon down-mix the 5.0 (or 5.1 or whatever) stream to 2.0 when I explicitly tell it not to?
The ID41 input card (which is what Roon ‘sees’) is 2-channel as is another connected device - my Meridian 218.
The answer is therefore to play this file through my Roon Core (i7 NUC) over HDMI into the multi-channel UHD722 and onward into the 861v8.
Off to give it a try, although I’m pretty sure I’ve been through this loop before…
@John, you wrote that a feature request ticket had been opened, but as I understand the reported issue, it’s a matter of getting a supported format to play correctly rather than adding new functionality. Any update on whether/when this fix might happen?