Once the Windows Audio Driver is installed, the BIOS setting should have no effect. The obvious question then is, “why isn’t this setting on by default?”. That is a question we’re discussing internally and we may update this in future BIOS’s.
Thanks for the update, this is exactly what I was hoping for!
My speculation then is that it’s basically just fiddling with non-public hardware registers that the Windows driver knows about, but are “trade secrets” possibly covered under NDA.
Another possibility of course is that they are publicly documented, but since the “right” values are platform-specific, the Linux driver isn’t interested in having a huge list of platform-specific settings in it.
3 Likes
Hi. Can anyone tell us exactly what the BIOS setting does and why? What registers it touches etc. I could then add it to the Linux kernel source code to work irrespective of what the BIOS setting does.
The setting changes the HDA VERB table between Linux and Windows.
Hardware wise we have a HDA codec with a class D amp that drives the high frequency speakers, and also an attached i2s amplifier for the main speakers.
The Linux version will configure EQ settings for both amplifiers correctly for Linux. Which is normally done by the Windows driver.
We would enable the linux settings as default for both, but the additional configuration will lead to a device failure in windows with the windows HDA driver.
10 Likes
What about in cases of dualbooting?
1 Like
@Niko_Cantero
From Kieran’s description, all the Linux setting in the BIOS does is make the speakers sound a bit better if you select the “Linux audio” setting. Once I get my FW16, I will make changes to the Linux Kernel so that whatever is done by the “Linux audio” BIOS setting, is then done by the Linux kernel instead. At that point, it will not matter which setting the FW16 bios is set to, it will sound best either way. But, time wise, this is maybe 6 months before I will get round to doing the changes in the Linux kernel because I don’t have a FW16 yet, but its on order.
2 Likes
You mean upstream those changes to the kernel, right? (I wonder why Framework doesn’t do that themselves tho tbh)
Cause the fw devs are absolutely overloaded with keeping their own stuff running. Just see all the BIOS complaints and feature requests
3 Likes
Hi,
Yes, I mean get the change into the mainline Linux kernel, that all the distros then use eventually. Its quite difficult to do the first time for any developer or organisation because the knowledge and quality barrier is quite high, but after you have done a few commits, you have then gained some trust and demonstrated your knowledge. It is a lot easier after that.
Even with the Linux comparability turned on in the BIOS, there is a huge difference in sound in Windows vs Linux. I noticed Windows is louder, and sounds a bit more rounded than in Linux. The profile I used for Easy Effects in Linux actually sounds even quieter but sounds fuller and more “correct” than without AND compared to Windows as well.
So I think Window’s driver still needs some tuning for sure.
This inconsistent audio performance is not giving me a whole lot of confidence with my FW16.
Add to that the request for numerous photos and videos for support to troubleshoot light bleed on my display due to the bezel pushing on it makes me feel regret on purchasing the FW16 at this time. Maybe it would get better.
I’m pretty overwhelmed with other life things right now so I really don’t want to spend the time to troubleshoot. Life was a lot different for me when the FW16 was accepting preorders.
Add to that the request for numerous photos and videos for support to troubleshoot light bleed on my display due to the bezel pushing on it makes me feel regret on purchasing the FW16 at this time. Maybe it would get better.
Did you have a look at this thread? The magnetic bezel puts slight pressure on the screen
You may be two pieces of thin cardboard away from working around that issue.
I tried this but it didn’t help 
Please open a support ticket for assistance with this. Thanks
1 Like
What for? Isn’t this more of a driver-level or firmware-level issue?
I did not see anybody reply with the answer to this request (try lspci -vnn) so I decided to try it.
1867 sudo lspci -vnn > linux_version.txt
1960 history | fgrep lspci
Shutdown, startup, interrupt the boot process by pressing F2, changing the state of the Linux Audio Compatibility setting to windows, save, continue the boot process.
1965 sudo lspci -vnn > windows_version.txt
1997 history | fgrep lspci
jeffs@frmwk16:~$
jeffs@frmwk16:~$ sudo lspci -vnn > windows_version.txt
[sudo] password for jeffs:
pcilib: Error reading /sys/bus/pci/devices/0000:00:08.3/label: Operation not permitted
jeffs@frmwk16:~$ sdiff -s linux_version.txt windows_version.txt
Flags: bus master, fast devsel, latency 0, IRQ 116, I | Flags: bus master, fast devsel, latency 0, IRQ 114, I
Flags: bus master, fast devsel, latency 0, IRQ 89, IO | Flags: bus master, fast devsel, latency 0, IRQ 87, IO
Flags: bus master, fast devsel, latency 0, IRQ 81, IO | Flags: bus master, fast devsel, latency 0, IRQ 82, IO
Flags: bus master, fast devsel, latency 0, IRQ 114, I | Flags: bus master, fast devsel, latency 0, IRQ 115, I
Flags: bus master, fast devsel, latency 0, IRQ 82, IO | Flags: bus mastemanr, fast devsel, latency 0, IRQ 84, IO
Flags: bus master, fast devsel, latency 0, IRQ 115, I | Flags: bus master, fast devsel, latency 0, IRQ 116, I
Flags: bus master, fast devsel, latency 0, IRQ 84, IO | Flags: bus master, fast devsel, latency 0, IRQ 86, IO
Flags: bus master, fast devsel, latency 0, IRQ 88, IO | Flags: bus master, fast devsel, latency 0, IRQ 90, IO
jeffs@frmwk16:~$
jeffs@frmwk16:~$ diff -y -l --width=200 linux_version.txt windows_version.txt | fgrep -A 1 -B 1 \|
Subsystem: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter [14c3:e61 Subsystem: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter [14c3:e61
Flags: bus master, fast devsel, latency 0, IRQ 116, IOMMU group 12 | Flags: bus master, fast devsel, latency 0, IRQ 114, IOMMU group 12
Memory at 8010900000 (64-bit, prefetchable) [size=1M] Memory at 8010900000 (64-bit, prefetchable) [size=1M]
--
Subsystem: Sandisk Corp WD Black SN770 / PC SN740 256GB / PC SN560 (DRAM-less) NVMe SSD Subsystem: Sandisk Corp WD Black SN770 / PC SN740 256GB / PC SN560 (DRAM-less) NVMe SSD
Flags: bus master, fast devsel, latency 0, IRQ 89, IOMMU group 13 | Flags: bus master, fast devsel, latency 0, IRQ 87, IOMMU group 13
Memory at 90a00000 (64-bit, non-prefetchable) [size=16K] Memory at 90a00000 (64-bit, non-prefetchable) [size=16K]
--
Subsystem: Framework Computer Inc. Phoenix [f111:0005] Subsystem: Framework Computer Inc. Phoenix [f111:0005]
Flags: bus master, fast devsel, latency 0, IRQ 81, IOMMU group 14 | Flags: bus master, fast devsel, latency 0, IRQ 82, IOMMU group 14
Memory at 8000000000 (64-bit, prefetchable) [size=256M] Memory at 8000000000 (64-bit, prefetchable) [size=256M]
--
Subsystem: Framework Computer Inc. Rembrandt Radeon High Definition Audio Controller [f1 Subsystem: Framework Computer Inc. Rembrandt Radeon High Definition Audio Controller [f1
Flags: bus master, fast devsel, latency 0, IRQ 114, IOMMU group 15 | Flags: bus master, fast devsel, latency 0, IRQ 115, IOMMU group 15
Memory at 905c8000 (32-bit, non-prefetchable) [size=16K] Memory at 905c8000 (32-bit, non-prefetchable) [size=16K]
--
Subsystem: Framework Computer Inc. Device [f111:0005] Subsystem: Framework Computer Inc. Device [f111:0005]
Flags: bus master, fast devsel, latency 0, IRQ 82, IOMMU group 18 | Flags: bus master, fast devsel, latency 0, IRQ 84, IOMMU group 18
Memory at 90300000 (64-bit, non-prefetchable) [size=1M] Memory at 90300000 (64-bit, non-prefetchable) [size=1M]
--
Subsystem: Framework Computer Inc. Family 17h/19h HD Audio Controller [f111:0005] Subsystem: Framework Computer Inc. Family 17h/19h HD Audio Controller [f111:0005]
Flags: bus master, fast devsel, latency 0, IRQ 115, IOMMU group 20 | Flags: bus master, fast devsel, latency 0, IRQ 116, IOMMU group 20
Memory at 905c0000 (32-bit, non-prefetchable) [size=32K] Memory at 905c0000 (32-bit, non-prefetchable) [size=32K]
--
Subsystem: Framework Computer Inc. Device [f111:0005] Subsystem: Framework Computer Inc. Device [f111:0005]
Flags: bus master, fast devsel, latency 0, IRQ 84, IOMMU group 24 | Flags: bus master, fast devsel, latency 0, IRQ 86, IOMMU group 24
Memory at 90600000 (64-bit, non-prefetchable) [size=1M] Memory at 90600000 (64-bit, non-prefetchable) [size=1M]
--
Subsystem: Framework Computer Inc. Device [f111:0005] Subsystem: Framework Computer Inc. Device [f111:0005]
Flags: bus master, fast devsel, latency 0, IRQ 88, IOMMU group 25 | Flags: bus master, fast devsel, latency 0, IRQ 90, IOMMU group 25
Memory at 90700000 (64-bit, non-prefetchable) [size=1M] Memory at 90700000 (64-bit, non-prefetchable) [size=1M]
jeffs@frmwk16:~$ diff -y -l --width=200 linux_version.txt windows_version.txt | fgrep -A 1 -B 1 \| | wc -l
31
jeffs@frmwk16:~$ diff -y -l --width=200 linux_version.txt windows_version.txt | fgrep -A 1 -B 1 \| > comparison_linux_first_windows_second.txt
jeffs@frmwk16:~$
Next, I reset the sound linux compatibility mode to Linux, ran lspci -vnn and got:
1998 sudo lspci -vnn > second_linux_version.txt
2003 history | fgrep lspci
jeffs@frmwk16:~$ diff -y -l --width=200 linux_version.txt second_linux_version.txt | fgrep -A 1 -B 1 \|
Subsystem: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter [14c3:e61 Subsystem: MEDIATEK Corp. MT7922 802.11ax PCI Express Wireless Network Adapter [14c3:e61
Flags: bus master, fast devsel, latency 0, IRQ 116, IOMMU group 12 | Flags: bus master, fast devsel, latency 0, IRQ 114, IOMMU group 12
Memory at 8010900000 (64-bit, prefetchable) [size=1M] Memory at 8010900000 (64-bit, prefetchable) [size=1M]
--
Subsystem: Sandisk Corp WD Black SN770 / PC SN740 256GB / PC SN560 (DRAM-less) NVMe SSD Subsystem: Sandisk Corp WD Black SN770 / PC SN740 256GB / PC SN560 (DRAM-less) NVMe SSD
Flags: bus master, fast devsel, latency 0, IRQ 89, IOMMU group 13 | Flags: bus master, fast devsel, latency 0, IRQ 87, IOMMU group 13
Memory at 90a00000 (64-bit, non-prefetchable) [size=16K] Memory at 90a00000 (64-bit, non-prefetchable) [size=16K]
--
Subsystem: Framework Computer Inc. Rembrandt Radeon High Definition Audio Controller [f1 Subsystem: Framework Computer Inc. Rembrandt Radeon High Definition Audio Controller [f1
Flags: bus master, fast devsel, latency 0, IRQ 114, IOMMU group 15 | Flags: bus master, fast devsel, latency 0, IRQ 115, IOMMU group 15
Memory at 905c8000 (32-bit, non-prefetchable) [size=16K] Memory at 905c8000 (32-bit, non-prefetchable) [size=16K]
--
Subsystem: Framework Computer Inc. ACP/ACP3X/ACP6x Audio Coprocessor [f111:0005] Subsystem: Framework Computer Inc. ACP/ACP3X/ACP6x Audio Coprocessor [f111:0005]
Flags: bus master, fast devsel, latency 0, IRQ 113, IOMMU group 19 | Flags: bus master, fast devsel, latency 0, IRQ 111, IOMMU group 19
Memory at 90580000 (32-bit, non-prefetchable) [size=256K] Memory at 90580000 (32-bit, non-prefetchable) [size=256K]
--
Subsystem: Framework Computer Inc. Family 17h/19h HD Audio Controller [f111:0005] Subsystem: Framework Computer Inc. Family 17h/19h HD Audio Controller [f111:0005]
Flags: bus master, fast devsel, latency 0, IRQ 115, IOMMU group 20 | Flags: bus master, fast devsel, latency 0, IRQ 116, IOMMU group 20
Memory at 905c0000 (32-bit, non-prefetchable) [size=32K] Memory at 905c0000 (32-bit, non-prefetchable) [size=32K]
--
Subsystem: Framework Computer Inc. Device [f111:0005] Subsystem: Framework Computer Inc. Device [f111:0005]
Flags: bus master, fast devsel, latency 0, IRQ 88, IOMMU group 25 | Flags: bus master, fast devsel, latency 0, IRQ 90, IOMMU group 25
Memory at 90700000 (64-bit, non-prefetchable) [size=1M] Memory at 90700000 (64-bit, non-prefetchable) [size=1M]
jeffs@frmwk16:~$
Interestingly enough, I was having sound problems before I went through process, but having gone through this process, that has fixed the sound problem. For me.
I have been working fixing computers for decades. The second most frustrating problem that I do lnot know how to fix. The most frustrating problems are those that I fix for reasons I do not understand. This problem falls into that category.
1 Like
Sorry, I’m a bit Linux ignorant. What does that do?
Techue Zeddie,
I am not sure I can explain it to you. It has to do with Linux operating system internals and BIOS internals. In all likelihood, you do not need to understand it unless you are doing some serious low-level troubleshooting. But I do not want to be dismissive, either. That’s kinda rude. So if my explanation does not make sense, then please ask me.
Full disclosure: I am not sure I understand what the sound card mode option in the BIOS actually does. I get it that you set it to linux mode if you are running linux and windows mode if you are running windows, but if you are dual booting, then what do you set it to so it will work in both operating systems. Furthermore, Linux generally has a “Okay, I’ve gotta do it the way Redmond says to do it” attitude in contrast to Microsoft’s “Fuck you and stop ruining my profit margins” attitude, so I would expect that linux would flip the mode the way it wants or else work around it.
The sound card connects to the rest of the computer using a bus called PCI, the Personal Computer Interconnect. The lspci command tells you what’s on the PCI bus. In this case, I took a look at the PCI bus before I made any changes, then shutdown the computer, changed the bit in the BIOS, then rebooted, then took a look at the PCI bus. Then, I rebooted, changed the setting back and looked at the PCI bus again.
I do not understand why changing the setting and then restoring the setting to the original value (which I think is the correct value) fixed the issue, but it did.
At that point, I have to defer to the judgement and wisdom of people who actually develop operating system software.
I meant what did the commands do?
From my relative inexperience, it looks like you switched one mode to another while listing the contents of the PCI bus to text files then compared the differences?
I guess what I didn’t understand is the -vnn for lspci. What does that do? And what was the difference you saw?
I’m having a hard time interpreting the output.
Does changing the modes make the sound chipset identify itself differently?