Improve wording and also fix the constants' names.
Sponsored by: The FreeBSD Foundation
MFC after: 2 days
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D46220
(cherry picked from commit 6e744de1a3dc5dde8d2ee51e97a1224a01bdfb21)
Sponsored by: The FreeBSD Foundation
MFC after: 1 day
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D45290
(cherry picked from commit 1ab62c8d067454b77bc9fb1c5aac75f263bb4143)
This is better than hardcoding device paths in mixer applications.
Sponsored by: The FreeBSD Foundation
MFC after: 1 day
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D45275
(cherry picked from commit 67c89b21b95601c01bafe5a0c518d320a39111c0)
mixer(8)'s -a option is used to print information about all mixer
devices in the system. To do this, it loops from 0 to
mixer_get_nmixers(), and tries to open "/dev/mixer%d". However, this
approach doesn't work when there are disabled/unregistered mixers in the
system, or when an audio device simply doesn't have a mixer.
mixer_get_nmixers() calls SNDCTL_SYSINFO and returns
oss_sysinfo->nummixers, whose value is the number of currently _enabled_
mixers only. Taking the bug report mentioned below (277615) as an
example, suppose a system with 8 mixer devices total, but 3 of them are
either disabled or non-existent, which means they will not show up under
/dev, meaning we have 5 enabled mixer devices, which is also what the
value of oss_sysinfo->nummixers will be. What mixer(8) will do is loop
from 0 to 5 (instead of 8), and start calling mixer_open() on
/dev/mixer0, up to /dev/mixer4, and as is expected, the first call will
fail right away, hence the error shown in the bug report.
To fix this, modify oss_sysinfo->nummixers to hold the value of the
maximum unit in the system, which, although not necessarily "correct",
is more intuitive for applications that will want to use this value to
loop through all mixer devices.
Additionally, notify applications that a device is
unavailable/unregistered instead of skipping it. The current
implementations of SNDCTL_AUDIOINFO, SNDCTL_MIXERINFO and
SNDCTL_CARDINFO break applications that expect to get information about
a device that is skipped. Related discussion can be found here:
https://reviews.freebsd.org/D45135#1029526
It has to be noted, that other applications, apart from mixer(8), suffer
from this.
PR: 277615
Sponsored by: The FreeBSD Foundation
MFC after: 1 day
Reviewed by: dev_submerge.ch
Differential Revision: https://reviews.freebsd.org/D45256
(cherry picked from commit 5d980fadf73df64a1e0eda40a93170ed76ce6f14)
We have BASEPATH defined.
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Reviewed by: dev_submerge.ch, markj
Differential Revision: https://reviews.freebsd.org/D43812
(cherry picked from commit 53c768e6836a32c8dcd0b0b422a169ef7a82a3ab)
There's no reason to pass the mixer as an argument since we can fetch it
from mix_dev. No functional change intended.
Reviewed by: markj, hselasky
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D38076
This allows us to use the TAILQ_PREV and TAILQ_FOREACH_REVERSE_* macros,
useful for an out-of-tree consumer.
Reviewed by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D38055
