Le 01/05/2020 à 17:30, Stuart Henderson a écrit :
On 2020/05/01 17:16, Damien Couderc wrote:
Le 01/05/2020 à 15:01, Mark Kettenis a écrit :
Date: Fri, 1 May 2020 14:17:56 +0200
From: Alexandre Ratchov <a...@caoua.org>
On Fri, May 01, 2020 at 01:11:16PM +0200, Damien Couderc wrote:
Speaking of the hdmi-only devices that were disabled in 2009: does the
project still stand on this position in 2020? I made a quick search and it
seems that more than half of the screens are audio capable now. I understand
the defaults back in 2009, but now is it still true?
There's nothing wrong with hdmi-only devices. As long as audio works
by default with no tweaks, nobody will object to re-enabling
them. AFAIK, this was the only reason to disable them.
Right. The main issue was that by default we only send output to
audio0. On many machines the audio device associated with the HDMI
port appears before the audio device that is associated with the
speakers and/or headphone jack on our laptops. Therefore by default
audio would go to an unconnected HDMI. Just enabling digital-only
devices would not work.
There are a couple things we could do here.
1. Make sndiod(8) responsible for picking a default output device.
I thought it was the case with the -f and -F options:
-F device
Specify an alternate device to use. If it doesn't work, the
one
given with the last -f or -F options will be used. For
instance,
specifying a USB device following a PCI device allows sndiod to
use the USB one preferably when it's connected and to fall back
to the PCI one when it's disconnected.
-f device
Add this sndio(7) audio device to devices used for playing
and/or
recording. Preceding per-device options (-aberwz) apply to
this
device. Sub-devices (-s) that are applied after will be
attached
to this device. Device mode and parameters are determined from
sub-devices attached to it.
So if I'm not wrong it could be possible to set the -f option with the
analog device and the -F option with the digital-only one.
These flags are to cope with a new audio device connected at runtime,
for example so you can set it to use audio1 if the device is available,
otherwise use audio0.
The problem with HDMI audio is that the device *is* available but the
output often doesn't go anywhere. This mechanism doesn't help that case.
It's possible to sense it the HDMI is connected or not like what you can
see with mixerctl:
outputs.digital-out_sou=dac-0:1
outputs.digital-out2_so=dac-2:3
outputs.digital-out3_so=dac-4:5
outputs.digital-out4_so=dac-6:7
outputs.digital-out5_so=dac-8:9
outputs.digital-out6_so=dac-10:11
outputs.digital-out_sen=plugged
outputs.digital-out2_se=unplugged
outputs.digital-out3_se=unplugged
outputs.digital-out4_se=unplugged
outputs.digital-out5_se=unplugged
outputs.digital-out6_se=unplugged
record.enable=sysctl
In this case, the digital-out sensor is plugged.
That said, I tried my proposition and it's not working. I suspect it's
related to the fact that the digital-out sensor is not checked or
something related.
Regards,
Damien
