Hi, I’m experiencing a strange problem. The following is reproducible with the audio plugin host example code.
In the app, if I start making patches from an audioInput node to and audioOutput node, eventually signal will show up where no patch is made. I’m assuming audio is being mixed somewhere that it shouldn’t be. Has anybody else ever seen this problem? I test this with the latest version of JUCE in git earlier this morning.
I thought at first I was coding something weird in my own app, but when the same problem was in the example code, I assume that there’s a bug somewhere in JUCE"s audio graph builder code.
Here’s the basic setup: My audioInput node and output node both have 14 channels. I have an audio signal coming in on channels 3 and 4. My speakers are hooked into audio out 1/2.
Steps to reproduce this problem in JUCE’s plugin host example:
Connect in 3/4 to out 1/2, all will work as expected and you’ll hear a normal stereo output.
Disconnect In 3 from out 1, still you will hear a normal signal in the right speaker.
Connect In 5 to out 1
Connect in 5 to out 2
Connect in 6 to out 1
Connect in 6 to out 2
At this point you still hear a normal right channel only output in the speakers
Connect in 4 to any other output channel except out 1. Doing this causes audio from in 4 to be copied or mixed into out 1.
I can reproduce this in my own application and the plugin host example. I understand that this isn’t exactly a normal patching situation, but nonetheless the above patching should not produce audio in output 1.
… it seems to solve it. As stated though, I haven’t tested with a larger graph so I’m not sure if anything else breaks from that. I suppose checking if the node is an audioOutput node could serve the same purpose and not affect any other non-AudioIOProcessor nodes.
I’ll continue to test, and hopefully this little bug can be squashed!
I don’t see a problem with the line you highlighted:
const int srcIndex = getBufferContaining (sourceNodes.getUnchecked (0),
sourceNodes and sourceOutputChans is not the channel number of the current node. Look how sourceNodes and sourceOutputChans is generated: it’s a list of all the sources for the current node and pin, i.e. the code goes through all the input pins of the current node. For each input pin it generates a list of sources (which consists of source node and the source node’s output pin) called sourceNodes/sourceOutputChans. It then uses the buffer of the first element of sourceNodes/sourceOutputChans as the buffer where it will later mix in the other sources. It doesn’t really matter which index it uses there (as long as it’s in the range of the sourceNodes array of course) - so it could have used 1 or 2 etc.
I don’t quite understand your comment about the other line of code you are showing:
if (sourceBufIndex >= 0
the zero’th sourceBufIndex is only the emptyReadOnlyBuffer in the case where the current pin has no input connections. The line you highlighted is only executed if the current pin has at least one input.
BTW: I don’t have a multi channel audio card lying around at the moment (I’ll try to grab one until the end of the week). But I couldn’t reproduce your problem with multi-channel surround plug-ins.
Thank you for explaining. I wasn’t suggesting there’s a problem there, just wanted to make sure I understand it’s doing what I think it is :). I have a much better understanding of this section of the code now!
I’m determined to figure this out. My line of thinking is that this is only happening when an audio/midi input node is patched directly to an audio/midi output node (because of the special handling of it).
Thanks again for acknowledging this! I’m anxious to see if the problem happens when you can test with a multi chan device. BTW, does JUCE accept pull requests on github? I know in the past Jules didn’t accept them, but don’t know if it’s different now that Roli is involved.