The Dell XPS 9510 includes four speakers, two of them acting as subwoofers. In my machine, the subwoofers seem to be detected, however, they are not playing any audio. This is bugging me quite a bit, since a patch included in the kernel a few months ago seemed to fix the issue for some users (this one: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.15.6&id=da94692001ea45ffa1f5e9f17ecdef7aecd90c27). I tested the audio output by playing different frequencies with `aplay`, and found out that all frequencies below ~150Hz are capped. I then confirmed that this was not a hardware issue by going into Windows and testing the same frequencies, from where I concluded that probably more changes are needed in the device driver to enable the use of the subwoofers. I believe the subwoofers are detected because the sound settings are showing as an option a surround 4.0 format for the internal speakers, and `alsamixer` also shows a `Bass speaker` control, although this one shows only a mute/unmute button only, without a volume bar. I reached a point where I didn't know what else to do, so I decided to ask for help here. Please let me know about any information I can provide that could help. I am more than happy to test and keep debugging this issue, I might only need a bit of guidance, since I have 0 experience with driver software development. Please let me know if you think this bug belongs somewhere else, I ended up here, but I'm not sure whether this is the right channel for reporting it either. -------------- Alsa-info output: http://alsa-project.org/db/?f=238c157b7abce92fe7d2c0086bcf156286b75397
Last night, watching a movie while running Windows, I noticed something: The subwoofers stopped when Windows noticed that there was only 10% battery left, then they went back on as soon as I connected the computer to the power. This made me think that maybe there is a power-saving option on the driver that I can use to turn on the subwoofers. I'll be looking for documentation on this and see if anything changes when I change the power settings on the machine. If anyone has any idea about whether this kind of feature for power saving exists, or how to manage it, please let me know :)
Created attachment 300171 [details] alsa-info Attaching a new alsa-info report, now with kernel version 5.15.7 and firmware version 1.6.2. Please let me know if there is anything I could try to test here. I'm learning more about how audio works, but I feel a bit lost when it comes to narrowing down and identifying the problem here. In any case, I'll keep updating the issue as I learn more about it.
Created attachment 300286 [details] alsa-info for xps 9510 running kernel 5.16 I have the same problem. Made several tests disabling all sound daemons (pulseaudio, in particular) and using speaker-test -t sine -f80 -c 2 and similar. No sound up to around 110hz Attached my alsa-info obtained running kernel 5.16 and with all daemons disabled.
I've been trying to improve the sound on the 9510, for a while I thought the main speakers were not working, but after some testing the 4 speakers do seem to be working, though perhaps not quite as they are supposed to. For example, in hdajackretask, I assigned the 0x17 pin to "Not Connected" (which I think reverses the kernel fix). After that I was only getting a very thin sounding audio from the tweeters. Is it possible there is some crossover setting somewhere which is rolling off the lower frequencies? Or maybe the bass speakers need the volume boosted somehow (since not only is the sound fuller in Windows, but is also louder, even when all the maxxaudio stuff is disabled)
(In reply to David Turner from comment #4) > I've been trying to improve the sound on the 9510, for a while I thought the > main speakers were not working, but after some testing the 4 speakers do > seem to be working, though perhaps not quite as they are supposed to. For > example, in hdajackretask, I assigned the 0x17 pin to "Not Connected" (which > I think reverses the kernel fix). After that I was only getting a very thin > sounding audio from the tweeters. Is it possible there is some crossover > setting somewhere which is rolling off the lower frequencies? Or maybe the > bass speakers need the volume boosted somehow (since not only is the sound > fuller in Windows, but is also louder, even when all the maxxaudio stuff is > disabled) This was also my last suspicion, although I haven't been able to get myself together to debug further. I had a day when I could reproduce the issue on Windows: The laptop was running out of battery and all of a sudden I had the same audio as in Linux. I wanted to see if I could manage to sniff the verbs used in Windows and see if there is a fix there (other laptops have needed that to get all the needed configuration going), but I didn't manage to gather the time to do it yet. There is also an issue that is bugging me, and it is that the output profiles available after the kernel fix are surround 4.0 and stereo, but no surround 2.1, which I would guess is what we need. I am wondering if the driver is somehow cutting off the low frequencies or sending them on the wrong device, making the subwoofers play only the high frequencies. I tried to test this by setting the low-frequency thresholds to 0 (making all frequencies go to the speakers) but I still got the same results. Then, I also realised not long ago that a fix was potentially made for the Precision 5560, since it has been certified for Ubuntu and if I'm not wrong they have the same hardware as the XPS 9510 (excepting the graphics card). It would be interesting to get a hand on the ubuntu image they ship with and see if things work there. I hope we can figure this out! I'm happy to see that others are looking into the issue :) Thanks for sharing your results!
So, following some guides I managed to get a VM with windows running and to sniff some verbs. However, even though audio through the VM was flawless, applying different subsets of the provided verbs has not given any results in fixing the frequency issue yet.. The sound does not really change after applying the verbs, which makes me think that it might be a problem at a higher level... I'll keep playing with the verbs to see if I can get some better results, but I'm thinking that the issue might be elsewhere. I'm attaching the logs I got from the VM and cleaned up verbs sent to the audio card during the sniffing session. I followed the steps here https://github.com/ryanprescott/realtek-verb-tools/wiki/How-to-sniff-verbs-from-a-Windows-sound-driver to get the verbs. Let me know if anyone has any idea of where can I look next!
Created attachment 300423 [details] qemu-sniff-output.txt
Created attachment 300424 [details] AllVerbs.txt Please note that these are all verbs from the session, the last few verbs are actually shutting down the audio card, so if you apply all of them you won't hear anything. I'm attaching them all because I'm still not sure which are the ones that we can get rid of for sure.
For anyone else still wondering about this issue, seems like either Dell or Realtek included a high-pass filter at 250Hz for this device as a measure to protect the speakers. See the conversation at: https://github.com/thesofproject/linux/issues/3729 There seems to be no solution other than adjusting the filter. I guess it won't be easy to get the sound working properly on this one...
Hello Aitor, I am still wondering: how windows drivers are disabling the filter? And what makes us giving up to get it working in linux? I don't get why there are safety implications. Also last questions, I am running 6.2.0-20-generic and I wanted to confirm that actually the woofer speakers are receving sound, have you confirmed this? if yes, how?
The same problem on the kernel 6.1.0-12, tried everything I found, the speakers do not work
(In reply to simo from comment #10) > Hello Aitor, I am still wondering: > > how windows drivers are disabling the filter? And what makes us giving up to > get it working in linux? > I don't get why there are safety implications. > > Also last questions, I am running 6.2.0-20-generic and I wanted to confirm > that actually the woofer speakers are receving sound, have you confirmed > this? if yes, how? Hi Simo, Sorry it took so long to get back to you, it's been a few intense months and I kept delaying writing back. I gave up because I could not find any info/documentation/help anywhere about this problem. From what I can recall, I don't think I tried much after I reported the issue I mentioned in #9. In that conversation, it became clear that I would not get any help or orientation on how to fix it and I got a bit discouraged.. I can confirm that this issue is still happening. I just tested it on 6.5.5-200.fc38, and is still an issue. There is an easy way to test that all speakers are giving out some sound. If you revert the change made in this patch https://github.com/kristinpaget/xps-15-9510-audio (you can just disable the right pin using hdajackretask, so you don't need to rebuild the kernel I think, I just can't remember what pin it was that this patch activated). If you enable/disable this and play something you can hear the difference. The next test is going to any frequency test in youtube and play it. You will instantly notice that no matter what configuration you use, you will not be able to play any low frequencies. Those lower frequencies are somehow enabled on windows but looks like it's impossible to get them to work on linux. I might give it another go next week if I get the chance, but I honestly have little hope for this to ever be fixed, unless dell decides that they will start playing with the kernel and fixing older models of their laptops anyways..
Hello Aitor, Thanks for the info. I will do the test just to confirm that I am getting the best experience we can get at the moment! I can also confirm you that when in windows it's going out of charge, it indeed switch the audio cutting off low frequencies. As you reported. Keep us posted, I will do the same here.
I can confirm Dells current line of xps 15 9530 (2023) seems to use the same audio device, resulting in the same issue (6.5.5-arch1-1) Device: 00:1f.3 Class: Multimedia audio controller [0401] Vendor: Intel Corporation [8086] Device: Raptor Lake-P/U/H cAVS [51ca] SVendor: Dell [1028] SDevice: Device [0beb] Rev: 01 ProgIf: 00 IOMMUGroup: 17
this should be good news for here as well, non? https://github.com/thesofproject/linux/issues/4624
Do not think so as the guys are working on enabling the Cirrus amplifier and for 9530. And on XPS 9530 there is a boot-time error message pointing to the amp. There is no such a message in dmesg for 9510 meaning either a different amplifier is installed on 9510 and/or that the amplifier is not even recognized at all as a device.
Hello Vlad, I see that you followed better the issue with the 9530. Do you believe that we can get anything out of testing/capturing any action done by the windows drivers? Expecially because we can have windows going in that "lack of bass" situation just by having the 9510 running on low battery. And if I correctly remember, just by plugging the charger the audio would come back with great bass. I am assuming that this behavior is actually controlled at os/driver level. I am not fully sure if it is the bios turning these two audio setup.
Hi Simo, >Expecially because we can have windows going in that "lack of bass" situation >just by having the 9510 running on low battery. And if I correctly remember, >just by plugging the charger the audio would come back with great bass. Most likely it means that 9510 is also have an amplifier for bass speakers installed and Windows shuts down the amplifier in low power mode. It is good news at it means a similar to 9530 patch can be implemented. The problem is that 9530 has this in logs Serial bus multi instantiate pseudo device driver CSC3551:00: Instantiated 2 SPI devices. [ 3.745957] cs35l41-hda spi1-CSC3551:00-cs35l41-hda.0: Error: ACPI _DSD Properties are missing for HID CSC3551. So 9530 guys knew from the beginning what was the device (bass speakers amplifier) and the device was reported to OS by BIOS. Then they added missing configiration and uploaded firmware. For 9510 we are missing the first step: the amplifier is not reported in the boot log and there is no PCI device in ACPI tables to start with. I am going to try out the 9530 patch when it goes upstream. Hopefully it helps.
Hey guys, Have you heard any news about this for 9510? I see it's fixed on 9530 (https://github.com/thesofproject/linux/issues/4624), but older dell laptops (9500, 9510,9520) this is still an issue. I have tested Fedora with Kernel 6.9 and it didn't work, no woofers unfortunately. Thanks. Alex.
Hey Alex, no, nothing. Older models have a different sound hardware (a different amplifier or possibly no amplifier at all) so the patch from 9530 does not help
I'm wondering why it is still broken because someone was able to create a patch for Kernel 5.13.9 back in 2021 (https://github.com/kristinpaget/xps-15-9510-audio). Have any of you tried this patch? Is it possible to compile it against newer Kernel version?
Created attachment 306516 [details] attachment-30752-0.html The patch has been included into kernels for long but the it simply does not work. The change enables pin 0x13 of the audio codec and it is not enough to activate subwoofers. Most likely the on chip or external amplifier connected to subwoofers should also be powered up and firmware for the amp should be uploaded as it was done for 9530. For 9510 the problem is that we do not know what the amplifier is. If you need more info please read the discussion thread for 9530. On Sun, Jun 30, 2024, 8:08âŻa.m. <bugzilla-daemon@kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=215233 > > --- Comment #21 from Alex (alexveri@gmail.com) --- > I'm wondering why it is still broken because someone was able to create a > patch > for Kernel 5.13.9 back in 2021 > (https://github.com/kristinpaget/xps-15-9510-audio). Have any of you > tried this > patch? Is it possible to compile it against newer Kernel version? > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You are on the CC list for the bug.