Date: Tue, 19 Dec 2023 20:02:08 -0500 From: Alexander Motin <mav@FreeBSD.org> To: Joseph Mingrone <jrm@freebsdfoundation.org>, freebsd-multimedia@freebsd.org Subject: Re: RFC - Work on FreeBSD's Audio Stack Message-ID: <4f5f9712-e759-c032-84bf-1a1dfe15e012@FreeBSD.org> In-Reply-To: <86y1dxpjzy.fsf@phe.ftfl.ca> References: <86ttomxg11.fsf@phe.ftfl.ca> <86y1dxpjzy.fsf@phe.ftfl.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On 13.12.2023 21:59, Joseph Mingrone wrote: > snd hda(4) pin-patching > > Regarding the stability of the audio stack, the project will address the pin-patching issue present in the snd hda(4) (Intel > High Definition Audio) driver. Essentially, some laptop models have non-standardized mappings for the headphone and > speaker jack pins, which results in absence of audio from the headphones, until a patch is manually applied in snd hda(4) > to correctly map the headphone and speaker pins for that model so that the same audio stream is output from both the > speakers and headphones when they are plugged in. > > The initial strategy to address the issue will be to see if it is possible to do the patching automatically by figuring out > what the Speaker pin’s as number is (see dev.hdac.<n>.pindump=1) and "forcibly" assign the same value to the headphone > jack pin as well. The following solutions follow the same logic: > > - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273809 > - https://i-bsd.com/freebsd-wireless-8265/ > > OpenBSD’s azalia(4) (their version of the HDA driver) will also serve as a point of reference, even though it too contains > a kind of manual patching mechanism. I believe this is a dead end, not a proper solution. In early days of HDA it was quite typical to have pins configuration just plain broken, and patching was the only way to make it work. But since Microsoft in some Windows version started to use the pins configuration, most of hardware vendors fixed the pin configurations. These days it is not so much of a problem. The problem now is that Windows implement different ideology of sound redirection. Instead of relying on CODEC features, they redirect sound in software, switching playback/recording between devices on fly. That is what I think we should actually do -- export information about connection status (which HDA driver already has) to the sound subsystem and make it change default device dynamically and in real time, stopping playback/recording on one device and starting another. It sounds pretty close to the hot-swapping sub-project below, except I am not sure it needs virtual oss, since kernel already knows how to convert channels formats, etc, if needed. > Hot-swapping > > Users of plain OSS, that is, without virtual oss, will have noticed that hot-swapping audio devices (i.e changing the default > unit, hw.snd.default unit) mid-track does not work and sound keeps coming out of the previous device until the track > is restarted. This is because applications open(2) the device at the start of playback and close(2) it when the track has > stopped. virtual oss(8) can create a virtual audio device responsible for routing audio to the appropriate physical audio > device. The device(s) sound is routed to can be changed at run-time using virtual oss cmd(8). > > This method has the advantage that sound can be re-routed to different devices while applications keep the same /dev/dsp > open; virtual oss(8) will make any necessary conversions on the fly and redirect audio to the new device without requiring > a restart of the track/application. > > This functionality will be embedded in either mixer(8) or the new audio(8) program. -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4f5f9712-e759-c032-84bf-1a1dfe15e012>