This is a multipart MIME message.

--==_Exmh_9520894926400
Content-Type: text/plain; charset=us-ascii


Hi -
that's neither kern nor purely userlevel -- maybe that list
is still good for something.

PR pkg/35444 (mplayer bad timeout select and play.channels number for oss)
reminds me of something: The NetBSD OSS emulation assumes that the number
of play and record channels is the same. It seems common now that there is
some 5.1 audio output but just a one or two channel input.
The emulated SNDCTL_DSP_CHANNELS ioctl tries to set both play and record
channels to the given number and fails if any of it fails. So there is no
chance to enable more than two channels in that example.

I'd suggest to treat play and record direction independently - see the
appended patch. Is there anyone having deeper knowledge about OSS,
or being able to test a real OSS with >2 channel hardware to judge
whether such a change makes sense?

best regards
Matthias



--==_Exmh_9520894926400
Content-Type: text/plain ; name="oss.txt"; charset=us-ascii
Content-Description: oss.txt
Content-Disposition: attachment; filename="oss.txt"

#
# old_revision [5fff99846d67879b2e498b71d01a3761adaef1c6]
#
# patch "lib/libossaudio/ossaudio.c"
#  from [ccf71c78ccaf56ea3a45ba9d0aad1782acf7d753]
#    to [d3cb57b84f77a93c843aa96b3f8a7b423e1b9361]
#
============================================================
--- lib/libossaudio/ossaudio.c	ccf71c78ccaf56ea3a45ba9d0aad1782acf7d753
+++ lib/libossaudio/ossaudio.c	d3cb57b84f77a93c843aa96b3f8a7b423e1b9361
@@ -240,7 +240,9 @@ audio_ioctl(int fd, unsigned long com, v
 		break;
 	case SNDCTL_DSP_CHANNELS:
 		AUDIO_INITINFO(&tmpinfo);
-		tmpinfo.play.channels =
+		tmpinfo.play.channels = INTARG;
+		(void) ioctl(fd, AUDIO_SETINFO, &tmpinfo);
+		AUDIO_INITINFO(&tmpinfo);
 		tmpinfo.record.channels = INTARG;
 		(void) ioctl(fd, AUDIO_SETINFO, &tmpinfo);
 		/* FALLTHRU */

--==_Exmh_9520894926400--