From nobody Wed Oct 02 21:53:45 2024 X-Original-To: freebsd-stable@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 4XJpV701rbz5Y8jw for ; Wed, 02 Oct 2024 21:53:51 +0000 (UTC) (envelope-from christos@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XJpV65wMmz4pkL; Wed, 2 Oct 2024 21:53:50 +0000 (UTC) (envelope-from christos@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1727906030; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/m9kJBIni3aqRUq2JCNdkpLpDPsV54xMjQfd5/98nTg=; b=wrlP9R/uBoiVpZuRzfglX7CmlpBuwXywI7q38Ne5lK0xhN81d/GZeGthLTrF+XNzitRvCk Jzyfp6cceqOqgSbXlEUZRsyFdXJG6c9IV4E5KTkVY6VBvj4toZXrVoKHdOycTQ4qfqQsBO X24sSPgAqyeRUo3ZrYGSee9vHXvj0RDiPuosYoKCIehcDXDhxAPFIj0gL9RLjJbVooNghS qvM5fzIr+PPR1x++zeHp0DkFcIukR2X9eF8BhmTn6pB5DlNGFfErsroX1Eit4oEenHzROZ esnXx1bu0UMd+vriVPo2Iew0rkgTwAXoFJbEWB83fOH7wCypAZ9t1gnuCJIt4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1727906030; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=/m9kJBIni3aqRUq2JCNdkpLpDPsV54xMjQfd5/98nTg=; b=YUAT8JSabQ2qoLzbnq5SnEDqphGZkljOf6RHdpKumrc4wU2spSCuCRPZTl2OQQPHswkIHW SeCj32SJvkZ7tXsbuq4akEl5Pyg9A0uOArhzKwJF/ZeIKDuynZFxtFbvsam8krx15uNsuv jiNecR5fk7qP9o1l0741K/1uctNxqw779BhbjylLEh1IIbjtOxM/SblL6wCF1vAuCbyY93 ol3FHIYP5WFw22g6ebrBW5+bC9k/gLhREv64cjwzQL+3w38AYPiI6eZIoHkiHDLUxXUBB8 6/4yebI9vK2ktL9hxvSULqMrwYuYGaQAGG1HO1FUWlg2vi1dsSzmMp6Zf9LVjA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1727906030; a=rsa-sha256; cv=none; b=BzE9RLC2wrbEK5rpdVjRQPzJKSDOiq4MxrW61nIYJjC3S4RxBvSBl1s/qM8+rJLt74KA96 UoBN0YJVkrL/OMBL9gfKG9ijuXA9Lz+nfcnA315r1ltucJP5/lxwAFR81kvyd0A0jsS+nH ctwz2b2qLgcs+qSmwrXcbSHi1IyGALS3tBYVnC7xC8Nb7ich7ghkPWUvZd293C5lDve8RJ edcLUjEop4OnP+7/4OCt1i4C+NIVH0sC91zHlOyu66sSGU1NmHz5E6dymJhG5tKMd6IOAC /p8IWgWiAg/zCyPtGdJ+feYEtd8eMB7thkwSmPmTADdTq/gU3oFLPjBT4416mQ== Received: from margiolis.net (mail.margiolis.net [95.179.159.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512) (Client did not present a certificate) (Authenticated sender: christos/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XJpV62hCFzWCN; Wed, 2 Oct 2024 21:53:50 +0000 (UTC) (envelope-from christos@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=mail; bh=BefGBl38iixjUXE 6SgG954KX9LvfH5OPL5OBHYbVOmo=; h=in-reply-to:references:subject:cc:to: from:date; d=margiolis.net; b=KFCEKwzLXKYJrMEmp6ZXacQqE6Dni/B6TXK0uK9Y FpVInbE01hnDxaagG/ygV4TRU5cPjbbJqp8MdNQUrrnrStz0lWoBtxBetQLWYc6RJnrzkJ emyIMVhCmK35GgI0+qjC694DOE778FutrynKmZwaaTI9WHc7wnRZUf3+oA1SU= X-Spam-Score: 6.4 / 15 X-Spam-Status: Yes, score=6.400 required=15.000 tests=[ARC_NA=0.000, ASN=0.000, FREEMAIL_ENVRCPT=0.000 FREEMAIL_TO=0.000, FROM_EQ_ENVFROM=0.000, FROM_HAS_DN=0.000 MID_RHS_NOT_FQDN=0.500, MIME_GOOD=-0.100, MIME_TRACE=0.000 NEURAL_SPAM=0.000, RCPT_COUNT_THREE=0.000, RCVD_COUNT_ONE=0.000 RCVD_TLS_ALL=0.000, RCVD_VIA_SMTP_AUTH=0.000, SPAM_FLAG=5.000 SUBJECT_HAS_CURRENCY=1.000, TO_DN_SOME=0.000 TO_MATCH_ENVRCPT_ALL=0.000] Received: from tpad (31-217-175-193.cgn.acro.cosmote.net [31.217.175.193]) by margiolis.net (OpenSMTPD) with ESMTPSA id 7884f06d (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Wed, 2 Oct 2024 21:53:47 +0000 (UTC) Date: Thu, 3 Oct 2024 00:53:45 +0300 From: Christos Margiolis To: Alban Hertroys Cc: Dag-Erling =?utf-8?B?U23DuHJncmF2?= , freebsd-stable@freebsd.org Subject: Re: uaudio device re-attach and persisting dev.pcm.$pcm.bitperfect sysctl Message-ID: References: <86ploiwxw8.fsf@ltc.des.dev> <8745F9FB-9CC1-476C-9445-DC0A7A76165F@gmail.com> List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-stable@freebsd.org Sender: owner-freebsd-stable@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8745F9FB-9CC1-476C-9445-DC0A7A76165F@gmail.com> Alban Hertroys wrote: > Meanwhile, several people here suggested that devd is the way to go > about this. I had actually looked into that a bit, but that seemed to > require a related device node in /dev, and there’s neither one for pcm > nor for uaudio, so I discarded that as not being a viable option. > Perhaps too soon. Audio device nodes are /dev/dspX, where X is the unit number, which has a 1-1 relation with the pcmX unit number, so pcm2's device node is /dev/dsp2. To clarify some more things, the sound subsystem roughly consists of the following layers: - The sound(4) layer, which is the highest-level layer, and among other things, is responsible for mixing channels, doing conversions, providing some generic functions for sound drivers to use, as well as providing a uniform device interface (i.e pcmX). - The device driver (e.g snd_uaudio(4), snd_hda(4), ...) layer, which is responsible for actually communicating with the sound card. You could visualize it as follows: some usb card -> uaudio0 -> pcm0 some other usb card -> uaudio1 -> pcm1 some intel card -> hdaa0 -> pcm2 > > [...] > > I can see devd looking to match uaudio0 and pcm2 devices to several > names it knows (probably from other devd confs?), but it doesn’t seem > to match my attempt. Let alone that it got around to attempting to > parse my sh tidbit. So in your case, "pcm2" is a generic name given to the device by sound(4) and "uaudio0" is the name of the driver this device is using, but the actual device node is /dev/dsp2. What I think is confusing is that sound(4) names devices as "pcm", but creates the nodes as "dsp"... Maybe I should propose a patch to get rid of this scheme, and simply name them everywhere as either "pcm", "dsp", or something else like "snd". Christos