[Bug 246231] dev/sound: SNDCTL_AUDIOINFO is actually SNDCTL_ENGINEINFO

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246231

            Bug ID: 246231
           Summary: dev/sound: SNDCTL_AUDIOINFO is actually
                    SNDCTL_ENGINEINFO
           Product: Base System
           Version: 12.1-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs at FreeBSD.org
          Reporter: kevinz5000 at gmail.com

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.