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.
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.
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).
- 'fragments' is the number of full free blocks and should not be
negative value.
- 'bytes' should not be rounded down.
It makes mpv work correctly (fixes a second half of kern/53028).
Reviewed by mlelstv@
picked up by gcc7's checker that the array size has not
been multipled by the member size.
here, we had 8 but should have had 8 * sizeof(int).
XXX: real bug - pullup-7, pullup-8
The ioctl definitions and accompanying structures were
taken from FreeBSD's soundcard.h, hopefully providing
some binary compatibility.
The ioctls are as follows:
SNDCTL_SYSINFO: Returns a structure containing
details about the audio device.
SNDCTL_ENGINEINFO - SNDCTL_AUDIOINFO: Returns a
structure with playback/recording
characteristics.
SNDCTL_DSP_GETPLAYVOL, SNDCTL_DSP_SETPLAYVOL,
SNDCTL_DSP_GETRECVOL, SNDCTL_DSP_SETRECVOL:
Retrieves/Sets Playback/Recording volume.
SNDCTL_DSP_SKIP - SNDCTL_DSP_SILENCE: These ioctls
were intended to manipulate the underlying
audio buffer skip or insert silence. These
return EINVAL.
SOUND_VERSION is unchanged, but is definable, It will be
changed when the mixer OSSv4 ioctls are written.
Addresses PR 46611
This commit was approved by wiz@.
we try to set both in one ioctl, to the same value, which fails if not
both record and play direction support that many channels. (Having
more play than record channels is common these days.)
This does likely address part of the problem described in PR pkg/35444
by Mihai Chelaru, and it helped Matthew R. Green about half a year
ago -- see the thread in tech-misc in April.
doesn't obtain the ports, gain and balance related parameters.
Those generally require reading from the hardware and therefore are much
more expensive to obtain. Modify OSS emulation to use the new ioctl
where possible.
This reduces CPU usage of mplayer during mp3 playback with my Thinkpad
from 20% to < 1% and from 50% to 20% during Xvid playback.
Review and comments from jmcneill@
<machine/endian_machdep.h>.
The previous method of wrapping a definition of _POSIX_SOURCE around the
inclusion of other headers to reduce namespace pollution had the
side-effect of not all required identifiers being defined when included
thereafter by the application itself (due to multiple-inclusion protection),
and is not blessed by that standard.
