From nobody Sat Mar 16 02:48:21 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 4TxQXz74G9z5DWwH for ; Sat, 16 Mar 2024 02:48:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TxQXz3cTVz4s7X; Sat, 16 Mar 2024 02:48:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 42G2mLTt036060; Sat, 16 Mar 2024 04:48:25 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 42G2mLTt036060 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 42G2mLht036059; Sat, 16 Mar 2024 04:48:21 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 16 Mar 2024 04:48:21 +0200 From: Konstantin Belousov To: Mark Johnston Cc: Christos Margiolis , status-updates@freebsdfoundation.org, freebsd-multimedia@freebsd.org, jrm@freebsd.org Subject: Re: Re: [Development report #7] Audio Stack Improvements Message-ID: 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-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home 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:6939, ipnet:2001:470::/32, country:US] X-Rspamd-Queue-Id: 4TxQXz3cTVz4s7X On Fri, Mar 15, 2024 at 10:38:01PM -0400, Mark Johnston wrote: > On Fri, Mar 15, 2024 at 06:00:16PM +0100, Christos Margiolis wrote: > > Hello Mark, > > > > Mark Johnston wrote: > > > > Behavior changes: > > > > - Only one /dev/dspX device is exposed, as opposed to the current > > > > /dev/dspX.[X]X devices created by the snd_clone mechanism. The > > > > user/application now only needs to access the device through /dev/dspX > > > > or /dev/dsp and sound(4) will take care of all necessary audio > > > > routing. > > > > > > Does this represent a backward compatibility break? That is, will > > > applications need any modification when running on a patched kernel? > > > > Applications are meant to open an audio device through /dev/dsp (if > > hw.snd.basename_clone is enabled), or through /dev/dspX, so the vast > > majority of applications should work with no problems. > > > > Applications that open a device through /dev/dspX.[X]X will break with > > this patch. However, opening a device like this is discouraged anyway, > > according to the sound(4) man page (see FILES section): > > To your knowledge, do any popular applications actually do this? A > comment in the man page isn't very important if applications end up > ignoring it. :) > > If needed, would it be a lot of work to provide backward compatibility? Should be rather trivial, to catch the case in the devfs lookup clone callback and instantiate fake nodes. > > > [...] > > /dev/dsp%d.p%d Playback channel. > > /dev/dsp%d.r%d Record channel. > > /dev/dsp%d.vp%d Virtual playback channel. > > /dev/dsp%d.vr%d Virtual recording channel. > > [...] > > > > The above device nodes are only created on demand through the > > dynamic devfs(5) clone handler. Users are strongly discouraged > > to access them directly. For specific sound card access, please > > instead use /dev/dsp or /dev/dsp%d. > > > > The patch basically does the same thing -- the output of /dev/sndstat > > remains the same -- but without creating these device nodes. > > > > Christos