CVS commit: [netbsd-9] src

["Martin Husemann" <martin%netbsd.org@localhost>]

Module Name:    src
Committed By:   martin
Date:           Mon Apr 27 14:32:34 UTC 2020

Modified Files:
        src/lib/libossaudio [netbsd-9]: ossaudio.c
        src/sys/compat/ossaudio [netbsd-9]: ossaudio.c

Log Message:
Pull up following revision(s) (requested by nia in ticket #855):

        lib/libossaudio/ossaudio.c: revision 1.41
        lib/libossaudio/ossaudio.c: revision 1.42
        lib/libossaudio/ossaudio.c: revision 1.43
        sys/compat/ossaudio/ossaudio.c: revision 1.80
        sys/compat/ossaudio/ossaudio.c: revision 1.81
        sys/compat/ossaudio/ossaudio.c: revision 1.82
        lib/libossaudio/ossaudio.c: revision 1.39
        sys/compat/ossaudio/ossaudio.c: revision 1.79
        lib/libossaudio/ossaudio.c: revision 1.40

ossaudio: Make SNDCTL_DSP_SPEED more robust when using invalid rates.

>From the perspective of reading the OSSv4 specification, NetBSD's
behaviour when an invalid sample rate is set makes no sense at all:
AUDIO_SETINFO simply returns an error code, and then we immediately
fall through to getting the sample rate, which is still set to the
legacy default of 8000 Hz.

Instead, what OSS applications generally expect is that they will be
able to receive the actual hardware sample rate. This is very, very
unlikely to be 8000 Hz on a modern machine.

No functional change when setting a sample rate between the supported
rates of 1000 and 192000 Hz. When a rate outside this range is requested,
the hardware rate is returned (on modern hardware, generally always 48000
Hz or a multiple of 48000 Hz).

ossaudio: Make SNDCTL_DSP_SETFMT conform with OSSv4.

The OSSv4 spec says we shouldn't really error if an invalid format is
chosen by an application. Things are especially likely to be confused
if we return MULAW, since in OSSv4 terms that means that's the native
hardware format. Instead, set and return the current hardware format
if an invalid format is chosen.

For the 24-bit sample formats, note that the NetBSD kernel currently
can't handle them in its default configuration, and will return an error
code if you attempt to use them. So, if an applicaton requests 24-bit PCM,
promote it to 32-bit PCM. According to the spec, this is valid and
applications should be checking the return value anyway.

In the Linux compat layer, we just use S16LE as a fallback. The OSSv3
headers that are still being shipped with Linux don't contain definitions
for fancier formats and we can reasonably expect all applications to
support S16LE.

ossaudio: If the user's channel count is rejected, use the hardware count

ossaudio: Make SNDCTL_DSP_[GET|SET][PLAY|RECORD]VOL closer to OSSv4

Problems in the previous code include returning values in the 0-255
range NetBSD uses instead of the 0-100 range OSSv4 expects, using
AUDIO_GETBUFINFO (which doesn't even return the mixer bits), and
not encoding channels as specified: "level=(left)|(right << 8)".

In reality, setting the gain in this way (through /dev/audio rather
than /dev/mixer) doesn't seem to work properly, and the mixer-set
value seems to be retained.

However, these changes at least ensure that the return values are
correct and the balance is set correctly.

I've only found one application using this API (audio/audacious), and
OSSv4 support in it is currently disabled precisely because it breaks
when it attempts to set the track volume using it.

ossaudio: Implement SNDCTL_DSP_(SET|GET)TRIGGER.


To generate a diff of this commit:
cvs rdiff -u -r1.36.2.1 -r1.36.2.2 src/lib/libossaudio/ossaudio.c
cvs rdiff -u -r1.74.4.3 -r1.74.4.4 src/sys/compat/ossaudio/ossaudio.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.