Unsolved
1 Rookie
•
6 Posts
0
14
August 9th, 2025 07:21
AW3225QF, eARC audio issues, Investigation
Just spent 5 hours or so of frustration to do Dell's engineering work for them. I hope my emails reach the engineering team, but I'm posting here for visibility.
I recently bought an Alienware AW3223QF QD-OLED monitor and it's a huge visual step up from my old Dell G3223Q IPS monitor, but that one had a 3.5mm jack and the Alienware has HDMI eARC. No problem, right? I just got a $20 eARC extractor/DAC and it should keep my speakers working great. Well, no. The monitor doesn't show up as an audio device on any PC I tried.
However, I plugged in a PS4 and a Nintendo Switch to the HDMI input and eARC audio worked fine, so the AW3223QF is doing *something* right? I tried Linux, I tried Windows, I tried an NVIDIA RTX 3080, an AMD Radeon 7800XT, and the Intel iGPU in my i7 14700K. Nothing detected the audio.
I called Dell tech support and spent an hour and a half on a call, let the guy remote into my PC, tried a handful of different HDMI cables. He said "it works on the PS4, so the monitor is fine".
I said no, obviously something is up with the AW3223QF otherwise the PC would see it as an audio device. My old G3223Q did, my Samsung TV did, it has to be this monitor. I updated the AW3223QF firmware. For an $850 monitor I expect it to work.
He eventually relented and contacted his "engineering contact" but basically they just said the same thing. Console works, thus AW3223QF fine. We eventually ended the call with no resolution, but the tech said he'd report it to engineering.
After getting off the call, I remembered EDID dumping and edidreader, so I dumped the HDMI EDIDs from my Samsung TV (audio works, including the eARC extractor) and from my AW3223QF. Compared them with edidreader. The Samsung TV EDID had an Audio Data Block describing supported formats and speaker configurations, but the AW3223QF EDID did not. After some unsuccessful fiddling trying to patch the ADB into the AW3223QF EDID, I tried an easier hack. I just forced the RTX 3080's HDMI port to use the dumped Samsung TV EDID with a kernel command line, rebooted the PC with the AW3223QF plugged into the HDMI port. Lo and behold, audio through eARC works fine if the PC thinks it's a Samsung TV. I then tried dumping the DisplayPort EDID from my G3223Q (as the Samsung TV did not do DisplayPort) and using that EDID override on the RTX 3080's DisplayPort. Plugged the AW3223QF in, and audio still works fine if it thinks its a G3223Q.
So yeah, it seems the issue does lie in the AW3223QF, specifically it's missing information in its EDID. Dell, if you're reading this, please add an Audio Data Block to the AW3223QF EDID based on the capabilities of the detected eARC device (basically what audio formats it supports) and maybe have an option to force enable audio passthrough for at least basic stereo modes because it seems whatever it currently does is lacking.
DELL-Chris M
Community Manager
•
56.9K Posts
0
August 9th, 2025 10:47
Good troubleshooting. I will also send your thread up the chain. Adding clarification notes for others about the video in ports as shown in the AW3225QF User's Guide.
* You should be testing using only the provided HDMI 2.1 FRL cable that shipped with the AW3225QF
* Menu--> Others--> HDMI CEC must be On
* #7 HDMI 1 port supports eARC/ARC (See page 24 for pins)
- #7 HDMI 1 port pin 14 = eARC TX
- #7 HDMI 1 port pin 19 = eARC TX hot plug detect
* #8 HDMI 2 port does not support eARC/ARC (See page 25 for pins)
(edited)
Element115s4
2 Intern
•
286 Posts
0
August 9th, 2025 12:35
Sad the user had to do so much work that Dell engineers should have been doing but I'm not really shocked.
HDMI...this should be the PC audio connection standard by now, after all its 2025!
I now run eARC from my RTX5070, disable the useless onboard Realtek and never look back.
I would think with an Alienware, you can disable that garbage onboard sound in the BIOS which is more than I can say for my XPS 8950.
CalcProgrammer1
1 Rookie
•
6 Posts
0
August 9th, 2025 22:56
I think I figured out how to patch in the necessary data blocks for audio, but I'm not at home today so I will test tomorrow night. I took the ADB (Audio Data Block) and SAB (Speaker Allocation Block), a total of 8 bytes of data, from my G3223Q's EDID and pasted them directly after the VDB (Video Data Block) in the AW3225QF's EDID (which is the same position they were in the G3223Q's EDID). I then also set the Basic Audio bit in the CEA-861 header, updated the DTD offset in the CEA-861 header (added 8 bytes to account for the ADB+SAB), and updated the checksum at the end of the CEA-861 block. I deleted 8 zero bytes at the end of this block (each block is 128 bytes) before the checksum (the last byte in each block) so that the data after the CEA-861 block remained in the same position as before.
After these edits, the updated audio-added EDID parses correctly in wxEDID with no errors:
Here is the binary comparison, the large diff section is due to the bytes after the ADB+SAB shifting. The first 8 bytes of the large diff section are the new bytes, the rest is the old data shifted, and then 8 padding zeros were removed.
Note that this is untested, but I will post an update tomorrow when I get a chance to test it.
Edit: In the diff, the file I started with already had the Basic Audio bit patched in, so it's not the actual original straight from the monitor. I will update this with a new diff.
(edited)
CalcProgrammer1
1 Rookie
•
6 Posts
0
August 9th, 2025 23:03
Can't edit my previous post again so here is the actual diff between the unmodified EDID and the completely modified one: