pipewire.service does not need to be enabled because it is started by pipewire.socket
If you use this command to check both the socket and service
systemctl --user status pipewire.{socket.service}
Only pipewire.service will show as enabled
but both should show as active (running)
Data from aplay shows DAC is detected in ALSA and Subdevices: 1/1 suggests that device is not connected to PipeWire and is available for direct connection in ALSA
If a software sound server or another application is using ALSA device it would show as unavailable Subdevices: 0/1
I suggest trying audio playback direct to audio device in ALSA
If audio works as expected in ALSA, replacing PipeWire with PulseAudio might help
@6x12
There is another bugzilla report that some MOTU M2 units need to be restarted
211975 – Motu M2 needs a power cycle to work
if I power on the audio interface straight after powering on my laptop it works straight away, otherwise (interface powered on beforehand or after a certain delay) it requires a power cycle to work.
i suspect replacing PW with PA might work, but i’d like to spend more time troubleshooting first
i already tried downgrading alsa-lib only, as well as downgrading everything i could find related to sound (alsa-lib, wireplumber, pipewire, sof-firmware, alsa-card-profiles, libpulse, easyeffects, manjaro-pipewire, gst-plugin-pipewire, pipewire-zeroconf, pipewire-pulse, pipewire-jack, pipewire-alsa)
i also saw the report of powering on the DAC after booting but that didn’t work either
$ systemctl --user status pipewire.{socket.service}
Invalid unit name "pipewire.{socket.service}" escaped as "pipewire.\x7bsocket.service\x7d" (>
Unit pipewire.\x7bsocket.service\x7d.service could not be found.
sample rate in pipewire.conf is 4800 by default which i believe matches the MOTU M2
default.clock.rate = 48000
can you explain what you mean by "Make sure you have the latest driver (May’22) and firmware (March '22) "?
i’m not aware of any drivers or firmware other than what’s in the kernel (i’ve tried 5.18 and 5.15) and the sof-firmware package which is up to date
systemctl command suggested had a typo - should be comma separating ‘socket’ and ‘service’
if you intend to post response here you should also add a couple of extra options so response is not truncated
systemctl --user -l --no-pager status pipewire.{socket,service}
i don’t know how to route playback direct to ALSA
Many music players can be configured to play audio direct to an ALSA hardware device
instead of via PipeWire/PulseAudio
This audio interface has an ADC for audio capture in addition to DAC for audio playback, so you may want to consider using Audacity to check audio inputs and outputs in ALSA
Yes, the ‘driver’ here is indeed the win driver that shouldn’t matter in your case, however, a missed firmware update will/can affect use under any os.
very interesting (i use and (mostly) love Audacity) - so i fired it up, set output to ALSA and my DAC was listed - selecting it and playing something works … first time i heard sound from speakers in 2 days!
so what does this tell me? being that the DAC works using ALSA, does this mean the problem is isolated to pipewire?
thing is, i tried downgrading everything pipewire related, as well as sof-firmware, and i couldn’t get the DAC to work (it was working prior to the 7-18 update) which causes me to question whether it’s a pipewire issue
on another note, i tried swapping pipewire for pulse and that ended up in disaster (circular dependency hell, broken desktop) so i ended up installing manjaro-pipewire + wireplumber again and so now i’m right back to square 1 … no audio from the DAC; in System Settings > Audio DAC profile is “off” and that’s the only option available (but, as mentioned, i can get it to work in Audacity)
KDE requires both core packages pulseaudio and pipewire and they cannot be removed without dependency problems
But if you install the PulseAudio metapackage
pamac install manjaro-pulse
That should be able to remove packages pipewire-pulse pipewire-zeroconf manjaro-pipewire
and replace them with pulseaudio,pulseaudio-alsa, pulseaudio-bluetooth, pulseaudio-zeroconf
with no package-manager requests to remove any KDE audio control packages
Then stop and disable the pipewire socket and service
$ sudo pamac install manjaro-pulse
[sudo] password for atom:
Preparing...
Synchronizing package databases...
Refreshing AUR...
Choose optional dependencies for manjaro-pulse:
1: paprefs: Configuration dialog
2: pasystray: system tray application
3: pavucontrol: A GTK volume control tool
4: pavucontrol-qt: A Qt volume control tool
5: pulseaudio-ctl: Control volume from the shell or mapped to keyboard shortcuts
6: pulseaudio-equalizer: Graphical equalizer
7: pulseaudio-equalizer-ladspa: A 15-band equalizer
8: pulseaudio-jack: Jack support
9: pulseaudio-lirc: IR (lirc) support
10: pulseaudio-rtp: RTP and RAOP support
Enter a selection (default=none):
Resolving dependencies...
Checking inter-conflicts...
Error: Failed to prepare transaction:
could not satisfy dependencies:
- unable to satisfy dependency 'pulseaudio-bluetooth' required by manjaro-pulse
this may have something to do with my problem in that pipewire may have missing deps from pulse, however when i …
$ sudo downgrade alsa-firmware
Downgrading from A.L.A. is disabled on the stable branch. To override this behavior, set DOWNGRADE_FROM_ALA to 1.
See https://wiki.manjaro.org/index.php/Downgrading_packages for more details.
No results found
Unable to downgrade alsa-firmware
alsa-utils i can downgrade, but i don’t know if it’s worth it at this point
i’m guessing you meant pulseaudio-bluethooth?
i may try this - right now i’m just disgusted for several reasons
So the Arch report in post#19 was the right way to go, but both of us failed to spot alsa-ucm-conf, and everything else was not relevant
The irriting thing for me is that I was looking at the changelogs for ALSA packages last week
to see what new hardware devices were getting support and there is no mention of changes relating to MOTU devices
from reading reports of others, i’m not sure that the alsa-ucm-conf issue is specific to Manjaro, pipewire or the MOTU M2 - for example i tried other live USB distros and had similar problems - in the case of MX Linux the M2 would play sound for a few seconds and then quit regardless of what input/output type was selected
the downgrade of the file appears to have also worked for non-MOTU interfaces according to reports