The OSS v4 API reference has this to say about AUDIOINFO vs ENGINEINFO: The higher level object is audio device file. Each audio device file has a visible device node in the /dev directory (actually there are two of them). Each audio device file has one or more audio engines. Audio device files that have multiple engines can be shared by multiple applications because each application (instance) will be directed to a different audio engine. In other words, every entry from AUDIOINFO should represent a device that a program can open and play. However, taking a look at my AUDIOINFO: /dev/dsp0.p0 /dev/dsp0.vp0 /dev/dsp0.vp1 /dev/dsp0.r0 /dev/dsp0.vr0 /dev/dsp0.vr1 /dev/dsp1.p0 /dev/dsp1.vp0 /dev/dsp1.vp1 /dev/dsp1.r0 /dev/dsp1.vr0 /dev/dsp1.vr1 ... Audio programs are not actually supposed to open these device nodes, because these are "engines" and not "devices". This is problematic, because many OSS applications on FreeBSD use the v4 API to populate a drop-down list of selectable audio devices, and none of them are actually playable. (To be completely clear: if you get lucky and select and empty VCHAN, then it is playable. But probably not after an application restart.) Instead, what AUDIOINFO returns now should be moved to ENGINEINFO, with AUDIOINFO returning something like: /dev/dsp0 /dev/dsp1 These are devices that applications can actually open.
It looks like the ioctl handler is the same for both AUDIOINFO and ENGINEINFO. I think I will try renaming the existing audioinfo handler to engineinfo, and write a new audioinfo handler that grabs some info from sndstat. This will involve making a few static sndstat structures public -- this the right way to go about it? This will give usable devices (/dev/dsp0 instead of /dev/dsp0.p0) and fill in the device handler (ai->handler) with a name from sndstat. We have a problem that the names from sndstat aren't unique, but this is better than having no handler, which some applications rely on to identify devices.
Feel free to propose a patch. Must be backwards compatible! --HPS
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=e07f9178502b7cbc0769fc10e99ad0d013f437fd commit e07f9178502b7cbc0769fc10e99ad0d013f437fd Author: Christos Margiolis <christos@FreeBSD.org> AuthorDate: 2024-05-23 00:57:04 +0000 Commit: Christos Margiolis <christos@FreeBSD.org> CommitDate: 2024-05-23 00:57:04 +0000 sound: Separate implementations for SNDCTL_AUDIOINFO[_EX] and SNDCTL_ENGINEINFO FreeBSD's implementation of SNDCTL_AUDIOINFO[_EX] and SNDCTL_ENGINEINFO does not exactly work as intended. The problem is essentially that both IOCTLs return the same information, while in fact the information returned currently by dsp_oss_audioinfo() is what _only_ SNDCTL_ENGINEINFO is meant to return. This behavior is also noted in the OSS manual [1] (see bold paragraph in "Audio engines and device files" section), but since e8c0d15a64fa ("sound: Get rid of snd_clone and use DEVFS_CDEVPRIV(9)") we can actually fix this, because we now expose only a single device for each soundcard, and create the engines (channels) internally. SNDCTL_ENGINEINFO will now report info about all channels in a given device, and SNDCTL_AUDIOINFO[_EX] will only report information about /dev/dspX. To make this work, we also have to modify the SNDCTL_SYSINFO IOCTL to report the number of audio devices and audio engines correctly. While here, modernize the minimum and maximum channel counting in both SNDCTL_AUDIOINFO[_EX] and SNDCTL_ENGINEINFO. Currently these IOCTLs will report only up to 2 channels, which is no longer the case. [1] http://manuals.opensound.com/developer/SNDCTL_AUDIOINFO.html PR: 246231, 252761 Sponsored by: The FreeBSD Foundation MFC after: 1 day Reviewed by: dev_submerge.ch Differential Revision: https://reviews.freebsd.org/D45164 sys/dev/sound/pcm/dsp.c | 179 +++++++++++++++++++++++++++++++++++++++++----- sys/dev/sound/pcm/dsp.h | 3 +- sys/dev/sound/pcm/mixer.c | 8 ++- sys/dev/sound/pcm/sound.c | 8 +-- 4 files changed, 173 insertions(+), 25 deletions(-)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=e8a80b4e50e8d992fe46a95509b37fc457288f93 commit e8a80b4e50e8d992fe46a95509b37fc457288f93 Author: Christos Margiolis <christos@FreeBSD.org> AuthorDate: 2024-05-23 00:57:04 +0000 Commit: Christos Margiolis <christos@FreeBSD.org> CommitDate: 2024-05-25 19:30:26 +0000 sound: Separate implementations for SNDCTL_AUDIOINFO[_EX] and SNDCTL_ENGINEINFO FreeBSD's implementation of SNDCTL_AUDIOINFO[_EX] and SNDCTL_ENGINEINFO does not exactly work as intended. The problem is essentially that both IOCTLs return the same information, while in fact the information returned currently by dsp_oss_audioinfo() is what _only_ SNDCTL_ENGINEINFO is meant to return. This behavior is also noted in the OSS manual [1] (see bold paragraph in "Audio engines and device files" section), but since e8c0d15a64fa ("sound: Get rid of snd_clone and use DEVFS_CDEVPRIV(9)") we can actually fix this, because we now expose only a single device for each soundcard, and create the engines (channels) internally. SNDCTL_ENGINEINFO will now report info about all channels in a given device, and SNDCTL_AUDIOINFO[_EX] will only report information about /dev/dspX. To make this work, we also have to modify the SNDCTL_SYSINFO IOCTL to report the number of audio devices and audio engines correctly. While here, modernize the minimum and maximum channel counting in both SNDCTL_AUDIOINFO[_EX] and SNDCTL_ENGINEINFO. Currently these IOCTLs will report only up to 2 channels, which is no longer the case. [1] http://manuals.opensound.com/developer/SNDCTL_AUDIOINFO.html PR: 246231, 252761 Sponsored by: The FreeBSD Foundation MFC after: 1 day Reviewed by: dev_submerge.ch Differential Revision: https://reviews.freebsd.org/D45164 (cherry picked from commit e07f9178502b7cbc0769fc10e99ad0d013f437fd) sys/dev/sound/pcm/dsp.c | 179 +++++++++++++++++++++++++++++++++++++++++----- sys/dev/sound/pcm/dsp.h | 3 +- sys/dev/sound/pcm/mixer.c | 8 ++- sys/dev/sound/pcm/sound.c | 8 +-- 4 files changed, 173 insertions(+), 25 deletions(-)