Date: Fri, 10 May 2024 03:34:05 +0200 Cc: emaste@freebsd.org, freebsd-multimedia@freebsd.org, Christos Margiolis <christos@freebsd.org> Subject: Re: SNDCTL_AUDIOINFO and SNDCTL_ENGINEINFO Message-ID: <6755561.qJWK8QVVMX@z800> In-Reply-To: <hwbwazmrmf6suuhqfjsukfztzqxlviaiupxsot5igq5lfheelr@2ybngnds4hz7> References: <hwbwazmrmf6suuhqfjsukfztzqxlviaiupxsot5igq5lfheelr@2ybngnds4hz7>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, May 9, 2024 2:57:47 PM CEST Christos Margiolis wrote: > A few days ago I stumbled into a bug report [1] which mentions that > FreeBSD's SNDCTL_AUDIOINFO and SNDCTL_ENGINEINFO do not exactly work > correctly. 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 [2] (see bold paragraph in > "Audio engines and device files" section), but I think that since the > DEVFS_CDEVPRIV(9) patch 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 report info about all > channels in a given device (exactly what we do already), and > SNDCTL_AUDIOINFO will only report information about /dev/dspX. Good idea. Don't forget to also change the `numaudios` in SNDCTL_SYSINFO, and to return "blank" oss_audioinfo structs with `enabled == 0` and some safe values if the device is unavailable (e.g. USB audio disconnected). > > The reason I writing this email however, is to hear your feedback on the > following. Both SNDCTL_AUDIOINFO and SNDCTL_ENGINEINFO expect the same > oss_audioinfo structure, so I am wondering what some of the fields will > be filled with for SNDCTL_AUDIOINFO. The values should actually be quite similar, as long as vchans are enabled on the pcm device (format conversion). It gets more interesting for bitperfect use which corresponds to the SNDCTL_AUDIOINFO_EX ioctl. > > Here are my thoughts about what we should fill the fields with: > > dev Device unit. > name Either pcmX or device_get_desc(). I think the latter is > better. The latter, device_get_desc(). > busy Set this to true if we have >0 busy channels in the > device? Yes. > pid I think it's best to set this to -1. We could check if > an application has exlusive access of the whole device, > but I don't think this is useful in any way. > caps We could gather the caps for every channel and OR them > together, so we'll report all the currently enabled caps > for the device. > iformats Same as caps. > oformats Same as caps. > cmd Nothing. Same logic as pid. > card_number Device unit. > song_name Not supported. > label Not supported. > port_number Device unit. > mixer_dev Device unit. > legacy_device Device unit. > devnode /dev/dspX > enabled device_is_attached() > min_rate Global (from all channels) minumum; > max_rate Global maximum. > min_channels Global minimum. > max_channels Global maximum. Sounds all reasonable, but I'm not sure it's necessary to iterate over the channels to aggregate. It should be the same logic as for the channels, these are virtual devices with format conversion after all. > nrates, rates Drivers do not support this yet, but I am not sure > exactly what we should put here. Should be a list of supported sample rates, as in [44100, 48000, ...]. Most drivers have this internally, but it's only propagated as a range to the pcm channel. I think we can omit that. > handle Not supported. > next_play_engine 0 > next_rec_engine 0 Agreed. > > Christos > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246231 > [2] http://manuals.opensound.com/developer/SNDCTL_AUDIOINFO.html
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6755561.qJWK8QVVMX>