Re: Audio over hdmi
On Fri, May 01, 2020 at 05:16:10PM +0200, Damien Couderc wrote: > > 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. > > That said, it would work only if you have two audio device (e.g. HDMI from > video card as audio0 and analog from soundcard as audio1). > > This is not true on Thinkpad laptops for example because they have two > output codecs on the same device for both analog and digital (and only one > is kept actually). > > Maybe we could make first analog and first digital codec available on each > audio device. Then sndiod would take the first analog and the first digital > from the devices in the given order. Does it sound sane? -F is just a tool to *ease* switching between devices, but doesn't solve the "default device problem" completely. It's intended to be used as follows: -f rsnd/0 -F rsnd/1 -F rsnd/2 ... which might become the default. This way if there's only one sound-card, it's used. If the user connects a new device, the new one is used until it's disconnected. That works by pure luck because attach order maches device priority. To apply this model to hdmi, there must be a mean to detect if it's connected to speakers and make it fail if it is not, so it can be skipped. If we can't detect whether it's connected, we must be sure it won't be used instead of the others. But even if hdmi has properly detected speakers, the user may want to use the analog one because it is more capable, for instance for telephony. AFAICS, this general problem can't be solved by just adding the hdmi device with the proper minor number, changes will be needed in many places of the audio sub-system. In the short term if you make sure the digital codec and the hdmi-only device properly work, never attache as audio0 and speakers are detected, the current defaults will work and nobody will complain. This would be a big step forward. my 2 cents
Re: Audio over hdmi
> From: Damien Couderc > Date: Fri, 1 May 2020 18:24:12 +0200 > > 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 > > 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. There are tentacles in amdgpu(4), inteldrm(4) and radeondrm(4) that probably need to be hooked up properly to make that work.
Re: Audio over hdmi
On Fri, May 01, 2020 at 03:01:04PM +0200, Mark Kettenis wrote: > > Date: Fri, 1 May 2020 14:17:56 +0200 > > From: Alexandre Ratchov > > > > 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. > > 2. Use locators (like I did for drm(4) and wsdisplay(4)) such that >audio0 is always the non-HDMI audio device. > > Option #2 has the downside that if your HDMI audio device is the only > supported audio device in the system, it will still be audio1 and > therefore not the default device. On the other hand that has the > benefit that if you later plug something like uaudio(4) into your > system it will become the default device. Since recently, sndiod can switch between devices. So with minimal tweaks we could make it use audio1 if audio0 is not present. Detecting if the hdmi codec is commected could ease this further > Option #1 would give us more flexibility, but I'm not sure if the > current audio(4) ioctls allow us to implement the proper heuristics. > > > > About the multi-codec devices, how do you see it ? Keeping all the codecs > > > and adding a knob to switch between analog and digital to select the > > > codec > > > This seems to make sense. > > It's never entirely clear to me what exactly a "codec" is. Basically there's are two chips: a PCI chip (the host) that does only DMA and talks through a simple serial link to the other chip (the codec) which has a bunch of DACs, ADCs, optical transmitters, the HDMI interfaces and so on. The interface between these is standardized. HDA host chips can handle multiple codecs, not sure if they are trully independent, specs say they are.
Re: Audio over hdmi
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 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
Re: Audio over hdmi
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 > > > > > > 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.
Re: Audio over hdmi
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 > >> > >> 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. I think it is nasty that people must start restart sndiod, and all their applications.
Re: Audio over hdmi
Le 01/05/2020 à 15:01, Mark Kettenis a écrit : Date: Fri, 1 May 2020 14:17:56 +0200 From: Alexandre Ratchov 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. That said, it would work only if you have two audio device (e.g. HDMI from video card as audio0 and analog from soundcard as audio1). This is not true on Thinkpad laptops for example because they have two output codecs on the same device for both analog and digital (and only one is kept actually). Maybe we could make first analog and first digital codec available on each audio device. Then sndiod would take the first analog and the first digital from the devices in the given order. Does it sound sane? 2. Use locators (like I did for drm(4) and wsdisplay(4)) such that audio0 is always the non-HDMI audio device. Option #2 has the downside that if your HDMI audio device is the only supported audio device in the system, it will still be audio1 and therefore not the default device. On the other hand that has the benefit that if you later plug something like uaudio(4) into your system it will become the default device. Option #1 would give us more flexibility, but I'm not sure if the current audio(4) ioctls allow us to implement the proper heuristics. About the multi-codec devices, how do you see it ? Keeping all the codecs and adding a knob to switch between analog and digital to select the codec > This seems to make sense. It's never entirely clear to me what exactly a "codec" is. But if it is possible to use both codecs simultaniously and indipendently, it would make sense to provide audio(4) devices for both.
Re: Audio over hdmi
Chris Bennett wrote: > On Fri, May 01, 2020 at 02:17:56PM +0200, Alexandre Ratchov wrote: > > 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. > > > > > About the multi-codec devices, how do you see it ? Keeping all the codecs > > > and adding a knob to switch between analog and digital to select the > > > codec ? > > > > This seems to make sense. > > > > I would deeply appreciate it if HDMI with audio could be activated. It cannot be turned on at this point, because on many machines HDMI audio will precede azalia, and so the default behaviour for those people will be silence. First step is to make it much easier to select alternative default audio (to INSIST on a specific audio device being the "primary", without having to add flags to every application)
Re: Audio over hdmi
On Fri, May 01, 2020 at 02:17:56PM +0200, Alexandre Ratchov wrote: > 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. > > > About the multi-codec devices, how do you see it ? Keeping all the codecs > > and adding a knob to switch between analog and digital to select the codec ? > > This seems to make sense. > I would deeply appreciate it if HDMI with audio could be activated. My laptop has a hideous screen and the audio cannot turn off the speakers when I only want to use the headphones. My eyes are not so good anymore, so a bigger screen, 2nd screen would be great. OTH, something is broken in the hardware or -current for a long time, so I'm stuck at 6.6-stable. Still have the same vision problem, though. Chris Bennett
Re: Audio over hdmi
> Date: Fri, 1 May 2020 14:17:56 +0200 > From: Alexandre Ratchov > > 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. 2. Use locators (like I did for drm(4) and wsdisplay(4)) such that audio0 is always the non-HDMI audio device. Option #2 has the downside that if your HDMI audio device is the only supported audio device in the system, it will still be audio1 and therefore not the default device. On the other hand that has the benefit that if you later plug something like uaudio(4) into your system it will become the default device. Option #1 would give us more flexibility, but I'm not sure if the current audio(4) ioctls allow us to implement the proper heuristics. > > About the multi-codec devices, how do you see it ? Keeping all the codecs > > and adding a knob to switch between analog and digital to select the codec > > > > This seems to make sense. It's never entirely clear to me what exactly a "codec" is. But if it is possible to use both codecs simultaniously and indipendently, it would make sense to provide audio(4) devices for both.
Re: Audio over hdmi
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. > About the multi-codec devices, how do you see it ? Keeping all the codecs > and adding a knob to switch between analog and digital to select the codec ? This seems to make sense.
Re: Audio over hdmi
On 26/04/2020 06:58, Alexandre Ratchov wrote: On Sat, Apr 25, 2020 at 05:16:03PM +0200, Damien Couderc wrote: I can see in the full dmesg that there are two different FTYPE results provided during azalia_codec_init and only the first one seems to be displayed in the mixerctl output. I think that maybe mixerctl does not recurse all the audio functions or that some bits aren't recorded. I'll take a look. Ok, I did a bit of reading and from what I understood there are 2 detected codecs (0 and 2) for the same instance of azalia but the latest is deleted in azalia_init_codecs() because there is only one that can be enabled. Alexandre could maybe tell us what is possible to do here. I think it's maybe possible to keep all detected codecs but to change which one is enabled. Hi, Sorry couldn't test your diff, my machines have one codec only. The azalia driver can handle only one codec at a time. Multiple codecs can't be presented as different devices because they can't be used at the same time. Quickly adding support for multiple codecs would need to expose "mixer" controls of all the codecs and the ability to switch between them. This may look difficult but in most (all?) real-world cases there is at most 1 analog and 1 digital codec and the latter has very few controls, if any. Independenty, support for the hdmi-only devices, present on certain graphics cards was removed as they were not useful, but used to attach as audio0, i.e. they took the place of the default audio device, which made audio not work by default. But this is not related to your patch. HTH Thank you Alexandre. 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? About the multi-codec devices, how do you see it ? Keeping all the codecs and adding a knob to switch between analog and digital to select the codec ? Regards, Damien
Re: Audio over hdmi
On Sat, Apr 25, 2020 at 05:16:03PM +0200, Damien Couderc wrote: > > > > I can see in the full dmesg that there are two different FTYPE results > > provided during azalia_codec_init and only the first one seems to be > > displayed in the mixerctl output. > > > > I think that maybe mixerctl does not recurse all the audio functions or > > that some bits aren't recorded. I'll take a look. > > Ok, I did a bit of reading and from what I understood there are 2 detected > codecs (0 and 2) for the same instance of azalia but the latest is deleted > in azalia_init_codecs() because there is only one that can be enabled. > > Alexandre could maybe tell us what is possible to do here. I think it's > maybe possible to keep all detected codecs but to change which one is > enabled. Hi, Sorry couldn't test your diff, my machines have one codec only. The azalia driver can handle only one codec at a time. Multiple codecs can't be presented as different devices because they can't be used at the same time. Quickly adding support for multiple codecs would need to expose "mixer" controls of all the codecs and the ability to switch between them. This may look difficult but in most (all?) real-world cases there is at most 1 analog and 1 digital codec and the latter has very few controls, if any. Independenty, support for the hdmi-only devices, present on certain graphics cards was removed as they were not useful, but used to attach as audio0, i.e. they took the place of the default audio device, which made audio not work by default. But this is not related to your patch. HTH
Re: Audio over hdmi
Le 25/04/2020 à 13:33, Damien Couderc a écrit :
Le 25/04/2020 à 12:33, Damien Couderc a écrit :
Le 25/04/2020 à 12:13, Solene Rapenne a écrit :
Le Sat, 25 Apr 2020 11:36:12 +0200,
Damien Couderc a écrit :
Hi,
I decided to take a look at what was missing to make audio over hdmi
working on OpenBSD.
After enabling AZALIA_DEBUG in the kernel config I commented the code
that disables HDMI codecs like the following :
--- azalia.c.orig Thu Apr 23 11:44:52 2020
+++ azalia.c Fri Apr 24 12:53:15 2020
@@ -926,9 +926,11 @@
c = -1;
for (i = 0; i < az->ncodecs; i++) {
codec = >codecs[i];
+/*
if ((codec->audiofunc < 0) ||
(codec->codec_type == AZ_CODEC_TYPE_HDMI))
continue;
+*/
if (codec->codec_type == AZ_CODEC_TYPE_DIGITAL) {
if (c < 0)
c = i;
And after rebooting with the modified kernel audio over HDMI was
working out of the box (see the following diff).
I suspect that it is pure luck, what could I miss ?
Could someone test it on Intel based computers ?
hello,
I tried your diff but I'm not sure how to play sound on the screen.
From the FAQ i changed sndiod default output device
# rcctl set sndiod flags -f rsnd/1
# rcctl restart sndiod
but if I run aucat I get the error "default: couldn't open audio device"
Hi solene,
I don't think you need to change sndiod's settings as your device is
already audio0.
That said, I think the Intel audio chip has at least 3 outputs on your
laptop: headphones, speakers and HDMI. And the trick must be to set
the HDMI as default.
Could you show me your mixerctl output ?
Ok so I upgraded my laptop to current and connected it to the same audio
capable screen.
I can see in the dmesg the following (full dmesg provided at the end):
azalia0: unknown03
wcap=40778d
cap=994
[01/00] color=unknown device=digital-out conn=jack conntype=digital
location=spec1 chassis=internal special=hdmi
outamp: mute=1 size=0 steps=0 offset=0
connections=0x2; selected=0x2
azalia_codec_sort_pins: analog out pins:
azalia_codec_sort_pins: digital out pins: 0x03->0x02
azalia_codec_sort_pins: analog in pins:
azalia_codec_sort_pins: digital in pins:
azalia0: dacgroup[0]: 02
azalia0: codecs: Realtek/0x0293, Intel/0x2809, using Realtek/0x0293
audio0 at azalia0
The problem is that outputs.digital-out is not displayed by mixerctl :
inputs.dac-2:3=126,126
inputs.dac-0:1=126,126
record.adc-0:1_mute=off
record.adc-0:1=124,124
record.adc-2:3_mute=off
record.adc-2:3=124,124
record.adc-4:5_mute=off
record.adc-4:5=124,124
inputs.mix_source=mic2
inputs.mix_mic2=120,120
inputs.mix2_source=dac-2:3,mix
inputs.mix3_source=dac-0:1,mix
inputs.mic=85,85
outputs.spkr_source=mix2
outputs.spkr_mute=off
outputs.spkr_eapd=on
outputs.hp_source=mix3
outputs.hp_mute=off
outputs.hp_boost=off
outputs.hp_eapd=on
inputs.mic2=85,85
outputs.mic2_dir=input-vr80
record.adc-4:5_source=mic2
record.adc-2:3_source=mic2
record.adc-0:1_source=mic
outputs.hp_sense=unplugged
outputs.mic2_sense=unplugged
outputs.spkr_muters=hp
outputs.master=126,126
outputs.master.mute=off
outputs.master.slaves=dac-2:3,dac-0:1,spkr,hp
record.volume=124,124
record.volume.mute=off
record.volume.slaves=adc-0:1,adc-2:3,adc-4:5
record.enable=sysctl
I can see in the full dmesg that there are two different FTYPE results
provided during azalia_codec_init and only the first one seems to be
displayed in the mixerctl output.
I think that maybe mixerctl does not recurse all the audio functions or
that some bits aren't recorded. I'll take a look.
Ok, I did a bit of reading and from what I understood there are 2
detected codecs (0 and 2) for the same instance of azalia but the latest
is deleted in azalia_init_codecs() because there is only one that can be
enabled.
Alexandre could maybe tell us what is possible to do here. I think it's
maybe possible to keep all detected codecs but to change which one is
enabled.
Re: Audio over hdmi
Le 25/04/2020 à 12:33, Damien Couderc a écrit :
Le 25/04/2020 à 12:13, Solene Rapenne a écrit :
Le Sat, 25 Apr 2020 11:36:12 +0200,
Damien Couderc a écrit :
Hi,
I decided to take a look at what was missing to make audio over hdmi
working on OpenBSD.
After enabling AZALIA_DEBUG in the kernel config I commented the code
that disables HDMI codecs like the following :
--- azalia.c.orig Thu Apr 23 11:44:52 2020
+++ azalia.c Fri Apr 24 12:53:15 2020
@@ -926,9 +926,11 @@
c = -1;
for (i = 0; i < az->ncodecs; i++) {
codec = >codecs[i];
+/*
if ((codec->audiofunc < 0) ||
(codec->codec_type == AZ_CODEC_TYPE_HDMI))
continue;
+*/
if (codec->codec_type == AZ_CODEC_TYPE_DIGITAL) {
if (c < 0)
c = i;
And after rebooting with the modified kernel audio over HDMI was
working out of the box (see the following diff).
I suspect that it is pure luck, what could I miss ?
Could someone test it on Intel based computers ?
hello,
I tried your diff but I'm not sure how to play sound on the screen.
From the FAQ i changed sndiod default output device
# rcctl set sndiod flags -f rsnd/1
# rcctl restart sndiod
but if I run aucat I get the error "default: couldn't open audio device"
Hi solene,
I don't think you need to change sndiod's settings as your device is
already audio0.
That said, I think the Intel audio chip has at least 3 outputs on your
laptop: headphones, speakers and HDMI. And the trick must be to set the
HDMI as default.
Could you show me your mixerctl output ?
Ok so I upgraded my laptop to current and connected it to the same audio
capable screen.
I can see in the dmesg the following (full dmesg provided at the end):
azalia0: unknown03
wcap=40778d
cap=994
[01/00] color=unknown device=digital-out conn=jack conntype=digital
location=spec1 chassis=internal special=hdmi
outamp: mute=1 size=0 steps=0 offset=0
connections=0x2; selected=0x2
azalia_codec_sort_pins: analog out pins:
azalia_codec_sort_pins: digital out pins: 0x03->0x02
azalia_codec_sort_pins: analog in pins:
azalia_codec_sort_pins: digital in pins:
azalia0: dacgroup[0]: 02
azalia0: codecs: Realtek/0x0293, Intel/0x2809, using Realtek/0x0293
audio0 at azalia0
The problem is that outputs.digital-out is not displayed by mixerctl :
inputs.dac-2:3=126,126
inputs.dac-0:1=126,126
record.adc-0:1_mute=off
record.adc-0:1=124,124
record.adc-2:3_mute=off
record.adc-2:3=124,124
record.adc-4:5_mute=off
record.adc-4:5=124,124
inputs.mix_source=mic2
inputs.mix_mic2=120,120
inputs.mix2_source=dac-2:3,mix
inputs.mix3_source=dac-0:1,mix
inputs.mic=85,85
outputs.spkr_source=mix2
outputs.spkr_mute=off
outputs.spkr_eapd=on
outputs.hp_source=mix3
outputs.hp_mute=off
outputs.hp_boost=off
outputs.hp_eapd=on
inputs.mic2=85,85
outputs.mic2_dir=input-vr80
record.adc-4:5_source=mic2
record.adc-2:3_source=mic2
record.adc-0:1_source=mic
outputs.hp_sense=unplugged
outputs.mic2_sense=unplugged
outputs.spkr_muters=hp
outputs.master=126,126
outputs.master.mute=off
outputs.master.slaves=dac-2:3,dac-0:1,spkr,hp
record.volume=124,124
record.volume.mute=off
record.volume.slaves=adc-0:1,adc-2:3,adc-4:5
record.enable=sysctl
I can see in the full dmesg that there are two different FTYPE results
provided during azalia_codec_init and only the first one seems to be
displayed in the mixerctl output.
I think that maybe mixerctl does not recurse all the audio functions or
that some bits aren't recorded. I'll take a look.
Here is the full dmesg:
OpenBSD 6.7-beta (GENERIC.MP) #3: Fri Apr 24 12:53:39 CEST 2020
damien@current.petrolan:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17012170752 (16224MB)
avail mem = 16483958784 (15720MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xd7082000 (65 entries)
bios0: vendor LENOVO version "N1KET41W (1.28 )" date 09/12/2018
bios0: LENOVO 20FH001FFR
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP TCPA SSDT UEFI SSDT SSDT ECDT HPET APIC MCFG
SSDT DBGP DBG2 BOOT BATB SLIC SSDT SSDT MSDM DMAR ASF! FPDT UEFI
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2195.76 MHz, 06-4e-03
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,
Re: Audio over hdmi
Le 25/04/2020 à 12:13, Solene Rapenne a écrit :
Le Sat, 25 Apr 2020 11:36:12 +0200,
Damien Couderc a écrit :
Hi,
I decided to take a look at what was missing to make audio over hdmi
working on OpenBSD.
After enabling AZALIA_DEBUG in the kernel config I commented the code
that disables HDMI codecs like the following :
--- azalia.c.orig Thu Apr 23 11:44:52 2020
+++ azalia.cFri Apr 24 12:53:15 2020
@@ -926,9 +926,11 @@
c = -1;
for (i = 0; i < az->ncodecs; i++) {
codec = >codecs[i];
+/*
if ((codec->audiofunc < 0) ||
(codec->codec_type == AZ_CODEC_TYPE_HDMI))
continue;
+*/
if (codec->codec_type == AZ_CODEC_TYPE_DIGITAL) {
if (c < 0)
c = i;
And after rebooting with the modified kernel audio over HDMI was
working out of the box (see the following diff).
I suspect that it is pure luck, what could I miss ?
Could someone test it on Intel based computers ?
hello,
I tried your diff but I'm not sure how to play sound on the screen.
From the FAQ i changed sndiod default output device
# rcctl set sndiod flags -f rsnd/1
# rcctl restart sndiod
but if I run aucat I get the error "default: couldn't open audio device"
Hi solene,
I don't think you need to change sndiod's settings as your device is
already audio0.
That said, I think the Intel audio chip has at least 3 outputs on your
laptop: headphones, speakers and HDMI. And the trick must be to set the
HDMI as default.
Could you show me your mixerctl output ?
Regards,
Damien
dmesg
OpenBSD 6.7-beta (GENERIC.MP) #0: Sat Apr 25 12:02:14 CEST 2020
solene@solene.perso.local:/sys/arch/amd64/compile/GENERIC.MP
real mem = 8323534848 (7937MB)
avail mem = 8058654720 (7685MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xaf07e000 (63 entries)
bios0: vendor LENOVO version "N24ET51W (1.26 )" date 08/30/2019
bios0: LENOVO 20L5CTO1WW
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT
SSDT SSDT BOOT BATB SLIC SSDT SSDT SSDT LPIT WSMT SSDT SSDT SSDT DBGP DBG2 MSDM
DMAR ASF! FPDT UEFI BGRT
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4)
RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4)
RP06(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.82 MHz, 06-8e-0a
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.06 MHz, 06-8e-0a
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.06 MHz, 06-8e-0a
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.06 MHz, 06-8e-0a
cpu3:
Re: Audio over hdmi
Le Sat, 25 Apr 2020 11:36:12 +0200,
Damien Couderc a écrit :
> Hi,
>
> I decided to take a look at what was missing to make audio over hdmi
> working on OpenBSD.
>
> After enabling AZALIA_DEBUG in the kernel config I commented the code
> that disables HDMI codecs like the following :
>
>
> --- azalia.c.orig Thu Apr 23 11:44:52 2020
> +++ azalia.c Fri Apr 24 12:53:15 2020
> @@ -926,9 +926,11 @@
> c = -1;
> for (i = 0; i < az->ncodecs; i++) {
> codec = >codecs[i];
> +/*
> if ((codec->audiofunc < 0) ||
> (codec->codec_type == AZ_CODEC_TYPE_HDMI))
> continue;
> +*/
> if (codec->codec_type == AZ_CODEC_TYPE_DIGITAL) {
> if (c < 0)
> c = i;
>
>
> And after rebooting with the modified kernel audio over HDMI was
> working out of the box (see the following diff).
>
> I suspect that it is pure luck, what could I miss ?
> Could someone test it on Intel based computers ?
>
hello,
I tried your diff but I'm not sure how to play sound on the screen.
From the FAQ i changed sndiod default output device
# rcctl set sndiod flags -f rsnd/1
# rcctl restart sndiod
but if I run aucat I get the error "default: couldn't open audio device"
dmesg
OpenBSD 6.7-beta (GENERIC.MP) #0: Sat Apr 25 12:02:14 CEST 2020
solene@solene.perso.local:/sys/arch/amd64/compile/GENERIC.MP
real mem = 8323534848 (7937MB)
avail mem = 8058654720 (7685MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xaf07e000 (63 entries)
bios0: vendor LENOVO version "N24ET51W (1.26 )" date 08/30/2019
bios0: LENOVO 20L5CTO1WW
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT SSDT TPM2 UEFI SSDT SSDT HPET APIC MCFG ECDT SSDT
SSDT SSDT BOOT BATB SLIC SSDT SSDT SSDT LPIT WSMT SSDT SSDT SSDT DBGP DBG2 MSDM
DMAR ASF! FPDT UEFI BGRT
acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4)
RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4)
RP06(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.82 MHz, 06-8e-0a
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.06 MHz, 06-8e-0a
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.06 MHz, 06-8e-0a
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 1696.06 MHz, 06-8e-0a
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE
Audio over hdmi
Hi,
I decided to take a look at what was missing to make audio over hdmi
working on OpenBSD.
After enabling AZALIA_DEBUG in the kernel config I commented the code
that disables HDMI codecs like the following :
--- azalia.c.orig Thu Apr 23 11:44:52 2020
+++ azalia.cFri Apr 24 12:53:15 2020
@@ -926,9 +926,11 @@
c = -1;
for (i = 0; i < az->ncodecs; i++) {
codec = >codecs[i];
+/*
if ((codec->audiofunc < 0) ||
(codec->codec_type == AZ_CODEC_TYPE_HDMI))
continue;
+*/
if (codec->codec_type == AZ_CODEC_TYPE_DIGITAL) {
if (c < 0)
c = i;
And after rebooting with the modified kernel audio over HDMI was working
out of the box (see the following diff).
I suspect that it is pure luck, what could I miss ?
Could someone test it on Intel based computers ?
Here is the promised dmesg :
OpenBSD 6.7-beta (GENERIC.MP) #3: Fri Apr 24 12:53:39 CEST 2020
damien@current.petrolan:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34271739904 (32684MB)
avail mem = 33220448256 (31681MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xe94f0 (31 entries)
bios0: vendor American Megatrends Inc. version "P1.80" date 12/18/2018
bios0: ASRock B450 Gaming K4
acpi0 at bios0: ACPI 6.0
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT SSDT SSDT CRAT CDIT SSDT MCFG
AAFT HPET SSDT UEFI IVRS SSDT SSDT WSMT
acpi0: wakeup devices GPP0(S4) GPP1(S4) GPP3(S4) GPP4(S4) GPP5(S4)
GPP6(S4) GPP7(S4) GPP8(S4) GPP9(S4) GPPA(S4) GPPB(S4) GPPC(S4) GPPD(S4)
GPPE(S4) GPPF(S4) GP17(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Ryzen 7 2700 Eight-Core Processor, 3194.61 MHz, 17-08-02
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache
cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully
associative
cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully
associative
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Ryzen 7 2700 Eight-Core Processor, 3194.00 MHz, 17-08-02
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache
cpu1: ITLB 64 4KB entries fully associative, 64 4MB entries fully
associative
cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully
associative
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD Ryzen 7 2700 Eight-Core Processor, 3194.01 MHz, 17-08-02
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB
64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache
cpu2: ITLB 64 4KB entries fully associative, 64 4MB entries fully
associative
cpu2: DTLB 64 4KB entries fully associative, 64 4MB entries fully
associative
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: AMD Ryzen 7 2700 Eight-Core Processor, 3194.00 MHz, 17-08-02
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,T
