The _ssize() function in ossaudiodev.c (2.4.3, but it's
the same in svn) calls SNDCTL_SET_CHANNELS with
channels=0 as part of an attempt to determine the total
number of samples per second for the current
configuration of the audio device, but as far as I can
tell this is not guaranteed to act as a query and at
least two implementations treat it as a request for a
monaural format (the ALSA pcm-oss module and the
alsa-oss library).

What this can safely be replaced with I don't know;
both Linux's OSS drivers and ALSA support
SOUND_PCM_READ_CHANNELS but this is not standard to the
best of my knowledge.  Storing the value returned when
the program calls .setfmt or .setparameters may be an
option.

I just wanted to confirm that this is  problem for me as well when I run this.  I am writing an application where I need to get buffer information when I am running with 2 channels.  This is a quite normal situation these days.  I assume that the change is made to mono because in OSS mono is the default, so that it will work with what is now quite ancient hardware.  But, requesting the buffer size should not cause such a dramatic error.  I don't understand why this is such a problem.  Could there be a parameter for number of channels since you cannot request the buffer size unless you have already setup the hardware giving the number of channels?  So even if the System cannot figure out the number of channels, your application knows it and can tell it.  Granted, it is a kluge, but it is a kluge that can work whereas currently whenever you request buffer information the speed of your sound is cut in half making the obuf commands unusable.  Possibly another solution would be to remove these commands until they work.  I did notice that the program does reference SOUND_PCM_WRITE_CHANNELS.  Is SOUND_PCM_WRITE_CHANNELS standard and SOUND_PCM_READ_CHANNELS not standard?  I don't know that that is not true, but it does seem strange.  

I think SNDCTL_SET_CHANNELS should have read SNDCTL_DSP_CHANNELS.  The code was changed in r42752 so is this still a problem?

Hi there yes this is very much an issue on Arm linux (e.g. Armbian). Calling any function that triggers a call to _ssize(..) - a function which is clearly intended to have no side-effects - instead resets the number of channels (and sample format?) by calling IOCTLs "SNDCTL_DSP_SETFMT" and "SNDCTL_DSP_CHANNELS" with arguments of zero as a way to query the current values. 

This doesn't work on many drivers; e.g. they take '0' as meaning 'mono' and switch to one channel. 

To repro:
        import ossaudiodev
        self.dsp=ossaudiodev.open("/dev/dsp1","w")
        self.dsp.setfmt(ossaudiodev.AFMT_S16_LE)
        self.dsp.channels(2)  #<<Set to stereo
        self.dsp.speed(96000)
        ...
        self.bufSize=self.dsp.bufsize()
        ...

        #This will output audio in the wrong format (mono)! Remove the innocent looking "bufsize" test above and it will correctly output stereo
        self.dsp.write(someData)


Frustrating bug! ;-)

Does the issue still affect supported Python and Linux versions? Majority of distros are using pipewire or pulseaudio these days.