Node names from `85-asahi-policy.lua` do not match with eudev.

[mixi]

On my setup of my distribution (Exherbo Linux) node name for the audio device of my M1 16" MBP (j316) is alsa_output._sys_devices_platform_sound_sound_card0.HiFi__hw_AppleJ316_1__sink instead of alsa_output.platform-sound.HiFi__hw_AppleJ316_1__sink as specified in 85-asahi-policy.lua. As a result the filter chain does not get enabled, and the speakers sound wrong.

I have no clue which detail could have caused the name, but it should be fixable by adding a match for that scheme of node names as well.

The only difference I can think of is that my setup uses eudev.

The output of pw-cli ls ist attached as pw_cli_ls.txt.

[mixi]

Some more information that could be helpful in figuring out why the devices are named the way they are:

• I use pipewire 1.0.0, patched only for an unrelated build fix.
• udevadm info -p /sys/devices/platform/sound/sound/card0 prints udev_info_card0_env.txt
• udevadm info -ap /sys/devices/platform/sound/sound/card0 prints udev_info_card0_attr.txt

[morrolinux]

Same here. On a fresh install of Asahi fedora remix, my 13" 2020 M1 pw-cli ls reports alsa_output.platform-sound.HiFi__hw_AppleJ313_0__sink but the rule matches only for alsa_output.platform-sound.HiFi__hw_AppleJ313_1__sink. Changing that and restarting wireplumber seems to improve the audio quality, but the volume is stuck at 100% and the left speaker is audibly distorted.

I'm attaching some possibly useful info as well.

pw-cli-ls.txt udev_info_card0_attr.txt udev_info_card0_env.txt

asahi-diagnose-20231220-220618.txt

Thaks!

[mixi]

That's definitely not the same symptom. Your device names follow the *.platform-sound.* scheme, where mine use *._sys_devices_platform_sound_sound_card0.*.

Also the volume being stuck at 100% sounds like pipewire tries to control the alsa HW volume controls, which was a symptom of it not working for me. This sounds to me like your modifications did disable the filter.

Your pw-cli ls also does seem to contain the node it matches on. The *_0__sink you changed it to seems to be the headphone jack instead:

...
    id 48, type PipeWire:Interface:Node/3
        object.serial = "268"
        object.path = "alsa:pcm:0:hw:AppleJ313,1:playback"
        factory.id = "18"
        client.id = "36"
        device.id = "44"
        priority.session = "728"
        priority.driver = "728"
        node.description = "Audio interno Speakers"
        node.name = "alsa_output.platform-sound.HiFi__hw_AppleJ313_1__sink"
        node.nick = "Speakers"
        media.class = "Audio/Sink"
...
    id 60, type PipeWire:Interface:Node/3
        object.serial = "269"
        object.path = "alsa:pcm:0:hw:AppleJ313,0:playback"
        factory.id = "18"
        client.id = "36"
        device.id = "44"
        priority.session = "1000"
        priority.driver = "1000"
        node.description = "Audio interno Headphones"
        node.name = "alsa_output.platform-sound.HiFi__hw_AppleJ313_0__sink"
        node.nick = "Headphones"
        media.class = "Audio/Sink"
...

Thanks for the data though, as it did give me an angle to investigate further. Your udev seems to set ID_PATH and ID_PATH_TAG, which I assume is where pipewire takes the name from.

[chadmed]

@morrolinux the 0 mux is for the headset jack. If both your speakers and the jack are on that same mux, something else is wrong with your setup. Please go to alsamixer and make sure Speaker Playback Mux is set to Secondary

[mixi]

Could you both please attach the output of asahi-diagnose?

Here is mine (the kernel log has a slightly different format, as I don't have journalctl, and had to change it to use a different source): asahi-diagnose-20231220-231719.txt

[mixi]

I found the culprit.

Systemd's udev is distributed with a rule 71-seat.rules, which, among other things, sets ID_PATH: https://github.com/systemd/systemd/blob/main/rules.d/71-seat.rules.in#L76

In eudev that rule is missing.

The basic sound card rule 78-sound.rules is similar in both, and skips platform device sound cards before it would have imported ID_PATH: https://github.com/eudev-project/eudev/blob/master/rules/78-sound-card.rules#L56 for the skip, https://github.com/eudev-project/eudev/blob/master/rules/78-sound-card.rules#L65 for the import.

I could reproduce with a simple rule that the issue is fixed when explicitly importing the path_id builtin:

$ cat /etc/udev/rules.d/99-sound-path.rules                                                                             
SUBSYSTEM=="sound", ACTION!="remove", IMPORT{builtin}="path_id"
$ udevadm control --reload
$ udevadm trigger --subsystem-match=sound --action=change
$ killall wireplumber
$ killall pipewire
$ pw-cli ls
...
                node.name = "alsa_output.platform-sound.HiFi__hw_AppleJ316_0__sink"
...

(Apparently the working pipewire rules hide the interface completely, the headphone output has to suffice as an example of the now proper names with .platform-sound.)

[chadmed]

eudev is abandonware and we can't support it. all distros should have moved to udev proper by now.

[morrolinux]

@morrolinux the 0 mux is for the headset jack. If both your speakers and the jack are on that same mux, something else is wrong with your setup. Please go to alsamixer and make sure Speaker Playback Mux is set to Secondary

Thanks for the hint. I've reset the configs and reverted back to the original post-install state. The right speaker sounds a bit too heavy on the bass and lacks clarity, the left speaker straight-up distorts the audio even at low volume. On MacOS they both sound good so we can rule out hardware damage.

Any idea about what could be wrong here?

[chadmed]

@morrolinux please go to /usr/share/asahi-audio/j313/graph.conf and set "amt" under bassex to 1.2. This might help.

[morrolinux]

@morrolinux please go to /usr/share/asahi-audio/j313/graph.conf and set "amt" under bassex to 1.2. This might help.

Thanks! It did help with the (less problematic) right speaker a bit (even though bypassing it completely gave the most noticeable result ofcourse).

What it did not change is the distortion on the left speaker, I'm attacching a sample just to get an idea on how it sounds.

https://github.com/AsahiLinux/asahi-audio/assets/20294254/e651ac2b-c893-4f0a-9683-7f08b3b24ee3

[chadmed]

Did you reboot your machine by any chance?

[morrolinux]

Did you reboot your machine by any chance?

At first I just restarted wireplumber and pipewire, then I rebooted. Why?

[chadmed]

We had issues with sleeping that could be cleared by rebooting at one point, but this doesn't sound like the cause. @marcan might have to help out with this one since I don't own a J313.

[morrolinux]

In the end it all came down to a clogged-up speaker grid. In MacOS it wasn't really noticeable probably because of the EQ, probably because there's no "left only" and "right only" sound coming from the speaker. On MacOS, even when you play such an audio test, you can still hear the audio coming from both speakers, abeit in different proportions. Long story short, I was the problem... But thanks for the support anyways!

[mixi]

eudev is abandonware and we can't support it. all distros should have moved to udev proper by now.

We'll see how abandoned it is. Having found the behaviour difference, I opened a PR there to fix the issue on their end, so feel free to close the issue on this end.

Sadly musl libc based distributions can't switch to systemd's udev without carrying a portability patchset (some of the patches at 1), which upstream explicitly rejected at some point. As it is also a fast moving target some musl distributions don't want to carry the burden for that and are rather maintaining eudev.

[mixi]

This was fixed on eudev's end with https://github.com/eudev-project/eudev/pull/271. Distributions that still use eudev should backport the corresponding commit when enabling asahi-audio.