DgfMg1AEnG6dA6pa9HENY6TkclFLKgK9z6hN3jBzHrSdoO2 CPjRpOWu+o2MhcBylxV9nJWkYa2V3k34LTe860sNvAVr9wtrBHEeCFfJ7HyCbvqTrmXubN I1/FLH77ZejP5suTxcMesyMgby3nVnqWYd08JlMNouA9YAdVL3tmkq9XsrNSChFkZX/EAh 3YYQmARjWBopluf+bcKLwvEytlMmX7lNq81MLE7iZUO5vcCMp+7B33horwYLBw== 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 4XKDcl1GVbz15T8; Thu, 3 Oct 2024 14:31:03 +0000 (UTC) (envelope-from christos@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=mail; bh=QHBW2jZYKDXq7HK jig5+m+7AFrX/522SvuSwaUhSsAc=; h=in-reply-to:references:subject:cc:to: from:date; d=margiolis.net; b=Y5H78fIs5BuBkk0ZGYn+NHePwf6+E5jXuNQT6u0o DLYf9Hn3jhGIAN2MKncSlUnzRV7QF1boKNP7W3ap4Q9AT4NBMsVZZqeikWDvl7z3vAbYpq kvAvgklFnvnQcWc/inWTpsdAK72q1Ax1zFGCc0zxHAX8XUNVQYfGqnoSHQspk= 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_CC=0.000 FREEMAIL_ENVRCPT=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_FIVE=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 0c773225 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Thu, 3 Oct 2024 14:30:59 +0000 (UTC) Date: Thu, 3 Oct 2024 17:30:57 +0300 From: Christos Margiolis To: Tomoaki AOKI Cc: Christos Margiolis , Alban Hertroys , 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> <20241003231016.47f74f2d2ada7b4a76d065dd@dec.sakura.ne.jp> 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=us-ascii Content-Disposition: inline In-Reply-To: <20241003231016.47f74f2d2ada7b4a76d065dd@dec.sakura.ne.jp> Hello Tomasz, Tomoaki AOKI wrote: > Maybe what newbies want would be: > *Currently active audio device is always seen as exactly the same, > without device number or something. What do you mean exactly? > *Basically newly attached "physical" device is always preferred. > For example: > If a USB audio is plugged and powered on, it is preferred. > After that, if a headphone is plugged into the connector, > the headphone is automagically selected and other outputs > are automatically muted. > After that, if optical SPDIF is connected, mute headphone and > route output to SPDIF. > When the SPDIF plug is disconnected, automatically fall back to > headphone. > If the headphone is plugged out before SPDIF, fall back to USB, > and more, if USB is not available ATM, fall back to PC speaker. > > Cannot point into specific posts, but I see screams like "Hey, I > cannot hear audio output from headphone. How can I do it?!" in Forums. > And currently the answers should be quite specific with the > questioner's environment (including hardware quirks) and hard to > answer. The headphone issue is present only in snd_hda(4), and it's because many HDA manufacturers assign non-standard mappings to the headphone and jack pins, so the driver needs to be manually patched in order to support them. That being said, I am planning to attempt to automate the method with which we tell what the correct mappings should be. If this attempt works, it will most likely still not solve all cases, but might simplify things a bit. > Would be complexed to implement (automate). But parts of those is > possible by virtual_oss, by letting it create /dev/dsp, without number. > And ports supporting base OSS to default to unnumbered device. > > My basic assumption is that virtual_oss would be worth incorporated > in base at some time in the future. That's in the plans already. The only obstacle at the moment is that virutal_oss uses third party libraries. Christos