Surround channels misplaced on AU but they are ok on AAX

Hi, I’m stuck on a problem a long time now and I don’t seem to find the reason on any similar topic.
On a multichannel (5.1 surround) pluggin I get misplaced output channels on AU. It seems to have L|R|Ls|Rs|C|LFE outputs order. Printing getCurrentLayout().getSpeakerArrangementAsString() I get t L R C Lfe Ls Rs
When I’m building for Pro tools it seems to be everything in the right order.
I tried to follow the Surround plugin example, which it works fine, but I don’t know what I’m missing.
Maybe I should use different process block for different DAWs?

Best use the helper functions and never assume a certain order of the channels:

auto* bus = getBus (false, 0);                 // returns main output bus
const auto& layout = bus->getCurrentLayout();  // returns the AudioChannelSet
int index = layout.getChannelIndexForType (AudioChannelSet::left); // index in the channel set
int pIndex = getChannelIndexInProcessBlockBuffer (false, 0 index); // finally index in your buffer in processBlock

Every time you have more than 2 channels it is worth to go the long route to be safe…

Good luck

1 Like

Thanks for the fast reply. Those functions are great indeed :slight_smile: but in this case I got the same results
Left channel index – 0|| process block – 0
Right channel index – 1|| process block – 1
Center channel index – 2|| process block – 2
LFE channel index – 3|| process block – 3
LeftSr channel index – 4|| process block – 4
RightSr channel index – 5|| process block – 5

and the outputs I got from logic are in L R Ls Rs C LFE order

JUCE always uses the same channel order internally no matter if the native AU/VST/AAX layout has a different order. JUCE’s plug-in backend will always re-order the channels for you. The “JUCE channel order” is always in the order in which the channels appear in the ChannelType enum list here.

So for 5.1 surround sound, the channel order of the buffer in your processBlock callback is always: L R C Lfe Ls Rs - regardless of DAW or plug-in type.

If you are getting an incorrect layout in some DAW then this is likely to be a JUCE bug (or DAW bug). I’ve just tested 5.1 Surround in Logic Pro and the channel ordering seems to be working fine.

Yes indeed, with the Surround example found in example folder seemed to work fine, so no bug for juce. I don’t know why my write buffer is reordering the channels in logic, without doing enything fancy, just passing some values to test the channels

Were you able to solve your problem? We are experiencing the same issue and haven’t been able to find a solution. Since the Surround example plugin works correctly, we have been searching for a difference but haven’t been able to find anything.

The error is not our buffer copying, because the channels are already out of order in JuceAU::Render() before processBlock() has been called.

We have verified that the following things are the same between the Surround project and our plugin:

  • channelInfo returned by AudioUnitHelpers::getAUChannelInfo()
  • number of input and output buses, and the number of channels in each
  • mapping of chIdx to outLayoutMap[ch] and inLayoutMap[ch] used when setting buffer pointers
  • channel mapping and variables used in CoreAudioBufferList::push() when copying input
  • default BusesProperties used upon initial construction of AudioProcessor

It seems like there must be some setting or assumption that is different between the example plugin and ours, but we haven’t been able to find it. The only difference we’re seeing is the order of the channels.

Any help or ideas to look into would be greatly appreciated.

Hey @fabian, do you have any thoughts on this?

Hey, sorry for the delayed answer, I remember solving it by installing an updated version and re-initiating my project.
I hope this helps,

Not really sure what could be causing this problem. Do you have some minimal code which reproduces the problem? Also note that if you are seeing this problem within Apple’s auval then have a look at this thread which was a bug in auval which was only recently fixed in 10.13.3.

I think we’ve found the discrepancy in our surround project: we needed to explicitly check !isDiscreteLayout() on both the input and the output in isBusesLayoutSupported(). Additionally, the AU cache must be cleared / rescanned for any changes in this function to be picked up by Logic.

Would it be possible to make isDiscreteLayout()'s purpose a little clearer in the documentation? It’s pretty sparse at the moment. Also, does it make sense that we’d need !isDiscreteLayout() for the surround channels to be correctly identified?

Yes, that makes complete sense. I’ll update the documentation.


The documentation of create5point1 states a channel order (L R C Ls Rs Lfe) different than you mentioned (L R C Lfe Ls Rs). Which one is correct ?

That latter one is correct. I’ll fix the documentation as well.

The AAX format seems to be different:
AAX_eStemFormat_5_1, { AudioChannelSet::left, AudioChannelSet::centre, AudioChannelSet::right, AudioChannelSet::leftSurround, AudioChannelSet::rightSurround, AudioChannelSet::LFE, AudioChannelSet::unknown, AudioChannelSet::unknown, AudioChannelSet::unknown, AudioChannelSet::unknown } }

No. That’s the channel order in AAX, but not the JUCE channel order. The explanation in this post is correct:

The AAX wrapper uses create5point1 but I don’t see where the order is handled differently.

I don’t quite see what your issue is. The AAX wrapper (as all the other wrappers) take care of re-ordering the channels to JUCE channel order. What is the specific problem you are having?

For example, in AAX, the re-ordering is happening here and here. But as I said, in my post above, you needn’t worry about that the internal AAX/AU/VST/VST3 channel order, as the channel order that your audio processor sees, will always be in the same order as the AudioChannelSet enums are defined.

Right, just found that in the wrapper, thanks !