Channel Layout bug in DaVinci?

#1

I am running some tests in DaVinci and its channel layout on adaptive tracks.

When adding 5.1 audio to a 16-channel track (channel by channel), I get volume in channels as follow:
0 - Left
1 - Right
2 - C
3 - LFE
4 - ?
5 - ?
6 - ?
7 - ?
8 - Lss
9 - Rss

The same way, if I make the track 18-20 channel, I get the following results:
0 - Left
1 - Right
2 - C
3 - LFE
4 - Left Surround
5 - Right Surround
6 - ?
7 - ?
8 - ?
9 - ?

Mind you, both the 16 channel and the 18-20 channel track report EXACTLY the same characteristics

Type: Uknown, 
Layout: L R C Lfe Ls Rs Lc Rc Lss Rss Tfl Tfr Trl Trr Tsl Tsr

And yet, channels 4 and 5 go through Lss Rss if the track is 16 channels, and through Ls Rs if it’s 18-20

So either I am doing something wrong (doubt it? In all DAWs it works fine), or there’s a bug in the channel layout when it comes to DaVinci.

Any help would be appreciated.

The code I tested on to monitor each channel’s volume, in processBlock:


    auto lol = getChannelLayoutOfBus(true, 0);
    auto tracks = lol.getChannelTypes();


    DBG(lol.getSpeakerArrangementAsString());
    DBG(lol.getDescription());
    DBG(
        "0 " << buffer.getMagnitude(lol.getChannelIndexForType(tracks[0]), 0, buffer.getNumSamples()) << " || " <<
        "1 " << buffer.getMagnitude(lol.getChannelIndexForType(tracks[1]), 0, buffer.getNumSamples()) << " || " <<
        "2 " << buffer.getMagnitude(lol.getChannelIndexForType(tracks[2]), 0, buffer.getNumSamples()) << " || " <<
        "3 " << buffer.getMagnitude(lol.getChannelIndexForType(tracks[3]), 0, buffer.getNumSamples()) << " || " <<
        "4 " << buffer.getMagnitude(lol.getChannelIndexForType(tracks[4]), 0, buffer.getNumSamples()) << " || " <<
        "5 " << buffer.getMagnitude(lol.getChannelIndexForType(tracks[5]), 0, buffer.getNumSamples()) << " || " <<
        "6 " << buffer.getMagnitude(lol.getChannelIndexForType(tracks[6]), 0, buffer.getNumSamples()) << " || " <<
        "7 " << buffer.getMagnitude(lol.getChannelIndexForType(tracks[7]), 0, buffer.getNumSamples()) << " || " <<
        "8 " << buffer.getMagnitude(lol.getChannelIndexForType(tracks[8]), 0, buffer.getNumSamples()) << " || " <<
        "9 " << buffer.getMagnitude(lol.getChannelIndexForType(tracks[9]), 0, buffer.getNumSamples()) << " || "
    );

Any ideas?

#2

Could you please provide the following information:

  • Are you using the latest available version of Davinci Resolve?
  • What platform are you using for testing? (mac/windows/linux)
  • What plugin format are you testing? (AU/VST/VST3)
  • Have you tested the develop branch of JUCE? If not, please do so.
#3
  • Latest version of Resolve, yes
  • Win, VST3
  • VST3
  • I think I am (total noob, I tried with 7.0.3 and then replaced all the files with the latest Dev branch, is that the proper way?)
#4

total noob, I tried with 7.0.3 and then replaced all the files with the latest Dev branch

Are you using git? If not, you’d be in better shape if you did. Once you clone the repo, you would call git checkout develop. If you’re new to this, you can use a front end like SourceTree or the liking.

#5

Thats what I thought, but the Dev branch doesnt have an .exe to run Projucer, so this is why I didnt clone it, I assumed using the existing 7.0.3 .exe and simply replacing would work. I’ll go the git way regardless, thank you!

I hope the Resolve issue can be…resolved :smiley:

#6

This looks like a bug in DaVinci Resolve.

To notify the plugin of the current bus layouts, the host should call setBusArrangements on the plugin, passing a Vst::SpeakerArrangement for each bus. When debugging, I see that for adaptive tracks with 16 to 21 channels, the host always passes a speaker layout of 0x302d6ff, which has 16 bits set and corresponds to a 9.1.6 layout. When selecting 22 or more channels, the requested bus layout changes to 0x7307ffff, which is a 24-channel layout. Given that the host and plugin disagree on the number of channels, I think it’s inevitable that some channels will be silent, or missing completely.

I’ll try filing a bug report and report back here if I get any response.

#7

Interesting! Thanks for checking this out!

To expand on this, I am trying DaVinci Resolve Studio (with Atmos support), and the same happens in Atmos tracks (7.1.4, etc) - the weird thing is that it’s only in the “incoming” channels, above channel 4, they get ordered wrongly, however, the channels my plugin outputs are ordered correctly.

So my plugin receives the wrong order, but the order it delivers is placed right.

#8

I’ve debugged this a bit more now. I took the following steps:

  • I created a 16-channel adaptive audio track.
  • I added a stereo audio clip to the project’s media pool.
  • I opened the clip’s attributes window, went to the Audio tab, and changed the clip format to be 24-channel adaptive. In the table below, I moved the clip’s audio channels 1 and 2 to play on channels 5 and 6 of the track.
  • I added a copy of SurroundPluginDemo to the track, and then paused the debugger in the plugin’s tresult process (Vst::ProcessData&) function.

When the track has 16 channels, I see that Resolve provides a 16-channel bus with all channels silent other than 5 and 6.

When I change the track to have 18 channels, Resolve continues to provide a 16-channel bus, but with the incoming audio on channels 9 and 10.

That is, the channel mapping behaviour you’re seeing is due to the order in which Resolve is providing channels to the plugin. It’s not due to any remapping that’s happening in the VST3 wrapper.

I’m not sure why Resolve is choosing to provide the channels in this order. I recommend contacting the support team for Resolve.

#9

I have come in contact with BlackMagic, too. Hopefully with good news :slight_smile: