From nobody Fri May 10 01:34:05 2024 X-Original-To: freebsd-multimedia@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VbBHm5CGYz5KVRk for ; Fri, 10 May 2024 01:34:12 +0000 (UTC) (envelope-from dev@submerge.ch) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4VbBHl6rCYz4NHg; Fri, 10 May 2024 01:34:11 +0000 (UTC) (envelope-from dev@submerge.ch) Authentication-Results: mx1.freebsd.org; none Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 0B4E234060D; Fri, 10 May 2024 03:34:09 +0200 (CEST) X-Iway-Path: 0 Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/14218.25988); Fri, 10 May 2024 03:34:08 +0200 (CEST) Received: from interway.li (sendai-nord.iway.ch [212.25.24.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Fri, 10 May 2024 03:34:08 +0200 (CEST) Received: from [145.40.196.39] (account fw@submerge.ch HELO z800.localnet) by sendai-nord.interway.li (CommuniGate Pro SMTP 7.1.0) with ESMTPSA id 262566675; Fri, 10 May 2024 03:34:08 +0200 From: Florian Walpen To: freebsd-multimedia@freebsd.org Cc: emaste@freebsd.org, freebsd-multimedia@freebsd.org, Christos Margiolis Subject: Re: SNDCTL_AUDIOINFO and SNDCTL_ENGINEINFO Date: Fri, 10 May 2024 03:34:05 +0200 Message-ID: <6755561.qJWK8QVVMX@z800> In-Reply-To: References: List-Id: Multimedia discussions List-Archive: https://lists.freebsd.org/archives/freebsd-multimedia List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-multimedia@FreeBSD.org MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:8758, ipnet:212.25.0.0/19, country:CH] X-Rspamd-Queue-Id: 4VbBHl6rCYz4NHg 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