pipewire issueshttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues2023-04-16T16:39:32Zhttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3161filter-chain regression with 0.3.692023-04-16T16:39:32ZA Tfilter-chain regression with 0.3.69A filter-chain derived from sink-eq6.conf from the Pipewire examples works well on 0.3.68, but won't start on 0.3.69. Multiple errors are logged:
```
Apr 15 18:38:37 hostname systemd[1066]: Started PipeWire Multimedia Service.
Apr 15 18:...A filter-chain derived from sink-eq6.conf from the Pipewire examples works well on 0.3.68, but won't start on 0.3.69. Multiple errors are logged:
```
Apr 15 18:38:37 hostname systemd[1066]: Started PipeWire Multimedia Service.
Apr 15 18:39:21 hostname pipewire[4729]: mod.filter-chain: cannot create plugin instance: Invalid argument
Apr 15 18:39:21 hostname pipewire[4729]: pw.stream: 0x560422030d30: error can't start graph: Invalid argument
Apr 15 18:39:21 hostname pipewire[4729]: mod.filter-chain: cannot create plugin instance: Invalid argument
Apr 15 18:39:21 hostname pipewire[4729]: pw.node: (effect_input.hpeq-0) start node error -5: Input/output error
Apr 15 18:39:21 hostname pipewire[4729]: mod.client-node: node 0x56042206a440: start failed
Apr 15 18:39:21 hostname pipewire[4729]: pw.core: 0x560421fa5950: error -22 for resource 2: can't start graph: Invalid argument
Apr 15 18:39:21 hostname pipewire[4729]: mod.client-node: 0x5604221a5570: error seq:205 -22 (can't start graph: Invalid argument)
Apr 15 18:39:21 hostname pipewire[4729]: pw.core: 0x560421fa5950: error -22 for resource 2: can't start graph: Invalid argument
Apr 15 18:39:21 hostname pipewire[4729]: mod.client-node: 0x5604221a5570: error seq:215 -22 (can't start graph: Invalid argument)
Apr 15 18:39:21 hostname pipewire[4729]: pw.core: 0x560421fa5950: error -5 for resource 2: start failed
Apr 15 18:39:21 hostname pipewire[4729]: mod.client-node: 0x5604221a5570: error seq:215 -5 (start failed)
Apr 15 18:39:27 hostname pipewire[4729]: mod.filter-chain: cannot create plugin instance: Invalid argument
Apr 15 18:39:27 hostname pipewire[4729]: pw.node: (effect_input.hpeq-0) start node error -5: Input/output error
Apr 15 18:39:27 hostname pipewire[4729]: mod.client-node: node 0x56042206a440: start failed
Apr 15 18:39:27 hostname pipewire[4729]: pw.core: 0x560421fa5950: error -22 for resource 2: can't start graph: Invalid argument
Apr 15 18:39:27 hostname pipewire[4729]: mod.client-node: 0x5604221a5570: error seq:265 -22 (can't start graph: Invalid argument)
Apr 15 18:39:27 hostname pipewire[4729]: pw.core: 0x560421fa5950: error -5 for resource 2: start failed
Apr 15 18:39:27 hostname pipewire[4729]: mod.client-node: 0x5604221a5570: error seq:265 -5 (start failed)
Apr 15 18:39:29 hostname pipewire[4729]: mod.filter-chain: cannot create plugin instance: Invalid argument
Apr 15 18:39:29 hostname pipewire[4729]: pw.node: (effect_input.hpeq-0) start node error -5: Input/output error
Apr 15 18:39:29 hostname pipewire[4729]: mod.client-node: node 0x56042206a440: start failed
```
pw-top shows only one of two expected filter-chains (output, no input) and playback attempts result in accumulated errors. Interestingly the 7.1 virtual surround sound chains load.
I suspect this might be related to the biquad filter changes between 0.3.68 and 0.3.69. Downgrading to 0.3.68 works OK (Arch Linux packages).
P.S. Is it possible to add some of the filter-chain examples as regression tests before releasing a new version? The ones that don't require LADSPA filters should be easy-ish to test?https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3160No apparent way to partially override /usr/share/pipewire/pipewire.conf confi...2023-04-17T08:35:57ZprezNo apparent way to partially override /usr/share/pipewire/pipewire.conf config fileMy distribution provides a `/usr/share/pipewire/pipewire.conf` with
```
context.exec = [
{ path = "/usr/bin/pipewire-media-session" args = "" }
]
```
I would like to switch to wireplumber, so I created a `~/.config/pipewire/pipewire...My distribution provides a `/usr/share/pipewire/pipewire.conf` with
```
context.exec = [
{ path = "/usr/bin/pipewire-media-session" args = "" }
]
```
I would like to switch to wireplumber, so I created a `~/.config/pipewire/pipewire.conf.d/00-sessionmgr-exec.conf` with the following contents:
```
context.exec = [
{ path = "/usr/bin/wireplumber" args = "" }
{ path = "/usr/bin/pipewire-pulse" args = "" }
]
```
**Expected behaviour**: only `wireplumber` and `pipewire-pulse` are started.
**Actual behavior**: `pipewire-media-session`, `wireplumber` and `pipewire-pulse` are started.
I took a look at the wiki. It mentions:
> Note!! Properties will override the previous ones, array entries will be appended. It is not possible yet to change or remove existing array entries. This only applied to the first level objects, arrays in properties will be overwritten as usual.
How does one achieve this?
If this is not implemented, then please give us a way to override the `context.exec` array in my user directory without having to change the system config file. Thank you.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3159Multiple allowed sample rates + virtual surround sink = loss of audio output2023-04-25T08:26:47ZBrisse89Multiple allowed sample rates + virtual surround sink = loss of audio output- PipeWire version: 0.3.68
- Distribution and distribution version: Debian GNU/Linux 12 (bookworm)
- Desktop Environment: GNOME
- Kernel version): 6.1.0-7-amd64
## Description of Problem:
Allowing multiple sample rates while using [virt...- PipeWire version: 0.3.68
- Distribution and distribution version: Debian GNU/Linux 12 (bookworm)
- Desktop Environment: GNOME
- Kernel version): 6.1.0-7-amd64
## Description of Problem:
Allowing multiple sample rates while using [virtual-surround-sink](https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/src/daemon/filter-chain/sink-virtual-surround-7.1-hesuvi.conf) causes issues, potentially leading to loss of audio output.
## How Reproducible:
100% if following steps below
### Steps to Reproduce:
1. Set `default.clock.allowed-rates = [ 44100 48000 ]` in pipewire.conf
2. Add a [virtual-surround-sink](https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/src/daemon/filter-chain/sink-virtual-surround-7.1-hesuvi.conf)
3. Restart PipeWire `systemctl --user restart pipewire`
4. Run pw-top and observe while doing following steps
5. Play any 44.1khz content (I play music in Rhythmbox) to make the audio chain switch to 44.1khz and then stop.
6. In pw-top, effect_output.virtual-surround-7.1 is now stuck at a rate of 44100.
7. Play any 48khz content (I use video in MPV) and note in pw-top that the rates displayed do not match, and the audio is completely gone
### Actual Results:
Complete loss of audio and effect_output.virtual-surround-7.1 stuck at the wrong sample rate.
### Expected Results:
Sample rates should switch back and forth seamlessly without loss of audio, and since we stopped playing the 44.1khz content before starting the 48khz content, there should be no simultaneous mismatch of sample rates displayed in pw-top, i.e. effect_output.virtual-surround-7.1 should switch back to 48khz rather than being stuck at 44.1khz.
### Additional information
Here are my specific configuration files. The virtual-surround-sink is slightly different from PipeWire's sample config but I don't know if it matters. Specifically, it has IR's for both sample rates and I've added an extra convolution step to correct the frequency response for my headphones.
[pipewire.conf](/uploads/18cc5ad5a2e0d9479ee8115afc40bcfc/pipewire.conf)
[sink-virtual-surround-7.1-hd555.conf](/uploads/ea65ab4d8f74d245579649eaa4c54746/sink-virtual-surround-7.1-hd555.conf)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3158Incorrect output selection on Raspberry Pi 4/4002023-04-14T08:10:09ZDave JonesIncorrect output selection on Raspberry Pi 4/400While testing the Ubuntu desktop images for Raspberry Pi which now use pipewire, I ran into a couple of odd default audio selections: [LP: #1993316](https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/1993316), [LP: #1993347](https:/...While testing the Ubuntu desktop images for Raspberry Pi which now use pipewire, I ran into a couple of odd default audio selections: [LP: #1993316](https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/1993316), [LP: #1993347](https://bugs.launchpad.net/ubuntu/+source/pipewire/+bug/1993347).
On the Raspberry Pi 4 it's a mild annoyance: the audio jack is selected as the default output rather than the HDMI audio. However, on the Pi 400 (the keyboard-based model) it's a bit more serious as the audio jack doesn't exist on that board so the stack is selecting a non-existent output.
I'm unfortunately not yet familiar with the pipewire stack, but I'll try and add some more useful details once the madness of the release has calmed down!https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3157[Gamescope] Streaming crashes steam when gamescope is used2023-04-13T14:20:10ZMatthew Anderson[Gamescope] Streaming crashes steam when gamescope is usedThere have been multiple reports that after 0.3.59 of pipewire streaming broke on ChimeraOS and I'm just now starting to get around to look into it. I got a journal log showing the crash event.
[Stream-crash.log](/uploads/5404b861ac64dd5...There have been multiple reports that after 0.3.59 of pipewire streaming broke on ChimeraOS and I'm just now starting to get around to look into it. I got a journal log showing the crash event.
[Stream-crash.log](/uploads/5404b861ac64dd5d326166cad7735008/Stream-crash.log)
I am still investigating the issue and need to sort out some compilation issues to be able to confirm on my end that 0.3.59 was indeed the last working version. I do know for certain that streaming did work at one point so it's a regression.
Here are my current notes:
- Streaming from ChimeraOS to Steam Link works
- Streaming from Chimeraos to ChimeraOS crashes
- Streaming from ChimeraOS to SteamOS (Steam Deck) crashes ( I haven't confirmed this yet myself)
It seems Valve might think the issues is with pipewire and not gamescope itself.
https://github.com/ValveSoftware/gamescope/issues/775#issuecomment-1500715234https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3156AirPlay: No Audio2024-02-26T18:08:53ZerebionAirPlay: No Audio<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`):
```
pipewire
Compiled with libpipewire 0.3.65
Linked with libpipewire 0.3.65
```
-...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`):
```
pipewire
Compiled with libpipewire 0.3.65
Linked with libpipewire 0.3.65
```
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): `Debian GNU/Linux 12 (bookworm)`
- Desktop Environment: MATE
- Kernel version (`uname -r`): `6.1.0-7-amd64`
## Description of Problem:
Using `module-raop-discover`, I get sinks for AirPlay devices, but cannot play audio.
## How Reproducible:
Install the module, load it, try to play audio. No audio.
### Steps to Reproduce:
1. Install the module
2. Load it
3. Try to play audio
4. no audio
### Actual Results:
No Audio
### Expected Results:
Audio
# Additional Info (as attachments):
`PIPEWIRE_DEBUG=3 pw-cli -m load-module libpipewire-module-raop-discover`
Output:
```
[I][03475.660855] mod.raop-sink | [module-raop-sink: 853 rtsp_setup_reply()] reply 200
[I][03475.660889] mod.raop-sink | [module-raop-sink: 889 rtsp_setup_reply()] server port:6000
[I][03475.660907] mod.raop-sink | [module-raop-sink: 905 rtsp_setup_reply()] control:6001 timing:6002
[I][03475.660949] mod.raop-sink | [module-raop-sink: 641 connect_socket()] Connected to host:169.254.208.79 port:6000
[I][03475.660969] mod.raop-sink | [module-raop-sink: 641 connect_socket()] Connected to host:169.254.208.79 port:6001
[I][03475.660987] mod.raop-sink | [module-raop-sink: 641 connect_socket()] Connected to host:169.254.208.79 port:6002
[I][03475.661047] default | [ rtsp-client.c: 426 flush_output()] sent: RECORD rtsp://192.168.178.37/569144142 RTSP/1.0
CSeq: 4
Client-Instance: 55b42417500d93ff
User-Agent: iTunes/11.0.4 (Windows; N)
Session: 1
Range: npt=0-
RTP-Info: seq=57071;rtptime=1402560660
[I][03475.677499] default | [ rtsp-client.c: 263 process_status()] status: RTSP/1.0 453 Not Enough Bandwidth
[I][03475.677665] default | [ rtsp-client.c: 337 process_header()] Server: AirTunes/105.1
[I][03475.677689] default | [ rtsp-client.c: 337 process_header()] CSeq: 3
[I][03475.677706] default | [ rtsp-client.c: 296 dispatch_handler()] received reply to request with cseq:3
[I][03475.677722] mod.raop-sink | [module-raop-sink: 853 rtsp_setup_reply()] reply 453
[E][03475.677737] mod.raop-sink | [module-raop-sink: 856 rtsp_setup_reply()] missing Session header
[I][03475.742735] default | [ rtsp-client.c: 263 process_status()] status: RTSP/1.0 200 OK
[I][03475.742897] default | [ rtsp-client.c: 337 process_header()] Audio-Latency: 15409
[I][03475.742924] default | [ rtsp-client.c: 337 process_header()] Server: AirTunes/105.1
[I][03475.742942] default | [ rtsp-client.c: 337 process_header()] CSeq: 4
[I][03475.742961] default | [ rtsp-client.c: 296 dispatch_handler()] received reply to request with cseq:4
[I][03475.742981] mod.raop-sink | [module-raop-sink: 765 rtsp_record_reply()] reply 200
[I][03475.743194] default | [ rtsp-client.c: 426 flush_output()] sent: SET_PARAMETER rtsp://192.168.178.37/569144142 RTSP/1.0
CSeq: 5
Content-Type: text/parameters
Content-Length: 17
progress: 0/0/0
```
- `pw-dump > pw-dump.log`:https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3155pipewire not working with Falkon, Firefox or mpv2023-04-14T20:17:20ZGhost Userpipewire not working with Falkon, Firefox or mpvWith pipewire running (i'm on Artix linux, s6 init env, LXQT desktop env, using pipewire, pipewire-pulse & wireplumber, just upgraded to 1:0.3.68 from 1:0.3.67, and still exactly the same problems) mpv starts every stream at current posi...With pipewire running (i'm on Artix linux, s6 init env, LXQT desktop env, using pipewire, pipewire-pulse & wireplumber, just upgraded to 1:0.3.68 from 1:0.3.67, and still exactly the same problems) mpv starts every stream at current position -106:45:06 (therefore, can't usefully seek in stream) and audio of videos play (in Falkon... not at all in Firefox) but the video and timecounter don't advance. This is a showstopper for me. I was happy to not run pipewire at all (just using alsa) and everything worked fine, except alsa doesn't allow me to use my new audio interface (without tweaking the alsa config, which i haven't tried).https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3154Ardour with pipewire-jack gets confused with inputs2023-05-24T09:24:00ZJ MArdour with pipewire-jack gets confused with inputs- PipeWire version (`pipewire --version`): 0.3.67
Wireplumber 0.4.14
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Debian unstable
- Desktop Environment: KDE 5.27.2
- Kernel version (`uname -r`): 6.1.0-6...- PipeWire version (`pipewire --version`): 0.3.67
Wireplumber 0.4.14
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Debian unstable
- Desktop Environment: KDE 5.27.2
- Kernel version (`uname -r`): 6.1.0-6-amd64
## Description of Problem:
[pw-dump.log](/uploads/cc082977be42521d2012e1b44a90761a/pw-dump.log)
I do have many audio inputs :
- one internal webcam
- one USB external webcam
- one USB external sound card Behringer UMC204HD
The problem happens with Ardourd 7.3 with pipewire-jack.
When I import an audio file in my session, all my audio inputs get connected to it despite it doesn't need any.
When I create an audio track afterwards, I can't manage to get any input connected to it.
Trying to disconnect them from within Ardour or by the means of qpwgraph, doesn't change anything.
Workaroud : creating the audio track prior to importing the audio file.
## How Reproducible:
Always.
### Steps to Reproduce:
1. Open Ardour 7.3
2. Create a new session
3. Import an audio file as a track
4. Create an audio track
### Actual Results:
All audio inputs connected to the audio file track. Impossible to disconnect them properly, making impossible for the audio track to get connected to the input of the USB external sound card it requires.
### Expected Results:
It should work like with jack: the audio track should be automatically connected to the first input of the USB external sound card.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`:https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3153Connections broken between PipeWire Midi-Bridge ports2023-04-12T10:11:34ZMark KnoopConnections broken between PipeWire Midi-Bridge ports- PipeWire version (0.3.68):
- Distribution and distribution version (Fedora Linux 37 (Workstation Edition)):
- Desktop Environment: Sway
- Kernel version (6.2.9-200.fc37.x86_64):
## Description of Problem:
Midi messages are not passed...- PipeWire version (0.3.68):
- Distribution and distribution version (Fedora Linux 37 (Workstation Edition)):
- Desktop Environment: Sway
- Kernel version (6.2.9-200.fc37.x86_64):
## Description of Problem:
Midi messages are not passed through the PipeWire Midi-Bridge to SuperCollider until/unless the source is also connected to another PipeWire Midi port.
## How Reproducible:
100%
### Steps to Reproduce:
Timestamps in square brackets refer to attached log file.
1. Boot SuperCollider [16205]
2. Initialize SuperCollider MIDI Client [16214]
3. Link midi keyboard output port with SuperCollider input port [16222]
4. Press key on midi keyboard [~16230] - no output in log file, no response in SuperCollider
5. Link midi keyboard output port with pw-mididump input port [16251] - only now SuperCollider receives the NoteOn message
### Actual Results:
SuperCollider doesn't receive the NoteOn message until the keyboard port is also linked to pw-mididump.
### Expected Results:
Messages should be passed immediately through Midi-Bridge connection.
# Additional Info (as attachments):
- `PIPEWIRE_DEBUG=D PIPEWIRELOG=pipewire.log sclang`: [pipewire.log](/uploads/14b837f55913979ac874bda95adc982e/pipewire.log)
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/3ace8f4c055674f78998c1456fc5d366/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/31520.3.67 -> 0.3.68 upgrade causing disappearing devices when combined with a dock2023-04-13T09:13:59ZDan Seminara0.3.67 -> 0.3.68 upgrade causing disappearing devices when combined with a dock<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): 0.3.68
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): 0.3.68
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: n/a
- Kernel version (`uname -r`): 6.1.15-1-lts
## Description of Problem:
When using a thunderbolt dock, docking and undocking my laptop (Lenovo X1 Carbon gen 7) results in the speakers disappearing as an option for audio output. After undocking, I can only play audio through headphones until a reboot.
## How Reproducible:
I can always reproduce
### Steps to Reproduce:
1. Open `pavucontrol` and see the current output devices
2. Devices listed are:
1. CannonPoint-LP High Definition Audio Controller HDMI / DisplayPort 3 Output (unplugged)
1. CannonPoint-LP High Definition Audio Controller HDMI / DisplayPort 2 Output (unplugged)
1. CannonPoint-LP High Definition Audio Controller HDMI / DisplayPort 1 Output (unplugged)
1. [selected as default] CannonPoint-LP High Definition Audio Controller Speaker + Headphones
1. Port dropdowns: Headphones (unplugged), Speaker
1. Connect the dock to the laptop
1. Devices listed are:
1. CannonPoint-LP High Definition Audio Controller HDMI / DisplayPort 3 Output (unplugged)
1. CannonPoint-LP High Definition Audio Controller HDMI / DisplayPort 2 Output (unplugged)
1. CannonPoint-LP High Definition Audio Controller HDMI / DisplayPort 1 Output (plugged in)
1. CannonPoint-LP High Definition Audio Controller Speaker + Headphones
1. Port dropdowns: Headphones (unplugged)
1. [selected as default] PCM2912A Audio Codec Analog Stereo
1. HDMI/DP 1 now appears plugged in, Speaker port under Speaker + Headphones device is missing, and new device for dock is present
1. Disconnect the dock
1. Devices listed are:
1. CannonPoint-LP High Definition Audio Controller HDMI / DisplayPort 3 Output (unplugged)
1. CannonPoint-LP High Definition Audio Controller HDMI / DisplayPort 2 Output (unplugged)
1. [selected as default] CannonPoint-LP High Definition Audio Controller HDMI / DisplayPort 1 Output (plugged in)
1. CannonPoint-LP High Definition Audio Controller Speaker + Headphones
1. Port dropdowns: Headphones (unplugged)
1. HDMI/DP 1 still appears plugged in despite the dock being disconnected, and the Speaker port did not reappear for the Speaker + Headphones device.
### Actual Results:
Switching the default to CannonPoint-LP High Definition Audio Controller Speaker + Headphones still doesn't play sound unless headphones are plugged in.
### Expected Results:
Behavior in 0.3.67:
- CannonPoint-LP High Definition Audio Controller Speaker + Headphones should keep the Speaker port option and be chosen as the default when unplugging the dock
Additionally HDMI/DP 1 should appear as unplugged, but that is a separate issue was present before 0.3.68.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3151Upmixing LFE not working despite manual configuration2023-04-26T08:21:47ZRobotRossUpmixing LFE not working despite manual configuration<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): pipewire
Compiled with libpipewire 0.3.68
Linked with libpipewire 0.3.68
- Distribut...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): pipewire
Compiled with libpipewire 0.3.68
Linked with libpipewire 0.3.68
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Fedora Workstation 37
- Desktop Environment: GNOME 43.4
- Kernel version (`uname -r`): 6.2.9-200.fc37.x86_64
## Description of Problem:
LFE channel mixing nonfunctional from stereo channels.
## How Reproducible:
Always.
### Steps to Reproduce:
1. Configure pipewire for output to 2.1 ( FL, FR, LFE )
2. Enable upmixing via config file in `{HOME}/.config/pipewire/pipewire.conf.d` . [20-upmix.conf](/uploads/cc61e499e418132fd78501879a2b7ca0/20-upmix.conf)
### Actual Results:
No mixed LFE present (Applications which can output directly to LFE work fine, but applications which should have a mixed LFE signal do nothing)
### Expected Results:
LFE channel should be mixed from speaker channels based on cutoff frequency.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/5c740186c2244388bf562887047449af/pw-dump.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3150pipewire 0.3.68 segfault in impl_check()2023-04-15T14:04:21ZJustin Millerpipewire 0.3.68 segfault in impl_check()- PipeWire version: 0.3.68
- Distribution and distribution version: Arch Linux
- Desktop Environment: Plasma 5
- Kernel version: 6.2.10-arch1-1
## Description of Problem:
SEGFAULT in impl_check()
## How Reproducible:
Reproduced by di...- PipeWire version: 0.3.68
- Distribution and distribution version: Arch Linux
- Desktop Environment: Plasma 5
- Kernel version: 6.2.10-arch1-1
## Description of Problem:
SEGFAULT in impl_check()
## How Reproducible:
Reproduced by different users: https://github.com/mumble-voip/mumble/issues/6101
### Actual Results:
<details><summary>debug session</summary>
```
PIPEWIRE_DEBUG=2 gdb mumble
Reading symbols from mumble...
Reading symbols from .cache/debuginfod_client/ab24f2d99d99cf5005d07405c5c215da1bde0375/debuginfo...
(gdb) run
Starting program: /usr/bin/mumble
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7ffff1ec96c0 (LWP 2164)]
[New Thread 0x7ffff16c86c0 (LWP 2165)]
ALSA lib pcm.c:2666:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2666:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2666:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib pcm_route.c:877:(find_matching_chmap) Found no matching channel map
[New Thread 0x7fffe9bdd6c0 (LWP 2166)]
[Thread 0x7fffe9bdd6c0 (LWP 2166) exited]
[New Thread 0x7fffe9bdd6c0 (LWP 2168)]
[Thread 0x7fffe9bdd6c0 (LWP 2168) exited]
[New Thread 0x7fffe9bdd6c0 (LWP 2170)]
[Thread 0x7fffe9bdd6c0 (LWP 2170) exited]
[New Thread 0x7fffe9bdd6c0 (LWP 2172)]
[Thread 0x7fffe9bdd6c0 (LWP 2172) exited]
ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
ALSA lib pcm_oss.c:397:(_snd_pcm_oss_open) Cannot open device /dev/dsp
[New Thread 0x7fffe9bdd6c0 (LWP 2173)]
[New Thread 0x7fffe93826c0 (LWP 2175)]
[Thread 0x7fffe93826c0 (LWP 2175) exited]
[Thread 0x7fffe9bdd6c0 (LWP 2173) exited]
[New Thread 0x7fffe9bdd6c0 (LWP 2176)]
[New Thread 0x7fffe93826c0 (LWP 2178)]
[Thread 0x7fffe93826c0 (LWP 2178) exited]
[Thread 0x7fffe9bdd6c0 (LWP 2176) exited]
[New Thread 0x7fffe9bdd6c0 (LWP 2179)]
[Thread 0x7fffe9bdd6c0 (LWP 2179) exited]
[New Thread 0x7fffe9bdd6c0 (LWP 2180)]
[Thread 0x7fffe9bdd6c0 (LWP 2180) exited]
ALSA lib pcm_a52.c:1001:(_snd_pcm_a52_open) a52 is only for playback
ALSA lib confmisc.c:160:(snd_config_get_card) Invalid field card
ALSA lib pcm_usb_stream.c:482:(_snd_pcm_usb_stream_open) Invalid card 'card'
ALSA lib confmisc.c:160:(snd_config_get_card) Invalid field card
ALSA lib pcm_usb_stream.c:482:(_snd_pcm_usb_stream_open) Invalid card 'card'
[New Thread 0x7fffe9bdd6c0 (LWP 2181)]
[New Thread 0x7fffe93826c0 (LWP 2183)]
[Thread 0x7fffe93826c0 (LWP 2183) exited]
[Thread 0x7fffe9bdd6c0 (LWP 2181) exited]
[New Thread 0x7fffe9bdd6c0 (LWP 2185)]
[New Thread 0x7fffe93826c0 (LWP 2187)]
[Thread 0x7fffe93826c0 (LWP 2187) exited]
[Thread 0x7fffe9bdd6c0 (LWP 2185) exited]
[New Thread 0x7fffe9bdd6c0 (LWP 2188)]
[New Thread 0x7fffe9bdd6c0 (LWP 2190)]
[Thread 0x7fffe9bdd6c0 (LWP 2188) exited]
[New Thread 0x7fffe93826c0 (LWP 2191)]
[New Thread 0x7fffcbdff6c0 (LWP 2193)]
[New Thread 0x7fffcb5fe6c0 (LWP 2194)]
[New Thread 0x7fffca1ff6c0 (LWP 2195)]
[New Thread 0x7fffc99fe6c0 (LWP 2196)]
[New Thread 0x7fffc91fd6c0 (LWP 2197)]
[New Thread 0x7fffc89fc6c0 (LWP 2198)]
[New Thread 0x7fffb3bff6c0 (LWP 2199)]
[W][00954.063652] default | [ thread.c: 101 impl_acquire_rt()] acquire_rt thread:0x7fffb3bff6c0 prio:-1 not implemented
[New Thread 0x7fffb33fe6c0 (LWP 2200)]
[New Thread 0x7fffb2bfd6c0 (LWP 2201)]
[Thread 0x7fffb2bfd6c0 (LWP 2201) exited]
[New Thread 0x7fffb2bfd6c0 (LWP 2202)]
[W][00954.094983] default | [ thread.c: 101 impl_acquire_rt()] acquire_rt thread:0x7fffb2bfd6c0 prio:-1 not implemented
[New Thread 0x7fffb23fc6c0 (LWP 2203)]
[New Thread 0x7fffb1bfb6c0 (LWP 2204)]
[Thread 0x7fffb1bfb6c0 (LWP 2204) exited]
[Thread 0x7fffb33fe6c0 (LWP 2200) exited]
warning: The VAD has been replaced by a hack pending a complete rewrite
Thread 1 "mumble" received signal SIGSEGV, Segmentation fault.
0x00007fffea2a08c4 in impl_check (data=0x555556eb98a0, loop=0x555556ef46b0) at ../pipewire/src/pipewire/thread-loop.c:95
95 if (spa_loop_control_check(this->loop->control) == 1)
(gdb) bt
#0 0x00007fffea2a08c4 in impl_check (data=0x555556eb98a0, loop=0x555556ef46b0) at ../pipewire/src/pipewire/thread-loop.c:95
#1 0x00007fffea2a3043 in pw_stream_destroy (stream=0x555556eba6a0) at ../pipewire/src/pipewire/stream.c:1652
#2 0x00005555557ef62f in PipeWireEngine::~PipeWireEngine() (this=0x555556ef5cc0, this=<optimized out>)
at /usr/include/c++/12.2.1/bits/unique_ptr.h:191
#3 std::default_delete<PipeWireEngine>::operator()(PipeWireEngine*) const (this=<optimized out>, __ptr=0x555556ef5cc0)
at /usr/include/c++/12.2.1/bits/unique_ptr.h:95
#4 std::default_delete<PipeWireEngine>::operator()(PipeWireEngine*) const (__ptr=0x555556ef5cc0, this=<optimized out>)
at /usr/include/c++/12.2.1/bits/unique_ptr.h:89
#5 std::unique_ptr<PipeWireEngine, std::default_delete<PipeWireEngine> >::~unique_ptr() (this=0x555556ef3b70, this=<optimized out>)
at /usr/include/c++/12.2.1/bits/unique_ptr.h:396
#6 PipeWireInput::~PipeWireInput() (this=0x555556ef3320, this=<optimized out>)
at /usr/src/debug/mumble/mumble-1.5.517/src/mumble/PipeWire.cpp:336
#7 0x00005555557ef68d in PipeWireInput::~PipeWireInput() (this=0x555556ef3320, this=<optimized out>)
at /usr/src/debug/mumble/mumble-1.5.517/src/mumble/PipeWire.cpp:336
#8 0x0000555555693a15 in boost::detail::sp_counted_base::release() (this=0x555556ea7640)
at /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_atomic.hpp:120
#9 boost::detail::sp_counted_base::release() (this=0x555556ea7640) at /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_atomic.hpp:116
#10 boost::detail::shared_count::~shared_count() (this=<optimized out>, this=<optimized out>)
at /usr/include/boost/smart_ptr/detail/shared_count.hpp:432
..
```
</details>
# Additional Info:
It is reported in the linked thread that the issue appears with 0.3.68.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3149Gstreamer pipewiresrc element produces non-monotonously timestamped buffers w...2023-04-20T11:28:48ZMarkus EbnerGstreamer pipewiresrc element produces non-monotonously timestamped buffers with keepalive- PipeWire version (`pipewire --version`):
Compiled with libpipewire 0.3.67
Linked with libpipewire 0.3.67
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):
openSUSE Tumbleweed
- Desktop Environment:
...- PipeWire version (`pipewire --version`):
Compiled with libpipewire 0.3.67
Linked with libpipewire 0.3.67
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):
openSUSE Tumbleweed
- Desktop Environment:
KDE 5.27.4
- Kernel version (`uname -r`):
6.2.9-1-default
## Description of Problem:
I am using `pipewiresrc` with a dynamic-framerate source (screencapture of an application window).
At least with kwin_wayland as window-manager and Firefox as captured window, `pipewiresrc` only receives a new frame whenever something changed (e.g. mouse cursor moved over the captured window, or content of the window changed) - thus the variable framerate.
The caps here are: `video/x-raw,framerate=0/1,max-framerate=25/1`
Because of this, the entire pipeline could potentially go to sleep for hours when nothing changes.
The `keepalive-time` option in `pipewiresrc` avoids that problem by sending the last buffer **with a new timestamp** on a regular/timeout basis.
However, the dts/pts timestamps of the buffers that were emitted due to the keepalive timeout seem to have a totally different clock and reference time than the ones comming from pipewire/kwin.
This makes the timestamps in the pipeline non-monotonous and drives many elements in the GStreamer pipeline absolute bonkers.
### Steps to Reproduce:
By whatever means (I wrote a small application), start a screencast for an application window and insert the first stream's nodeId into the following pipeline:
```
GST_DEBUG="3,pipewiresrc:8" gst-launch-1.0 pipewiresrc do-timestamp=true keepalive-time=500 path=<%NODE_ID%> client-name=<%APPLICATION_NAME%> ! videoconvert ! autovideosink
```
### Actual Results:
Here is an excerpt of the produced log.
Buffers that originated from a new incomming buffer from pipewire/kwin all have a timestamp of `0:00:00.000000000`:
```
0:00:16.327006168 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:1177:gst_pipewire_src_create:<pipewiresrc0> popped buffer 0x7f224c02bee0
0:00:16.327010458 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:480:buffer_recycle:<pipewiresrc0> recycle buffer 0x7f2240008ab0
0:00:16.327016228 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:1222:gst_pipewire_src_create:<pipewiresrc0> pts 16313538000, dts 16313538000, base-time 8:07:02.500927324 -> 0:00:00.000000000, 0:00:00.000000000
0:00:16.327031528 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:1177:gst_pipewire_src_create:<pipewiresrc0> popped buffer (nil)
0:00:16.343645445 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:568:dequeue_buffer:<pipewiresrc0> got new buffer 0x7f2240004b70
0:00:16.343651475 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:578:dequeue_buffer:<pipewiresrc0> pts 16330218000, dts_offset 0
0:00:16.343656735 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:1177:gst_pipewire_src_create:<pipewiresrc0> popped buffer 0x7f224c0050c0
0:00:16.343659915 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:480:buffer_recycle:<pipewiresrc0> recycle buffer 0x7f2240008ed0
0:00:16.343665115 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:1222:gst_pipewire_src_create:<pipewiresrc0> pts 16330218000, dts 16330218000, base-time 8:07:02.500927324 -> 0:00:00.000000000, 0:00:00.000000000
```
whereas buffers coming from a cloned last buffer due to the keepalive timeout triggering have an actually working monotonously increasing clock, equal to the pipeline's `running_time`:
```
0:00:18.170920108 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:1177:gst_pipewire_src_create:<pipewiresrc0> popped buffer (nil)
0:00:18.670998960 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:1172:gst_pipewire_src_create:<pipewiresrc0> timeout, send keepalive buffer
0:00:18.671029180 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:1222:gst_pipewire_src_create:<pipewiresrc0> pts 18119571430, dts 18119571430, base-time 8:07:02.500927324 -> 0:00:18.650208762, 0:00:18.650208762
0:00:18.700762726 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:1177:gst_pipewire_src_create:<pipewiresrc0> popped buffer (nil)
0:00:19.200853848 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:1172:gst_pipewire_src_create:<pipewiresrc0> timeout, send keepalive buffer
0:00:19.200881898 24888 0x7f2248000b70 LOG pipewiresrc gstpipewiresrc.c:1222:gst_pipewire_src_create:<pipewiresrc0> pts 18650208762, dts 18650208762, base-time 8:07:02.500927324 -> 0:00:19.180062900, 0:00:19.180062900
```
Here is the entire log (probably not much of additional value): [timestamps.log](/uploads/a1bbc503127c13572eae11c4176d4765/timestamps.log)
### Expected Results:
No matter whether the frame was a copy of `last_buffer` sent out due to the keepalive timeout triggering, or whether it was a fresh one from pipewire/kwin, the timestamps should be monotonous. And since this is a live pipeline, they should be the pipeline's `running_time`.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3148Upgrading pipewire-audio from 0.3.67 to 0.3.68 causes unwanted sound from lap...2023-04-18T15:50:29ZDaniel ParksUpgrading pipewire-audio from 0.3.67 to 0.3.68 causes unwanted sound from laptop speakers<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): 0.3.68
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`...<!-- If you are filing this issue with a regular release please try master as it might already be fixed. -->
- PipeWire version (`pipewire --version`): 0.3.68
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Arch Linux
- Desktop Environment: sway with a bunch of gtk/gnome stuff installed
- Kernel version (`uname -r`): 6.2.10-arch1-1
## Description of Problem:
I'm using Arch Linux on a Dell Inspiron 7405 2-in-1, which has a Ryzen 7 4700U with onboard audio.
After I upgraded from 0.3.67 to 0.3.68, I started having an issue:
Often, when I plug in my headphones, sound comes from both the headphones and the laptop speaker. I can usually get the sound to come out of the headphones by fiddling with which profile is selected and re-plugging the 3.5mm jack, but I haven't been able to figure out exactly what it is I'm doing that helps.
## How Reproducible:
It always happens the first time I plug in my headphones after booting, and then it sometimes happens if I plug in my headphones again later.
### Steps to Reproduce:
1. Plug in headphones
2. Play sound
### Actual Results:
Sound comes out of both headphones and speakers.
Also, (not sure if this is relevant) I can't select an output port anymore in the output devices section of pavucontrol.
### Expected Results:
Sound comes out of only headphones.
# Additional Info (as attachments):
- `pw-dump > pw-dump.log`: [pw-dump.log](/uploads/0ba8bc988e9894fd9fa40cf9da3808cc/pw-dump.log)
- [pw-dump_67.log](/uploads/7e323dde8d2c5b3f3eed80bdc6ddb09e/pw-dump_67.log)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3147GStreamer pipewiresrc element does not seem to handle pipewire video stream r...2023-04-14T16:21:37ZMarkus EbnerGStreamer pipewiresrc element does not seem to handle pipewire video stream resolution changes- PipeWire version (`pipewire --version`):
Compiled with libpipewire 0.3.67
Linked with libpipewire 0.3.67
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):
openSUSE Tumbleweed
- Desktop Environment:
...- PipeWire version (`pipewire --version`):
Compiled with libpipewire 0.3.67
Linked with libpipewire 0.3.67
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`):
openSUSE Tumbleweed
- Desktop Environment:
KDE 5.27.4
- Kernel version (`uname -r`):
6.2.9-1-default
## Description of Problem:
When the resolution of a pipewire stream changes (e.g. screencapture of an application window), the `pipewiresrc` GStreamer element then just seems to push frame buffers with the new resolution into the pipeline without doing a caps re-negotiation first. This makes the pipeline crash and/or hang.
### Steps to Reproduce:
By whatever means (I wrote a small application), start a screencast for an application window and insert the first stream's nodeId into the following pipeline:
```
GST_DEBUG=3 gst-launch-1.0 -e pipewiresrc client-name=<%APPLICATION_NAME%> path=<%NODE_ID%> ! \
videoscale ! videorate ! video/x-raw,framerate=25/1,width=1280,height=720 ! videoconvert ! \
queue ! x264enc threads=8 tune=zerolatency speed-preset=2 ! video/x-h264,profile=high ! \
queue ! matroskamux ! queue ! filesink location=/tmp/test.mkv
```
Then, use your mouse to resize the screencasted application window.
### Actual Results:
From the moment when you started moving your mouse, you will be spammed with error messages for every single frame buffer with the `videoscale` element complaining about an incorrect resolution on the received frame buffers:
```
(gst-launch-1.0:3162): GStreamer-Video-CRITICAL **: 02:17:30.649: gst_video_frame_map_id: assertion 'info->width <= meta->width' failed
0:00:33.005092445 3162 0x7fef1c0010d0 WARN videofilter gstvideofilter.c:296:gst_video_filter_transform:<videoscale0> warning: invalid video buffer received
WARNING: from element /GstPipeline:pipeline0/GstVideoScale:videoscale0: Internal GStreamer error: code not implemented. Please file a bug at https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/new.
Additional debug info:
../gst-libs/gst/video/gstvideofilter.c(296): gst_video_filter_transform (): /GstPipeline:pipeline0/GstVideoScale:videoscale0:
invalid video buffer received
```
### Expected Results:
I'm not too familiar with the GStreamer internals with respect to caps negotiation, but I think that a re-negotiation should be triggered when the resolution changed.
[This part of the documentation](https://gstreamer.freedesktop.org/documentation/additional/design/negotiation.html#pushmode-negotiation) is the closest I could find to what is interesting w.r.t. this problem.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3145[Gamescope/Gamepadui] Steam Deck boot animation broke and no audio (bisected)2023-04-11T14:55:59ZMatthew Anderson[Gamescope/Gamepadui] Steam Deck boot animation broke and no audio (bisected)Immediately after upgrading pipewire on ChimeraOS I was presented with two problems:
- Steam Deck animation logo is static (first frame rendered and froze)
- No audio regardless of device profile selected in settings
I bisected to the ...Immediately after upgrading pipewire on ChimeraOS I was presented with two problems:
- Steam Deck animation logo is static (first frame rendered and froze)
- No audio regardless of device profile selected in settings
I bisected to the exact commit that causes this regression:
```
9664787cffb3eec096b257f52f7420afc6e381f6 is the first bad commit
commit 9664787cffb3eec096b257f52f7420afc6e381f6
Author: Wim Taymans <wtaymans@redhat.com>
Date: Mon Apr 3 17:00:49 2023 +0200
context: Only activate runnable nodes
Rework the runnable state calculation. It works in 2 steps now:
1. Collect all nodes linked to a driver in some way. Mark nodes that
are reachable with a non-passive link as runnable.
2, Go through all runnable nodes and set all linked nodes to the
runnable state as well, up to the driver.
Step 2 is new. Previously if there was just one runnable node, *all*
nodes would be set to runnable. With the addition of step 2, some nodes
might remain idle when they are not used.
This has the effect that virtual sinks without inputs stay idle when
the driver is otherwise running. Grouped nodes (like the RTP session)
will now also only run the linked nodes.
src/pipewire/context.c | 108 +++++++++++++++++++++
```
Downgrading to v 0.3.67 resolves the issue and I narrowed down the exact packages causing the issues.
- libpipewire-1:0.3.68-1 pipewire-1:0.3.68-1 causes the boot animation to freeze
- pipewire-audio-1:0.3.68-1 breaks the audio
Hardware: \
One X Player Mini \
CPU: Ryzen 7 5800U (APU) \
OS: ChimeraOS v42 (unstable) \
Kernel: 6.2.10 arch1-1
If you need any logs or any information I'll gladly provide them. The OS uses a modified gamescope-session from the Steam Deck and gamescope with steam embedded with the GamepadUI. Audio works on the gnome desktop when doing the tests, but the one game I played on from the desktop did not have any audio.https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3144ALSA capture position clock lags with tsched:02023-08-14T19:48:00ZP VALSA capture position clock lags with tsched:0I see a ALSA source ratematch rate increasing continuously. This occurs on current master branch (880c1b0bd60fbb5c74), but it seems to occur also e.g. in 0.3.65.
With timer-based scheduling (tsched:1) this doesn't seem to have that much...I see a ALSA source ratematch rate increasing continuously. This occurs on current master branch (880c1b0bd60fbb5c74), but it seems to occur also e.g. in 0.3.65.
With timer-based scheduling (tsched:1) this doesn't seem to have that much downstream effect, since it only results to "early wakeup" and rescheduling the timer.
With interrupt-based scheduling (tsched:0) it makes the clock.nsec position to start lagging realtime by more and more.
Record from Logitech PRO headset microphone (Bus 001 Device 003: ID 046d:0aa7 Logitech, Inc. PRO) with `pw-record ../foo.wav`:
```
$ pw-link -l
alsa_input.usb-Logitech_PRO_000000000000-00.mono-fallback:capture_MONO
|-> pw-record:input_MONO
pw-record:input_MONO
|<- alsa_input.usb-Logitech_PRO_000000000000-00.mono-fallback:capture_MONO
$ pw-top
S 29 0 0 --- --- --- --- 0 Dummy-Driver
S 30 0 0 --- --- --- --- 0 Freewheel-Driver
S 40 0 0 --- --- --- --- 0 Midi-Bridge
S 50 0 0 --- --- --- --- 0 libcamera_input.__SB_.PCI0.XHC_.RHUB.HSP3-3_1.0-0c45_6368
S 52 0 0 --- --- --- --- 0 v4l2_input.pci-0000_00_14.0-usb-0_3_1.0
S 58 0 0 --- --- --- --- 0 alsa_output.pci-0000_01_00.1.hdmi-stereo-extra3
S 59 0 0 --- --- --- --- 0 alsa_output.usb-Logitech_PRO_000000000000-00.analog-stereo
R 60 1024 48000 66,6us 1,3us 0,00 0,00 0 S16LE 1 48000 alsa_input.usb-Logitech_PRO_000000000000-00.mono-fallback
R 67 0 48000 36,1us 17,6us 0,00 0,00 0 S16LE 2 48000 + pw-record
```
In pipewire logs with tsched:1, I'm then seeing
```
[I][05229.863670] spa.alsa | [ alsa-pcm.c: 1638 spa_alsa_set_format()] hw:3 (capture): format:S16_LE access:mmap-interleaved rate:48000 channels:1 buffer frames 32768, period frames 512, periods 64, frame_size 2 headroom 512 start-delay:0 tsched:1
...
[T][05443.429164] mod.profiler | [module-profiler.: 143 flush_timeout()] 0x7f1170438010 avail 16848
[D][05443.429195] mod.protocol-native | [ connection.c: 156 connection_ensure_size()] connection 0x55e5e7f0abd0: resize buffer to 4710952 20496 4751360
[T][05443.429219] mod.protocol-native | [module-protocol-: 492 on_server_need_flush()] need flush
[T][05443.449463] spa.alsa | [ alsa-pcm.c: 2482 handle_capture()] 0x55e5e7ed57b8: early wakeup 1504 1536
[T][05443.470516] spa.alsa | [ alsa-pcm.c: 2482 handle_capture()] 0x55e5e7ed57b8: early wakeup 1488 1536
[D][05443.471502] spa.alsa | [ alsa-pcm.c: 1977 update_time()] hw:3: follower:0 match:0 rate:1,046509 bw:0,128000 thr:1024 del:1536 target:1536 err:0,000000 max:512,000000
[T][05443.491897] spa.alsa | [ alsa-pcm.c: 2482 handle_capture()] 0x55e5e7ed57b8: early wakeup 1520 1536
[T][05443.492217] spa.alsa | [ alsa-pcm.c: 2482 handle_capture()] 0x55e5e7ed57b8: early wakeup 1520 1536
[T][05443.492549] spa.alsa | [ alsa-pcm.c: 2482 handle_capture()] 0x55e5e7ed57b8: early wakeup 1520 1536
[T][05443.513282] spa.alsa | [ alsa-pcm.c: 2482 handle_capture()] 0x55e5e7ed57b8: early wakeup 1504 1536
[T][05443.534336] spa.alsa | [ alsa-pcm.c: 2482 handle_capture()] 0x55e5e7ed57b8: early wakeup 1488 1536
...
[T][05840.481569] spa.alsa | [ alsa-pcm.c: 2482 handle_capture()] 0x55e5e7ed57b8: early wakeup 1520 1536
[T][05840.500761] spa.alsa | [ alsa-pcm.c: 2482 handle_capture()] 0x55e5e7ed57b8: early wakeup 1408 1536
[T][05840.522264] spa.alsa | [ alsa-pcm.c: 2482 handle_capture()] 0x55e5e7ed57b8: early wakeup 1440 1536
[D][05840.524266] spa.alsa | [ alsa-pcm.c: 1977 update_time()] hw:3: follower:0 match:0 rate:1,132364 bw:0,128000 thr:1024 del:1536 target:1536 err:0,000000 max:512,000000
[T][05840.543109] spa.alsa | [ alsa-pcm.c: 2482 handle_capture()] 0x55e5e7ed57b8: early wakeup 1424 1536
[T][05840.545437] spa.alsa | [ alsa-pcm.c: 2482 handle_capture()] 0x55e5e7ed57b8: early wakeup 1520 1536
[T][05840.545752] spa.alsa | [ alsa-pcm.c: 2482 handle_capture()] 0x55e5e7ed57b8: early wakeup 1520 1536
[T][05840.564939] spa.alsa | [ alsa-pcm.c: 2482 handle_capture()] 0x55e5e7ed57b8: early wakeup 1456 1536
[T][05840.566598] spa.alsa | [ alsa-pcm.c: 2482 handle_capture()] 0x55e5e7ed57b8: early wakeup 1504 1536
[T][05840.567354] mod.profiler | [module-profiler.: 143 flush_timeout()] 0x7f1170438010 avail 16848
[D][05840.567384] mod.protocol-native | [ connection.c: 156 connection_ensure_size()] connection 0x55e5e7f0abd0: resize buffer to 16797032 20496 16842752
[T][05840.567411] mod.protocol-native | [module-protocol-: 492 on_server_need_flush()] need flush
[T][05840.586113] spa.alsa | [ alsa-pcm.c: 2482 handle_capture()] 0x55e5e7ed57b8: early wakeup 1440 1536
[T][05840.606948] spa.alsa | [ alsa-pcm.c: 2482 handle_capture()] 0x55e5e7ed57b8: early wakeup 1424 1536
[T][05840.609282] spa.alsa | [ alsa-pcm.c: 2482 handle_capture()] 0x55e5e7ed57b8: early wakeup 1520 1536
...
[D][08054.395432] spa.alsa | [ alsa-pcm.c: 1977 update_time()] hw:3: follower:0 match:0 rate:1,613065 bw:0,128000 thr:1024 del:1536 target:1536 err:0,000000 max:512,000000
...
```
This sort of output repeats: the rate (corr) climbs slowly upward.
With tsched:0. I added some extra debug https://gitlab.freedesktop.org/pvir/pipewire/-/tree/alsa-capture-dbg and I'm seeing this:
```
...
[I][27881.450338] spa.alsa | [ alsa-pcm.c: 1638 spa_alsa_set_format()] hw:3 (capture): format:S16_LE access:mmap-interleaved rate:48000 channels:1 buffer frames 32768, period frames 1024, periods 32, frame_size 2 headroom 0 start-delay:0 tsched:0
...
[T][28150.000522] spa.alsa | [ alsa-pcm.c: 2547 alsa_wakeup_event()] 0x56300fd54ef8: wakeup at 28151268099107 vs. next:28011918429908 tsched:0
[D][28150.000563] spa.alsa | [ alsa-pcm.c: 1986 update_time()] hw:3: follower:0 match:0 rate:3,590456 bw:0,128000 thr:1024 del:1920 target:1024 err:-512,000000 max:512,000000
[T][28150.000580] spa.alsa | [ alsa-pcm.c: 2008 update_time()] 0x56300fd54ef8: clock nsec 28011918429908 delayed:139349728534
[T][28150.000587] spa.alsa | [ alsa-pcm.c: 2531 handle_capture()] 0x56300fd54ef8: output buffer:1 frames:1024
[T][28150.022548] spa.alsa | [ alsa-pcm.c: 2547 alsa_wakeup_event()] 0x56300fd54ef8: wakeup at 28151290125619 vs. next:28011924371586 tsched:0
[T][28150.022586] spa.alsa | [ alsa-pcm.c: 2008 update_time()] 0x56300fd54ef8: clock nsec 28011924371586 delayed:139365792121
[T][28150.022603] spa.alsa | [ alsa-pcm.c: 2531 handle_capture()] 0x56300fd54ef8: output buffer:0 frames:1024
[T][28150.043553] spa.alsa | [ alsa-pcm.c: 2547 alsa_wakeup_event()] 0x56300fd54ef8: wakeup at 28151311130810 vs. next:28011930313020 tsched:0
[T][28150.043597] spa.alsa | [ alsa-pcm.c: 2008 update_time()] 0x56300fd54ef8: clock nsec 28011930313020 delayed:139380862316
[T][28150.043605] spa.alsa | [ alsa-pcm.c: 2531 handle_capture()] 0x56300fd54ef8: output buffer:1 frames:1024
[T][28150.064550] spa.alsa | [ alsa-pcm.c: 2547 alsa_wakeup_event()] 0x56300fd54ef8: wakeup at 28151332127996 vs. next:28011936254211 tsched:0
[T][28150.064591] spa.alsa | [ alsa-pcm.c: 2008 update_time()] 0x56300fd54ef8: clock nsec 28011936254211 delayed:139395915230
[T][28150.064599] spa.alsa | [ alsa-pcm.c: 2531 handle_capture()] 0x56300fd54ef8: output buffer:0 frames:1024
[T][28150.086547] spa.alsa | [ alsa-pcm.c: 2547 alsa_wakeup_event()] 0x56300fd54ef8: wakeup at 28151354125594 vs. next:28011942195158 tsched:0
[T][28150.086590] spa.alsa | [ alsa-pcm.c: 2008 update_time()] 0x56300fd54ef8: clock nsec 28011942195158 delayed:139411973549
[T][28150.086597] spa.alsa | [ alsa-pcm.c: 2531 handle_capture()] 0x56300fd54ef8: output buffer:1 frames:1024
[T][28150.107551] spa.alsa | [ alsa-pcm.c: 2547 alsa_wakeup_event()] 0x56300fd54ef8: wakeup at 28151375129851 vs. next:28011948135862 tsched:0
[T][28150.107596] spa.alsa | [ alsa-pcm.c: 2008 update_time()] 0x56300fd54ef8: clock nsec 28011948135862 delayed:139427038748
[T][28150.107603] spa.alsa | [ alsa-pcm.c: 2531 handle_capture()] 0x56300fd54ef8: output buffer:0 frames:1024
[T][28150.128548] spa.alsa | [ alsa-pcm.c: 2547 alsa_wakeup_event()] 0x56300fd54ef8: wakeup at 28151396126873 vs. next:28011954076322 tsched:0
[T][28150.128589] spa.alsa | [ alsa-pcm.c: 2008 update_time()] 0x56300fd54ef8: clock nsec 28011954076322 delayed:139442091961
[T][28150.128597] spa.alsa | [ alsa-pcm.c: 2531 handle_capture()] 0x56300fd54ef8: output buffer:1 frames:1024
...
```
The corr can become very large, and state->next_time (and hence also the clock.nsec values) now are increasingly behind the actual time of the wakeup, which then plays havoc is something (like the bluetooth backend) wants to use these clock values for something.
[pw-dump.txt](/uploads/54a1514f09068118cfb62cf4a534accc/pw-dump.txt)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3143Motu M4 - USB-sound-card (dis)connection issues, missing profiles and applica...2023-06-26T08:15:10ZXander BaatzMotu M4 - USB-sound-card (dis)connection issues, missing profiles and application hangs/freezes
- PipeWire version (`pipewire --version`): 0.3.67
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Nobara Linux 37 (Thirty Seven)
- Desktop Environment: GNOME 43.2
- Kernel version (`uname -r`): 6.2.8-200...
- PipeWire version (`pipewire --version`): 0.3.67
- Distribution and distribution version (`PRETTY_NAME` from `/etc/os-release`): Nobara Linux 37 (Thirty Seven)
- Desktop Environment: GNOME 43.2
- Kernel version (`uname -r`): 6.2.8-200.fsync.fc37.x86_64
## Description of Problem:
I've had the Motu M4 for about 6 months, and it has always been like this.
What I've tried:
- Using my old USB audio interface (Audient iD4), which works without any problems.
- Using other systems, a laptop and a desktop, both running Fedora (36 or 37). Motu M4 would still not function properly.
- Using another USB cable (e.g. USB-C to USB-C and USB-C to USB-A), using other USB ports (both 3.x and 2.0).
- Switching from wireplumber to pipewire-media-session, changes nothing.
- Following the advice on https://github.com/kiosion/alsa-motu-m2, I've tried to downgrade kernel and alsa packages to no avail.
- Adding my user to the audio group. Doesn't fix the issue.
- Locking the sample-rate and buffer size (among other things) through wireplumber's and PipeWire's configs. No difference.
- Using boot quirks for snd-usb-audio under `/etc/modprobe.d/`. Still no difference.
- Updating the firmware using Motu's official firmware updater on a Windows machine. Still did not change anything.
Upon a shutdown/reboot of my computer I have to power-cycle the interface (physically) for it to enter a working state, however there may be an excessive amount of xruns (sometimes in the thousands).
I'm using GNOME 43.2, and in audio settings it either says `Dummy Output/Input` or just completely greyed out.
Applications that are trying to utilize the audio server in this state may crash (such as Firefox, e.g. when playing a YouTube video, where even the video won't play).
When in this state only the `Off` and `Pro Audio` profile is available for the M4 in pavucontrol under the Configuration tab.
Above mentioned state happens after a computer boot-up before having turned off and on the M4 USB Interface. During this state the interface appears fully working when looking at the meters.
The audio interface would stop working at random times, usually as a result of changes in the audio server while doing tasks such as gaming and audio editing.
A program like Ardour will hang when closing the application, where I have to kill the process for it to close OR power-cycle my interface, where Ardour closes normally as soon as the interface is turned off.
The same thing will happen when trying to restart the pipewire service, it'll then hang until the interface is power-cycled, just like Ardour.
Upon boots, in its non-working state, I have to wait around 20-30 seconds before the computer will register my mouse and keyboard inputs, which halts my ability to log in that time. Physically turning off the interface fixes the issue, "unlocking" mouse and keyboard again.
In its working state there are more profiles available, like `HiFi` and `Direct`. Hi-Fi is the one I prefer, as the others seem to put me into the non-working state.
Changing sample-rate may put the M4 into the non-working state. From my limited testing and experimenting, I've found that it's most stable at 48000 Hz (the default for M4 on Windows is 48000 Hz at a 256 buffer size).
Alsa is always able to detect the interface, no matter if it's in the working state or not. However `aplay -l` will say `Subdevices: 1/1` in the non-working state and `Subdevices: 0/1` in the working state.
Below I've attached text files with outputs from:
- `aplay -lL`
- `pactl list cards`
- `pactl list sinks`
- `sudo fuser -v /dev/snd/*`
- `systemctl --user status pipewire pipewire-media-session pipewire-pulse wireplumber`
- `pw-dump`
in both the working and not-working state.
Similar issue from other people (links):
- https://github.com/kiosion/alsa-motu-m2/issues/3
- https://linuxmusicians.com/viewtopic.php?t=20936&start=30
## How Reproducible:
...
### Steps to Reproduce:
Below I've listed different methods on how to reproduce the issue, putting the interface into the non-working state:
- Booting, rebooting, and logging out.
- Switching audio profiles (e.g. through pavucontrol).
- Throwing many different audio-dependent applications at it simultaneously, like Ardour, Firefox, EasyEffects, video games, Discord.
### Actual Results:
Motu M4 is in a limited state on boots and reboots, additionally it can cause applications to hang at random times.
### Expected Results:
The Motu M4 working as expected, able to utilize all profiles and handle a diverse range of audio tasks without crashing/hanging applications that use it.
# Additional Info (as attachments):
Not-working state:
- [alsa-info-not-working](/uploads/bac0f27dc86f299732c6e1106ab6e561/alsa-info-not-working)
- [aplay-lL-not-working](/uploads/08820e54ccc33a1bb86800b6b2fba38f/aplay-lL-not-working)
- [pactl-list-cards-not-working](/uploads/8ec6b356556e21787519d5a871b3b9c1/pactl-list-cards-not-working)
- [pactl-list-sinks-not-working](/uploads/5596b4d918582df58f86d87c4390a103/pactl-list-sinks-not-working)
- [pw-dump-not-working.log](/uploads/4405a4d51e1ef2aa296e4e1042cf2d67/pw-dump-not-working.log)
- [sudo-fuser-v-not-working](/uploads/d691a4d09aef4dc6f55b4125ff698cc5/sudo-fuser-v-not-working)
- [systemctl-user-status-not-working](/uploads/841f99458a82545bf2e7d3efdc36f9b6/systemctl-user-status-not-working)
Working state:
- [aplay-lL](/uploads/29eaba361e26f04babf97949ca10d0f8/aplay-lL)
- [pactl-list-cards](/uploads/f00c1daa8d54454042781f42aa698a3f/pactl-list-cards)
- [pactl-list-sinks](/uploads/8bc46f7fdb69817905081883a0d853aa/pactl-list-sinks)
- [pw-dump.log](/uploads/e033323c8dbd21a689312ee9dcdf0be0/pw-dump.log)
- [sudo-fuser-v](/uploads/1adee780116870575fb88cefaa943da9/sudo-fuser-v)
- [systemctl-user-status](/uploads/73e7eb871edcf61a79265fc3dc1941ea/systemctl-user-status)https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3142Questions about filter chains2023-04-07T02:39:18ZVjacheslav GaevskihQuestions about filter chainsHello. I'm trying to make somewhat complicated filter chain (or two). But I can't find enough information about this process. So, here is my questions.
1. What is a good place for chains configuration? Right now I copied default pipewir...Hello. I'm trying to make somewhat complicated filter chain (or two). But I can't find enough information about this process. So, here is my questions.
1. What is a good place for chains configuration? Right now I copied default pipewire.conf file to .config/pipewire directory and edited it there. I added virtual surround sink for testing, and it's working. However I don't think I should use entire pipewire config file only for filter chains. I suppose I should make separate file for each filter chain in .config/pipewire/pipewire.conf.d/, right?
2. What I want to make is filter chain for my mic, that will use noise supression + echo cancellation. And for output use surround filter chain, that I already configured. For the echo cancel I want to use pipewires echo-cancel module, but it is configured separately, and I don't understand how to connect it with other filter chains
3. And lastly I want to have a way to switch from surround sink to standard stereo hdmi sink, without breaking echo cancellationhttps://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3141Support Antlion ModMic Wireless aptx-ll2023-04-19T16:01:28ZMassimo BSupport Antlion ModMic Wireless aptx-llFirst discussed here: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/972#note_1031490
https://antlionaudio.com/collections/microphones/products/modmic-wireless
**Background:**
This device is special. Even though adding suppo...First discussed here: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/972#note_1031490
https://antlionaudio.com/collections/microphones/products/modmic-wireless
**Background:**
This device is special. Even though adding support for just a single rare device could be some effort not worth the few users, BUT: This device is so special, there are no alternative devices on the market. I was long time looking for a high quality wireless mic. I also use the USB wired version in some setups, great voice quality.
I was thinking about purchasing the Avantree devices from the other thread, their aptx-LL should be a great improvement for the microphone back channel. But as with the wired modmic, this ModMic wireless makes it possible to use whatever headphone, combined with the best microphone performance.
Finally it would be great to run both, the headphone and the ModMic with the same internal BT receiver. Yes, and the BT mouse. Could saturate the max bandwidth, not sure. Some people already had issues when running a LDAC headphone together with a mouse...
I purchased one and like to help adding support for it.
Using the dedicated USB receiver it already works great, just another USB audio device. But on the laptop I would like to avoid the additional receiver and use the internal one which supports BT 5.2
As according to their [FAQ](https://antlionaudio.com/pages/faq) it should be able to connect the ModMic with any aptx-LL receiver, I did not succeed with any receiver yet, probably just not supported using some A2DP profile with a microphone-only, just guessing.
Currently I'm not able to pair at all. Holding the button for 5 secs it gets to pairing mode, possible to pair with its receiver, but not visible from the blueman-manager. Maybe it's unnamed. I see some unnamed Hifi device, but can't pair.
We could get some support from the manufacturer if pipewire dev is interested to implement.