I know this has come up several times over the years, and I think it requires some magic to be done within the graphics driver to send the data over the wire along with the video (layman’s understanding at best), but I did a listdev today and saw this in the output:
Does the fact that it’s detected that controller as an Audio device mean that Haiku is recognising that an attached device is an audio device, or is that just surfacing information that the device itself is providing? I get that the third line is clearly output from the device itself, but the first line is giving me some (maybe false) hope.
Open devices apps, if there is no audio driver loaded for that device, it only means that HID is read correctly but I think that devs would have made an announce.
If there was a driver, I guess that you would be able to select it on Media preferences.
I think that we’re seeing the device and since it is HD Audio, we are able of initialising the mixer part. I would say that, for the moment, we’re at the step where the device would be able to decode the sound but as there’s no negotiation with the receiver, and no protocol, it wouldn’t know how to send it through the cable. It will be a long way to get that, HDMI is a moving target. See here, you will have an idea of the work to do.
Yeah ok, that makes sense. I was aware there was probably work to do with the connection itself but I was half hoping that the card would simply expose it as an HDA device and everything else would be magic
It could be magic. But HDMI, like other norms is written after devices are manufactured.
Some things are evolving so fast that if you wait for norms to be written, your device is already outdated when it arrives on the market.
So companies are working on a draft of the norm, when it even exists, and everyone add his own sauce… Most of time, your device ends up with 100% compatibility with the previous norm, perhaps 90% with the actual norm and 70% for the upcoming one. What will change percentages is only the weight of manufacturer on norm decision board. It’s quite noticeable if you’re looking at modes supported by wifi dongles but is unfortunately true for most things.
That’s not really the prolem here (yet). We didn’t even try to get it working. Maybe once we read the specs and do what they say, it will just work.
Also, there are specifications from Intel (for example) on both HDA graphics and Intel audio, where they document how their hardware works. And we also have other OS sourcecode to look at. So it should not be too much of a problem.
I’ve had a quick sniff around other code bases but wasn’t really sure where to start looking. I’m guessing it’s going to be device specific drivers, and in my case it’s an nvidia card so I’m guessing the Nouveau driver would be a good starting point. I use HDMI audio from Linux on the same machine but it’s with the proprietary binary driver from nVidia.
Drivers are not something I’ve touched previously but might be time to try and get stuck in a little and learn a bit!
Yes, nVidia will be more complicated, since currently we have no driver at all for it. Maybe not the best hardware choice for a Haiku machine, until someone writes a driver for it.
Yes, the Framebuffer and VESA driver rely on code in the video card ROM to set things up. Unfortunately, there is only so much the manufacturers of the videocards will put there, usually just enough to get the BIOS setup screen and the OS splash screen. Then they expect more complete drivers, specific to each OS, to take over after that.
