Question regarding getNumInputChannels


#1

I have set up my plugin in order to allow mono input.
When compiled in standalone mode, the audio settings dialog allows me to choose only one channel for input, but inside the processBlock callback still the getNumInputChannels() call returns 2.
The same happens within the prepareToPlay…

What am I missing? Is there another method I should call to get the actual number of input channels selected from that dialog?


#2

Some audio devices might only be able to work as a stereo pair, and it’s your job to fill up whatever channels it gives you. Easy enough for a mono plugin, you can just copy the data across all the channels.


#3

The same device reported the expected number of input channels (1) with earlier versions of juce…


#4

Was it a different audio API? E.g. are you using WASAPI now?


#5

I’ve always used both DirectSound and ASIO, but they both now report 2 input channels even if I chose only one in the audio settings dialog.


#6

You must be talking about a very old version of juce then - I don’t remember making any big changes to those classes for years!


#7

well I don’t honestly know, but what is for sure is that, even changing different sound cards and drivers, choosing a single input in the audio preferences settings still results in getNumInputChannels returning 2 within the processBlock callback. Can you confirm this?


#8

I’m sure it does, but like with a plugin, your code has to deal with whatever number of channels it’s asked to handle. I don’t really see this as an actual bug that needs fixing.


#9

well ok, I understand but… what’s the purpose of that window then? I tried changing the configurations from {1, 1} to {2, 3} at runtime, but still the processBlock function says that I’m working in stereo-to-stereo {2, 2} , no matter what the actual configuration of channels is.

How could it be that, if I enable 3 output channels in the audio settings window, still the number returned by getNumOutputChannels () is 2? Am I getting wrong what that function is meant to return? Or maybe I’m not getting properly what that audio settings window is meant for…


#10

Ok, I’m confused now - I must be misunderstanding what you’re asking. I’ll take a look next time I’m doing audio stuff, but am tied up in other areas of the code right now.


#11

I think I have spotted the problem:

the method setPlayConfigDetails of AudioProcessor is called only upon creation of the AudioFilterStreamer object, passing the max number of input and output channels as #defined in the plugin characteristics.

What seems to be missing are subsequent calls to setPlayConfigDetails when the audio properties (in particular, when the number of channel) changes.

I mean: every time I change channels in the audio options window, the setAudioDeviceSetup method of AudioDeviceManager is called, but no following calls to AudioProcessor::setPlayConfigDetails happen, while it seems to me like a reasonable behaviour, what do you think?

I got a bit confused by the class hierarchy used for the standalone plugin, so I didn’t dare to implement a solution myself, but I think that a good idea would be to exploit the fact that the AudioDeviceManager can have changeListeners notified when the setup changes… or is it better to make it a synchronous change?

Hope I have been clear enough…


#12

That does sound like something that the standalone wrapper should be doing… Sorry, I’m too deep in other stuff right now to task-switch and think about this.