Setup not adhereing to num of input channels

[fred-dev]

I am using a device with 18 outputs, just very simple testing with the example-matrixMixer.
With these setup paramaters:

ofSoundStreamSettings settings;
    settings.bufferSize = 256;
    settings.numBuffers = 1;
    settings.numInputChannels =  2;
    settings.numOutputChannels = 2;
    settings.sampleRate = 44100;

I get 18 channels of input on the matrix, despite requeting 2 (or any other number) as well as this warning:
[warning] ofSoundBuffer: resize(samples,val): channel count 18 is not consistent with sample count 512 (non-zero remainder)

However adding

cout<<ofToString(stream.getNumInputChannels())<< endl;

Reports the number of channels requested in the setup.

I have tested the normal ofSoundStream and this seems to adhere to the number of inputs and outputs set via ofSoundStreamSettings

I am using the current master branch.

[roymacdonald]

Hi.
So the ofSoundBuffer that is passed around has a marker with the number of channels, which from the warning it is 18, and that is actually how the number of channels is passed around, yet the soundstream might hold it as a differnt value which is the one you get when you print it out.
I dont have at hand a multi output interface to test.
Can you try any other example, and set it to use 2 outputs on the sound stream? Do you get the same warning?

[fred-dev]

Hi, so example-audioInput (with minor addtions of depreciated code to set the device) does not give any warning,s however to note this old methods lists my device as a different ID to all the examples using ofSoundStreamSettings, although that is not code from this addon.

example-soundRecorder also does not give the error but I could not set up a single mono input channel - despite setting settings.numInputChannels = 1; the verbose output reports input.getNumChannels : 2
example-multiInputMixdown gives the following outout

[warning] ofxSoundBaseMultiplexer: no valid group indices
[notice ] ofxSoundBaseMultiplexer: getChannels requested more channels than available 

Not sure if that helps.

[roymacdonald]

Hi. this is helpful. thanks.
Which OS are you using?
I can test on mac and windows. I mostly develop on my mac, and this addon in particular I have mostly developed and tested on mac, and works with no problems (at least that I have found).

[fred-dev]

I'm trying all this on OSX

[roymacdonald]

Ha, I've battle tested this addon on OSX, the matrix mixer in particular, running continously for months with no issues. One thing although is that I would usually set the sound stream to use the full amount of inputs available.
Just to be more specific, which audio interface and OSX version do you use.
There is a thing in macos where it sets the inputs to 2 automatically even if you choose one. It is an OF thing to avoid problems when using the internal microphone.
I'll see if I can replicate this and let you know.
best

[fred-dev]

I am not sure if tihs is the issue, but looking a little further I see:
bool ofxSoundMatrixMixer::MatrixInputObject::pullChannel() method.

Line 23: size_t nc = source->getNumChannels();

Checks for the number of channels, for all the possible types of object this would make sense, except for an input. This calls:

size_t ofxSoundInput::getNumChannels(){
	if(getInputStream()){
		auto ss = getInputStream()->getSoundStream();
		if(ss) return ss->getInDevice().inputChannels;
	}
	return inputBuffer.getNumChannels();
}

I made a check altering this method:

size_t ofxSoundInput::getNumChannels(){
	if(getInputStream()){
		auto ss = getInputStream()->getSoundStream();
        if(ss){
            std::cout<<"Are we returning the hardware channels?"<< std::endl;
            
            return ss->getInDevice().inputChannels;
        }
        
	}
	return inputBuffer.getNumChannels();
}

And it is returning ss->getInDevice().inputChannels;
It seems everywhere in the ofxSoundMatrixMixer class, src->getNumChannels() is called it will return the total number of input channels available on the device, not the number of used or initialised input channels. I didn't trace the whole system to see how that it all works with the buffer, but maybe this is a clue. This would also align with your experience that it is working well with all input channels used together.

So changing ofxSoundObject so the ofxSoundInput::getNumChannels() method to:

size_t ofxSoundInput::getNumChannels(){
	if(getInputStream()){
		auto ss = getInputStream()->getSoundStream();
		if(ss) return ss->getNumInputChannels();
	}
	return inputBuffer.getNumChannels();
}

Seems to fix the issue for me and the mixer has the correct number of input channels, but I am not sure of the whole intention of that method, or if this has some other effects.