[JUCE4.3] Hosting a plugin with bad number of outputs channels

Audio Plugins
1

Hi everybody,

I came here to share with you a problem that i encounter and maybe found an answer to this problem.

I’m currently working on a plugin that host other plugins and I’m facing a problem when hosting the UVI’s plugins Workstation and Falcon in Audio Unit Format (no problem in VST format).
Indeed, when hosting Workstation, no sound come from the plugin anymore and the CPU consommation is just excessive (about 160% of my processor when only 3% is used with the VST version of Workstation).

After digging deeper into the code to found the origin of this bug, I’ve found that the Workstation that I’m trying to host has 53472 output channels in Audio Unit format whereas it “only” has 34 output channels in VST format. Then I tried to host Workstation directly in the Juce Plugin Host, to know if the code of my project was the problem, and I noticed that the problem was present too.
This problem doesn’t seem to appear when hosting Workstation directly in Daws like Ableton or Logic Pro.

To reproduce this bug, you just have to take the Juce Plugin Host of the version 4.3.1 or 4.3.0 (I’ve tested with both), install Workstation(which is free) in Audio format and try to load it in the Juce Plugin Host which is going to trigger an assert in the juce::GraphRenderingOps::RenderingOpSequenceCalculator::markBufferAsContaining on the first assert.

Capture d’écran 2017-02-17 à 13.46.14.png1900×520 240 KB

I tried to see how the number of output channel is calculated when loading Workstation without any success.

This all the information that I got, and I hope someone here will help me to find out if this problem come from how the hosting work or from Workstation behavior.
I also contact UVI to share this problem with them, and will update this thread if I have any other information.

Thanks for the time you will spend to help me in advance,
Xav.

2 Likes
2

Hi again,

I post here again to update the informations that i’ve gotten during the weekend.
With the help of UVI and some colleagues, we have find out that there is a problem with the way the Juce Plugin Host host the plugins.
To arrive to this conclusion, we have try to host Workstation into several applications without encounter any problem, then we tried to host Workstation with an old version of Juce (4.1.0) and it works !!

So, once we have found out there is a bug in Juce, we have used git bisect on Juce to find the commit which trigger the bug. This operation led use to the commit 4fa0516f4068fcfe33d42ee94375be39e08e4bc0 entitled “Revised multibus API and added support for multibus hosting”. This commit is too huge(6,767 additions and 4,409 deletions.) for us to hope found the origin of the bug just by looking at it.

We are going to try to found the origin of this bug, but I really hope someone from Juce will be able to help us on that point which is far to be trivial. ^^

Regards,
Xav.

2 Likes
3

Same problem here with UVIWorksation in AudioUnit format, and the plugin Host works in 4.2.4 and stops working after the commit (4fa0516f4068fcfe33d42ee94375be39e08e4bc0) (tested with bisect)

1 Like
4

Same Problem with the Plugin Host on the Juce’s devlop branch, currently on the commit 78bbe49616d2f0a3b161a5ae9fc2e2cb56ae6b7a.

5

Sadly many of JUCE’s bugs seem to be introduced in giant commits like this one and this makes debugging very difficult.

I’d like to kindly ask the JUCE team to split their commits so that we all could help investigate bugs with more ease. In my experience working with smaller commits is also more productive (can later revert/blame with more ease etc).

7 Likes
6

Some info from UVIWorkstation:

1 stereo main output and 16 stereo aux outputs

override GetAudioChannelLayout and returns its num of input/output when element == 0
and forward to default impl in other cases

override ValidFormat and returns true for the valid main possible configuration when inElement == 0
and true for the valid aux channel configuration for other inElement

in its ctor call ChangeStreamFormat for its default configuration for main and aux outputs

Olivier, developer at UVI :slight_smile:

4 Likes
7

Hi everybody, i’am benjamin from ExpressiveE (I work with @Xxav)

Here is what we have found about the bug :

Since the first commit after the 4.2.4 version of JUCE, It is not possible to host the UVIworksation Audio Unit anymore with the JUCE hosting logic that we can find in the Plugin Host ( and therefore with the AudioProcessorGraph).

We tried to debug with XCode and breakpoints.

The source of the bug is in the function “getBusProperties” in the file “juce_AudioUnitPluginFormat” :

Capture d’écran 2017-02-22 à 16.40.10.png1237×483 99 KB

What we found is the following bug :

Between lines 1632 and 1637, for the first output bus of UVIworksation, the value of mChannelLayoutTag in the auLayout (AudioChannelLayout) is huge (>58000) and never updated by the “AudioUnitGetProperty” function that send no error, the if statement the pass and the currentLayout is instantiated as a “AudioUnitHelpers::CoreAudioChannelLayoutToJuceType”, then with the wrong “tag” value, all the logic of the bus setting is broken for this first bus.

The 16 others buses are not passing this “if” statement and therefore pass to the following one between lines 1639 and 1646. The currentLayout is instantiated as a “AudioChannelSet::canonicalChannelSet”.

At some point the class “BigInteger” then fails to count a correct number of channels (>58000) only for the first bus and gives 2 for the 16 others buses. (function “BigInteger::countNumberOfSetBits()”)
Then the jassert noted by @Xxav is raised.

The easy fix is to comment the first “if” statement between lines 1632 and 1637, then the first bus is managed correctly by the second “if” statement and all goes well.
Tested with other AU it works perfectly.

We don’t know why the logic of the buses is broken by this statement, we know that the commit mentioned before is responsible, we tried to do something but without comments, without an explanation of the complex processes involved in the hosting of the AU with JUCE we cannot do anything more.

We hope that this issue will be fixed properly in a future release of JUCE.

Best regards,

Benjamin, Developer at ExpressiveE.

1 Like
8

UVIWorkstation only reports GetAudioChannelLayout for the main bus.
This is maybe the issue.

I can fix that.
That’s the first host to bother with this :slight_smile:

@expressive E. I will send you guys a build to check on your end

1 Like
9

Ok, I have now fixed my implementation of GetAudioChannelLayout which was plain wrong.

@JuceDevs
Just wondering, should you guys calls reset on the kAudioUnitScope_Global scope instead of doing it for each input/outpu buses ?

10

So was this a UVIWorkstation bug all along?

I can’t remember exactly, but some other plug-ins needed that.

11

@Fabian yes it was an UVIWorkstation bug all along. Looks like nobody else care for the return values of GetAudioChannelLayout on the market. This code has been here for several years…

Regarding Reset, I would suggest adding a kAudioUnitScope_Globa once though.
I suspect other plugin like me only check/care for this one.
Don’t know what are the official/Apple position on this but AFAIK apple software don’t call it on each output/input so this is weird

1 Like
12

Thanks a lot @otristan for your help and your reactivity ! We would still be searching for the problem without your help ^^

Sorry @JuceDevs to have pointed Juce as the origin of the bug prematurally. if possible, it would be really helpful to add a comment in Juce, so the next time someone encounter the same bug he would not have to pass a week on this problem.

I am going to update this ticket’s title to a more accurate title for the future readers. @otristan, if you have any suggestion for this ticket’s title which describe the problem correctly for others users of Juce’s forum, do not hesitate to give them :wink:

1 Like
13

Well, the problem was ours so my bad.