Date: Fri, 4 Oct 2024 01:57:44 +0900 From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> To: Christos Margiolis <christos@freebsd.org> Cc: Alban Hertroys <haramrae@gmail.com>, Dag-Erling =?UTF-8?B?U23DuHJncmF2?= <des@freebsd.org>, freebsd-stable@freebsd.org Subject: Re: uaudio device re-attach and persisting dev.pcm.$pcm.bitperfect sysctl Message-ID: <20241004015744.6a735e6e3c041ac9d94df44f@dec.sakura.ne.jp> In-Reply-To: <a6yj4i77rojmuu4ihyqgmiwfqy5l2wqnxl67xjrv4a7f64vewi@ziewxaoklgrt> References: <F61ECC96-6FCB-4A4E-9EEC-8D6AF31A8A62@gmail.com> <86ploiwxw8.fsf@ltc.des.dev> <8745F9FB-9CC1-476C-9445-DC0A7A76165F@gmail.com> <fgpuue37atkszq5hbty2ec47c47nd3dpokrdhl4g4b3qlh4po2@luayn4ocxtpw> <20241003231016.47f74f2d2ada7b4a76d065dd@dec.sakura.ne.jp> <a6yj4i77rojmuu4ihyqgmiwfqy5l2wqnxl67xjrv4a7f64vewi@ziewxaoklgrt>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 3 Oct 2024 17:30:57 +0300 Christos Margiolis <christos@freebsd.org> wrote: > 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? Assuming there are 2 audio outoputs via HDMI as /dev/pcm0 and /dev/pcm1 1 audio output via PC speaker (i.e., HDA) as /dev/pcm2 1 audio output via headphone connetor as /dev/pcm3 at start, if snddetect_enable="YES" is set on /etc/rc.conf[.local], the last /dev/pcm3 would be chosen as default. If not, IIRC (not even tried for a long time), /dev/pcm0 was the default. What I meant is "if /dev/pcm always automatically points to configured default, configuring /dev/pcm as the only audio device for audio and multimedia apps which directly supports base OSS on ports tree would be easiest to use. > > *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. Exactly. But unfortunately, HDA seems to be the majority now. Don't know how other OS'es are resolving the "quirks". If the headphone jack is made like as was in old radios and/or TVs, include physical switch in itself, the problem cannot happen. (As when internal switch in the jack is pushed by the phone plug, the electric circuit to speaker is opened (shut down) and to the phone is closed (functional) and when unplugged, the switch does the reverse. Of course, it is not at all good for sound qualitiy.) People who doesn't know the HDA problem (in their physical impleentations) would expect the headphone jack to work as above. And so would be as anything plugged/unplugged after boot. Automating "as natural human naturally expect" selection/routing would help it, but if active device name always switches on each auto selection makes users confused. So if fixed device name like /dev/pcm (without number) always routed to active default device, it would be helpful. > > 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 Glad to know it! Thanks in advance. -- Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20241004015744.6a735e6e3c041ac9d94df44f>