Hi all,
I would like to have sound on my computer with Haiku.
I can’t just say to devs “please just do it”, I wish I knew how to do it myself.
So how can I help, how can I learn to work on this driver?
Thanks 
1 Like
Have you tried a “warm” reboot, where first you cold boot another OS, then reboot into Haiku? This fixes I/O mappings for some chipsets (eg on my MacBookPro). Only via headphone out, not with internal speakers.
Alternatively, some boxes require a cold boot (my Realtek 1200C) for working sound (and wont work after a warm reboot).
Please test these various scenarios.
Your best first steps would be to checkout haiku’s source code and try building it. Then try playing with the driver and loading it. Once you have that process down, it’s just wash and repeat.
Everyone has to start somewhere 
Worst case, open a bug with a bunch of logs and data on what you’re encountering. That’s the second best way to help if you really can’t get into the development thing.
3 Likes
Does it means PCI BAR register and IRQ mappings? For RISC-V I made PCI resource allocator, it may also help for another platforms.
2 Likes
Thanks.
I really need to be more familiar with the system as I am with GNU/Linux.
I’m a big newb here 
HDA is actually something someone who is new to driver development could help out on by doing some testing and comparing to other operating systems. I believe much of the issues with our HDA is bad pin mapping. For those who don’t know, HDA is a standard around particular chips. Each kind of chip has a certain number of DACs and pins, and even the same chip could be hooked up in different ways on different motherboards. The chips are programmable and the operating system can adjust how things are routed. Some pins aren’t even hooked up, so it makes no sense to route sound to them. Also some pins have sensors that can tell when something is plugged in, so that for example the speakers in a laptop can be muted when headphones are plugged in. Pins are also grouped, so for example all he outputs for a 5.1 sound system are grouped.
Anyhow, sometimes the configuration for these pins is decent from the built-in firmware, sometimes it is not. Generally the HDA driver in the operating system is supposed to read the pin set up and figure out a reasonable way to set things up, and disconnected pins should be ignored, etc. Personally I don’t think the Haiku HDA driver does a very good job here. In fact I’m quite sure it does not properly ignore disconnected pins. Also some chips have weird quirks that have to be worked around.
So, why am I explaining all this? Most operating systems allow you to see how the HDA chip was set up. So if you have a device which works well in Linux or Windows (which of course it does), it might be useful to see how those systems set up the chip and comparing it to Haiku. Haiku logs this stuff in the syslog. Linux has some tools to see the pin set up after booting. Windows probably has something too. Also this is why a warm reboot can make sound work, the other OS set up the chip properly and then Haiku manages to not screw it up.
If you can collect some logs showing how Haiku sets up pins differently and collect those into a ticket it would be helpful. I think the logs Haiku writes for this are really hard to read, but if you can learn the understand them that will also help you learn enough to help on the driver later. Improving this logging would also be useful. I think the way FreeBSD logs it is really nice, this link has an example.
Another useful task would be to see what quirks other systems work around, at least for chips you can test.
17 Likes
why not give users the ability to configure HDA? it was possible to try and if it helped to add to the source code of the driver.
You mean everybody should post half-baked homebrew pinconfigs here to make the life of the newcomers even more miserable? “Just use my pinconfig, it is 100% working on a not even similar hw, but it will surely help you!” ?
I better like the idea of fixing the hda driver instead of going all way linux with this, where you compile your kernel to get sound working and other terrible user-hating solutions.
There have been several improvements and fixes to the media kit recently. It’s possible that it works better now (on my machine it started working).
If we knew what was wrong, we would not add a checkbox to the settings labelled “make it work”. We would just, you know, make it work.
If you want to try to fix the problems, you have to dig in the sourcecode and find what the problems are. And we already provide all you need to do that: a compiler and a text editor.
3 Likes
what’s probably needed, is that there is a config file crrated for each vendor, because, hda doesn’t really follow standard’s, and a way to add mapping etc per board.
I’m sure hardware vendors are supplying Microsoft something like this
1 Like
You mean those 120+ Mb drivers, right?
I doubt that it would take 15 mb to do them all, but that’s some of it
Would it be acceptable to try to pull in bits from FreeBSD in regards to the logging, pin layouts, and IDs?
I take it we have to read this information from the syslog instead of a program to output this data?
And besides the compiler (Linux way) to give users a comfortable graphical configuration tool similar to screen settings?
Look at my ticket 15158, everything is there, and if I could try out different options, I might have suggested a solution to my problem.
Yes right now you have to read the syslog. It would be possible to add code to the driver to have an ioctl to send the current pin setup so a program could output it, but someone would need to add that. It would probably make debugging this easier though. Next time I get a chance to work on this stuff I will see if I can add that.
2 Likes