The Linux Kernel Is Ready To Support A Lot More Sound Hardware

[Kivarnis]

Hm, I recently helped to fix an issue with another realtek device, I think it was an ALC668 from a laptop. Do you know what issues there still are specifically? The program I made to capture the commands of Windows drivers within a VM might be useful in fixing the issues with the ALC1220 if it works fine in Windows.

It has a issue with some implementation of the dual codec setup that it can have. Where there are "separate" devices for front and rear and the for lack of better wording mux together into one device on a logical level in Windows. Linux see's them both independantly which IMO is wrong behavior from the intent in the first place but more importantly sometimes Linux combines them together, so you end up with no sound because both line out's are merged and mapped in conflict. Best explanation I can give based on my loose observations. Worth noting it works on some distro's not others. Works on Manjaro for example (I have the ALC1220 dual codec setup myself) But IIRC -NOT- Solus.

[Conmanx360]

It has a issue with some implementation of the dual codec setup that it can have. Where there are "separate" devices for front and rear and the for lack of better wording mux together into one device on a logical level in Windows. Linux see's them both independantly which IMO is wrong behavior from the intent in the first place but more importantly sometimes Linux combines them together, so you end up with no sound because both line out's are merged and mapped in conflict. Best explanation I can give based on my loose observations. Worth noting it works on some distro's not others. Works on Manjaro for example (I have the ALC1220 dual codec setup myself) But IIRC -NOT- Solus.

Hmm, it working on some distros but not others is weird. It may have been fixed in a newer kernel version? For what it's worth, the ZxR had a similar issue before I added support. It has a daughter card that shares the same HDA 'bus' and since they're both treated as regular ca0132's, they'd generate conflicting controls and PCM's.

Interesting stuff. I'll look more into it.

[Aeder]

Hm, I recently helped to fix an issue with another realtek device, I think it was an ALC668 from a laptop. Do you know what issues there still are specifically? The program I made to capture the commands of Windows drivers within a VM might be useful in fixing the issues with the ALC1220 if it works fine in Windows.

This one for example: https://bugzilla.kernel.org/show_bug.cgi?id=195303 It has no workarounds.

Also it still has that bug that affected other Realtek devices where certain specific applications (the most reliable example being Flatpak'd Discord) will trigger popping and crackling on audio playback once you start them, or once they call speech-dispatcher's functions. The only work around for this second bug is to specify PULSE_LATENCY_MSEC to a number between 30 and 90 when starting the program.

[Kivarnis]

Hmm, it working on some distros but not others is weird. It may have been fixed in a newer kernel version? For what it's worth, the ZxR had a similar issue before I added support. It has a daughter card that shares the same HDA 'bus' and since they're both treated as regular ca0132's, they'd generate conflicting controls and PCM's.

Interesting stuff. I'll look more into it.

Same kernel version.

[Melcar]

It has a issue with some implementation of the dual codec setup that it can have. Where there are "separate" devices for front and rear and the for lack of better wording mux together into one device on a logical level in Windows. Linux see's them both independantly which IMO is wrong behavior from the intent in the first place but more importantly sometimes Linux combines them together, so you end up with no sound because both line out's are merged and mapped in conflict. Best explanation I can give based on my loose observations. Worth noting it works on some distro's not others. Works on Manjaro for example (I have the ALC1220 dual codec setup myself) But IIRC -NOT- Solus.

I have a Gaming K7 (AM4) with those dual codecs. Running Kubuntu with PA. Both codecs are detected, but PA does not load the one corresponding to the front panel. Manually loading the module gives you access to both codecs, but as separate sound cards.

[Kivarnis]

I have a Gaming K7 (AM4) with those dual codecs. Running Kubuntu with PA. Both codecs are detected, but PA does not load the one corresponding to the front panel. Manually loading the module gives you access to both codecs, but as separate sound cards.

Was not the case in what I was referencing. My mobo is a Gaming 7 WiFi (AM4).

[Conmanx360]

Seems like a weird issue, that it's effecting certain distros differently even with the same kernel, and then behaving differently depending on it's implementation. In the little searching I've done, I've found people talking about using different coef verbs to set it up properly. That's what was found when I helped out with the ALC668 codec. If they share one bus, getting a dump in a virtual machine may help figure some stuff out and help to get better support.

[Kivarnis]

Seems like a weird issue, that it's effecting certain distros differently even with the same kernel, and then behaving differently depending on it's implementation. In the little searching I've done, I've found people talking about using different coef verbs to set it up properly. That's what was found when I helped out with the ALC668 codec. If they share one bus, getting a dump in a virtual machine may help figure some stuff out and help to get better support.

You're a fucking hero dude, sound device support is so lacking in Linux land (TBH Linux has a ways to go before it has a real shot at going mainstream, but stuff like this really helps a ton and I yern for it.) I highly appreciate your hard work man, you're a dang saint. Is there a way to contribute to you monetarily for your hard work or is that against what you're about?

[Conmanx360]

You're a fucking hero dude, sound device support is so lacking in Linux land (TBH Linux has a ways to go before it has a real shot at going mainstream, but stuff like this really helps a ton and I yern for it.) I highly appreciate your hard work man, you're a dang saint. Is there a way to contribute to you monetarily for your hard work or is that against what you're about?

Thanks. The sound card was the only thing keeping from moving to Linux back when I first tried a few years ago, and I figured getting it working was a good challenge. Once I had just the Z working, I kind of figured I might as well help get the other ones working. The hope is the more people that use Linux, hopefully that means more things get fixed by new users. Might be a bit optimistic, but I hope it's true.

I'm not against donations, it helps me buy hardware to test on. It's hard to diagnose issues when I don't actually have it on hand, which is why I bought the ZxR and AE-5 myself. I'm not sure if it's allowed to put my donation link here directly, but it's in the Reddit post I've made for the cards, which I'll link.

I've said it before, but I think a lot of issues could be solved by using the program I've made to capture the HDA verbs between a virtual machine. Once the verbs are known, it's really only a matter of putting them into the driver for the most part. Seems like it would have been done before, but there must not have been enough audio issues to really care to do it. The ca0132 is probably the most complex HDA driver supported, as far as I can tell. If anyone is interested in trying it out with the ALC1150, I wouldn't mind parsing through the dump to see if anything weird is going on.