From nobody Wed Dec 20 01:02:08 2023 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 4SvwJM08Jmz54Kx9 for ; Wed, 20 Dec 2023 01:02:11 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SvwJL1ksjz3Y2t for ; Wed, 20 Dec 2023 01:02:10 +0000 (UTC) (envelope-from mavbsd@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=TM++LYm+; spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::1132 as permitted sender) smtp.mailfrom=mavbsd@gmail.com; dmarc=none Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-5e75005bd0cso19739627b3.1 for ; Tue, 19 Dec 2023 17:02:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703034129; x=1703638929; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=213mbiqrBnXUDm67DGKCctV4e4bahf8ddzKQDcDOmpA=; b=TM++LYm+QCFFDfEy99s9lCCdXE5TcCF1KcQhDgZ7418PGRpoO6mXMXtsB5gwDcXr94 NB/3La6P2d1VIm/NVaWCw+RM0aEGsYTu1Hn3E7LjuHPvgcqEfK283qlOmoIqUGScSUMt C1MBnirKxU+F8wFSF35BRHdsZTadbQhc4ZkF/NL7NUzYqBJmBOX8G1ZQVVkBCDpYlNLC NvLLI2NdSs1SQD+8HEc63gVAdMF+0DkG7Y863K7PXJiysj4Snn32vLChI60CrrhQnSD4 yT9TLVft+A8ox5U/wX6DguCELD8nvg3ZbxXY74hIPf+tJ3b+I67XD/HZ76HGFeL0dnKP 9gIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703034129; x=1703638929; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=213mbiqrBnXUDm67DGKCctV4e4bahf8ddzKQDcDOmpA=; b=gE5Iwn3iyFD3IF+Rf25xsodDVlgWToYFrwHq2SA7wvwbnjuQpHf+xFN69YmuyD2LFv /m0FZpZmGVaJei0IdWaJ23ZGWxYpRdvUOsgKwEE0N8i/5bAuvahwo6X2+1B95jvHucoQ 4Q8/LvcjPzTlgDjepd3kYWAuU4+YVNfb/egWCF+BH6JJjhGk8ve6k+TWhZd6YTBHH7ep xRNFZfdUtUQnEt+5tsrp1GMQIJm7f5cMlMXfSl1MlaqN/2F2UKFx/VILipsAGpKxjAgc O1P6cYg+pJy/R67+9+Eim4iR7npczRTG1Fg+hyfcaxyw9nClZHHuTNKp2BUu2n6BFzwA 9rug== X-Gm-Message-State: AOJu0YxOoQ8yl/1SUZIBhaW8Woof6OfKzN6Pfy9SrCYwe+mp8OY3lPgh vc93U4Rqm2sTKpMQJ0o84j0= X-Google-Smtp-Source: AGHT+IFCLAn5+q//u4xNRlNVeBYp6HKYITc8RSE4AZlo5rr0y3IQbz7vDmWf6yp1dZkHwbzSAW8D4w== X-Received: by 2002:a81:d550:0:b0:5d3:7c6d:59b1 with SMTP id l16-20020a81d550000000b005d37c6d59b1mr16980439ywj.16.1703034129150; Tue, 19 Dec 2023 17:02:09 -0800 (PST) Received: from ?IPV6:2600:1700:3580:3560:228:f8ff:fe04:d12? ([2600:1700:3580:3560:228:f8ff:fe04:d12]) by smtp.gmail.com with ESMTPSA id e7-20020a81dd07000000b005d755416307sm10048459ywn.73.2023.12.19.17.02.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Dec 2023 17:02:08 -0800 (PST) Message-ID: <4f5f9712-e759-c032-84bf-1a1dfe15e012@FreeBSD.org> Date: Tue, 19 Dec 2023 20:02:08 -0500 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 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: RFC - Work on FreeBSD's Audio Stack Content-Language: en-US To: Joseph Mingrone , freebsd-multimedia@freebsd.org References: <86ttomxg11.fsf@phe.ftfl.ca> <86y1dxpjzy.fsf@phe.ftfl.ca> From: Alexander Motin In-Reply-To: <86y1dxpjzy.fsf@phe.ftfl.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-3.20 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_NA(0.00)[freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-multimedia@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::1132:from]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; MLMMJ_DEST(0.00)[freebsd-multimedia@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4SvwJL1ksjz3Y2t X-Spamd-Bar: --- 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..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