Hi. I have two MG300 devices I like to sync together however every now and then one of the two devices(either one) e
Will start to play static every now and then. There’s also the issue of either device not syncing up with the other. Any recommendations?
Does this only happen when the device has not been playing audio for some time? If so, try disabling automatic suspending of audio devices (see instructions for PipeWire here)
That howto is one more example of bad practice training, sorry. You do not, ever alter files in /usr like this:
sudo sed -i 's/--\["session.suspend-timeout-seconds"\] = 5/\["session.suspend-timeout-seconds"\] = 0/' /usr/share/wireplumber/main.lua.d/50-alsa-config.lua
That file will be overwritten by the APT/Dpkg on the next pipewire upgrade, and then Ubuntu gets the blame.
How would you apply this change to PipeWire configuration?
Give me a minute to find the correct documentation, because there was a change in wireplumber 0.5, You are most probably still on v0.4.x. and all online docs seem to only talk about the new config format and different override locations…
apt-cache policy wireplumber
You know what, if you want to try your hand yourself, you can open the local documentation:
sudo apt install wireplumber-doc
Then open /usr/share/doc/wireplumber/html/configuration.html in your browser.
The locations section is the interesting one.
Just installed the Wireplumber program yo mentioned and ran the command line for it. Below are the results.
saga-0-1@saga-0-1-B760M-Pro-RS-D4:~$ apt-cache policy wireplumber
wireplumber:
Installed: 0.4.17-1ubuntu4.1
Candidate: 0.4.17-1ubuntu4.1
Version table:
*** 0.4.17-1ubuntu4.1 500
500 Index of /ubuntu noble-updates/main amd64 Packages
100 /var/lib/dpkg/status
0.4.17-1ubuntu4 500
500 Index of /ubuntu noble/main amd64 Packages
Sure you can. With dpkg-divert you can create all the local diversions of system package files that you want. It’s just not necessary in this case because of the ability to use drop-in config/lua script files for wireplumber. Just set up the drop-in directories before hand.
That’d be the package management tools doing it, which is their purview. Messing with files in /usr (except /usr/local) directly is just asking for trouble. And I have seen too many of these bad practice imprinting HowNOTTos. On top of that it’s System76 suggesting this. 
It is never necessary for a user/admin to do such things. That’s what /usr/local, /etc and $XDG_CONFIG_HOME are for.
Either create a drop-in dir on user-only basis
$ mkdir -p ~/.config/wireplumber/main.lua.d
or one for a system-wide basis
$ sudo mkdir -p /etc/wireplumber/main.lua.d/
copy the lua script you want to modify from /usr/share/wireplumber/main.lua/d into one the directories you created and edit it. Then save it as 51-alsa-config.lua so that the name is hierarchically higher than the one you copied and will be processed after the 50-alsa-config.lua
lol. Gosh I wonder why dpkg-divert was programmed to be able to add local diversions then?
Let’s see what the dpkg-divert manpage says.
dpkg-divert is the utility used to set up and update the list of diversions.
File diversions are a way of forcing dpkg(1) not to install a file into its location, but to a diverted location.
Diversions can be used through the package maintainer scripts to move a file away when it causes a conflict. System administrators can also use it to override some package’s configuration file, or whenever some files (which aren’t marked as “conffiles”) need to be preserved by dpkg, when installing a newer version of a package which contains those files.
Don’t know, man. The SYSTEM documentation disagrees with you.
First, can you dial down your 'tude?
Second, name one instance where this is truly necessary, without said admin first having altered files in improper places like /usr, which is package manager territory.
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html
In my 25 years of experience with Debian-based systems, I never once had to make use of local diversions.
P.S.: Even Debian developers don’t like diversions:
Before deciding to use a diversion, read Alternative versions of an interface - update-alternatives (from old Packaging Manual) to see if you really want a diversion rather than several alternative versions of a program.Debian Policy[...]
Do not use diversions for files that have their own native override mechanisms, such as `systemd` unit files.
The alternatives system is a much cleaner approach, borne from the experience with the downsides of packages overwriting each others' files.
I’ll think about it whenever you dial back the absolutist manner of the declarations of your opinions.
I don’t have to justify anything to you. Just because you don’t avail yourself of its capability doesn’t mean some other administator doesn’t find it useful.
WirePlumber’s default locations of its configuration files are determined at compile time by the build system. Typically, those end up being$XDG_CONFIG_DIR/wireplumber,/etc/wireplumber, and/usr/share/wireplumber, in that order of priority. [...] The three locations are intended for custom user configuration, host-specific configuration and distribution-provided configuration, respectively. At runtime, WirePlumber will search the directories for the highest-priority directory to contain the needed configuration file. This allows a user or system administrator to easily override the distribution provided configuration files by **placing an *equally* named file** in the respective directory.
It follows that the modified local override should be named exactly like the one it overrides, i.e. 50-alsa-config.lua. Otherwise the overridden one will still run and the override may be incomplete.
Moderator note to all participants in this topic:
Let’s all take a deep breath here…
We can agree to disagree but respectfully.
Our focus should always be how to help the original poster resolve whatever issue they are dealing with.
Let’s keep this in mind and think carefully about our responses.
Any more off-topic/opinionated/potentially inappropriate comments will be edited or deleted.
I appreciate everyone who is trying to help…let’s get this topic back on track.
Thanks
If the filename is exactly the same the order precedence of sourcing/execution comes into play. User config comes first, then system config. In which case the system config will be processed after the user config and then undoing the changes made by the user.
That’s not quite how it works here, because this is a “first match wins” approach:
When the file is found the search stops.
Also, this will change with Wireplumber 0.5, which is in Ubuntu 26.04. They call them “fragments”, which is just a synonym of drop-ins, in the more commonly understood fashion.
Ah that’s a good point.
@turkmenbashib, I may have found a simple workaround or at least test case, if the issue returns. Use it only if the other method didn’t work just yet.
You can run this command in a terminal and leave the terminal open:
pw-play --latency=1s - </dev/zero
This is a poor user’s keep-alive, because it sends perfect silence to the default audio output, which can thus not be suspended by wireplumber; just don’t close that terminal window. The additional CPU load should be minimal, but it may make a difference for battery life, if that’s important.
If the issue goes away with this keep-alive, we at least know that it’s something to do with suspending devices. If it still happens, there must be another cause.
I’ll give it a shot, but before I do/can I think i’ll need to program the devices to work in sync again. The option that I made previously for both devices to work together is gone now.
As you requested I took it upon myself to post the details I mentioned earlier after one of the audio devices started emitting static.
This is what the error log said:
:38:48 saga-0-1-B760M-Pro-RS-D4 systemd[2800]: Failed to start app-gnome-gnome\x2dkeyring\x2dsecrets-3188.scope - Application launched by gnome-session-binary.
Apr 22 08:38:48 saga-0-1-B760M-Pro-RS-D4 systemd[2800]: Failed to start app-gnome-xdg\x2duser\x2ddirs-3203.scope - Application launched by gnome-session-binary.
Apr 22 08:38:55 saga-0-1-B760M-Pro-RS-D4 gdm3[2199]: Gdm: on_display_removed: assertion ‘GDM_IS_REMOTE_DISPLAY (display)’ failed
Apr 22 10:18:17 saga-0-1-B760M-Pro-RS-D4 pipewire[2826]: spa.alsa: front:0p: snd_pcm_drop: No such device
Apr 22 10:18:33 saga-0-1-B760M-Pro-RS-D4 pipewire-pulse[2831]: mod.combine-stream: error id:43 seq:1224 res:-2 (No such file or directory): target not found
One that stood out was, “spa.alsa: front:0p: snd_pcm_drop: No such device”. As i’ve said I ran “systemctl --user restart pipewire” which was recommended via Google search only for the configuration only for both devices to work together to be erased forcing me just using of the audio devices.
I ran “Sudo dmesg | grep snd” which was another command that was recommended. These are the results:
[ 22.152953] usbcore: registered new interface driver snd-usb-audio
[ 22.203681] snd_hda_intel 0000:00:1f.3: enabling device (0000 → 0002)
[ 22.204289] snd_hda_intel 0000:01:00.1: enabling device (0000 → 0002)
[ 22.204323] snd_hda_intel 0000:01:00.1: Disabling MSI
[ 22.204325] snd_hda_intel 0000:01:00.1: Handle vga_switcheroo audio client
[ 22.453946] snd_hda_codec_alc662 hdaudioC2D0: autoconfig for ALC897: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line
[ 22.453962] snd_hda_codec_alc662 hdaudioC2D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[ 22.453968] snd_hda_codec_alc662 hdaudioC2D0: hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
[ 22.453973] snd_hda_codec_alc662 hdaudioC2D0: mono: mono_out=0x0
[ 22.453976] snd_hda_codec_alc662 hdaudioC2D0: inputs:
[ 22.453980] snd_hda_codec_alc662 hdaudioC2D0: Rear Mic=0x18
[ 22.453985] snd_hda_codec_alc662 hdaudioC2D0: Front Mic=0x19
[ 22.453988] snd_hda_codec_alc662 hdaudioC2D0: Line=0x1a
