It does not work out of the box, so I tried installing OSS and to follow the instructions on Open Sound System for Haiku . I suspect these instructions are a bit outdated, so I tried to changed the path to ../hmulti/* in the blacklist, but it did not work either. OSS for Beos supports the card with oss_ali5455, but I think oss_ich would work as well.
On boot usb_audio is loaded, I do not know if this means that the systems thinks I have an usb audio card attached or if it just makes it possible to attach such a card. oss_loader is also loaded, but no oss-drivers. In fact I can not find any oss-drivers installed, only settings for them. OSS does not find any devices (ossinfo). ossplay complains about /dev/dsp missing, and it is missing.
It is possible that the system misidentifies the card for Sis7018.
I think the main problem is that I try to do things the wrong way, so I would very much appreciate any hints about how to attack the problem.
Did you try without modifying the path first? As far as I know drivers are still in this folder.
To avoid conflicts, you may need to add a line to also blacklist usb_audio.
On Haiku, a driver always loads once at startup, if he finds a device it register with it, if not it quits and unload himself.
That usb_audio driver is looking for sound chips on USB but it doesn’t have to be a sound card. It might be a headset or any device with a sound chip as well. So, if unsure, unplug such device.
You’ll want to post a new bug ticket for Haiku AC97 audio driver. Provide the syslog file for the ticket
and PCI ID (i.e. 0x10b9, 0x5455) info for your audio device. Give them the detailed info on your desktop/laptop hardware as well. You can use the commands ‘listdev’ and ‘listusb’ for more info.
I did try without modifying the path first, yes. I got the other path from syslog, I think the efect was the same. I only have a mouse connected to the USB, that could be a problem with this very computer, I had Void Linux on it before and with the later kernels I would get a kernel panic with the mouse connected. It seems that the kernel identifies the sound card as a Sis7018, but listdev as M5455.
I can blacklist a module in the package-file, is there not a way to instruct Haiku to load a module?
Yes, the kernel identifies the soundcard as Sis7018 and loads usb_audio. Blacklisting usb_audio results in no driver loaded. Disconnecting the mouse has no effect, and OSS cannot find the device, so I removed it.
The kernel identify devices by chips if I know well, it scans the all buses, and those scan presumable conditioned to detect on low level access - below what OS command use. Someone may correct me.
The command listdev presumably uses the PCI standard as the device reports back from itself what defined in PCI standards, as listdev generally reports back mostly what connected via PCI, so listdev like lspci on GNU/Linux.
I do not know what about i2c or FD attached devices which are more common on other architectures than x86, x86_64 .. I do not own any of it. I just saw patches and forum posts it developed in last years, due to manufacturing trend changes in modern machines, and ARM / RISC-V differencies.
I may also wrong about it what is in the deep, but I wanted to pinpoint that a device can be detected by OS kernel and reported back itself differently if you use a command.
In case driver perspective the chip is enough to know as it will work with a generic driver for that chip, at least you cannot use some feature that additionally exists for that audio ‘card’.
However it is an AC’97 chip, means it covers AC’97 codec standard, so this way possibly integrated to the motherboard and has standard input/output ports.
In a laptop possibly just duplex stereo in (line in jack + piezo mics) / out (sheadphone jack / built-in speakers), meanwhile in desktop may support 5.1 or 7.1 channel output and may have digital SPDIF also installed.
Unlike HDA, every AC97 card needs it’s own driver. There is no class driver for it, the ich_ac97 (I think it’s called that) driver is for Intel 8xx chipsets.