Delays and "too many open files" errors when playing multiple sounds with sox
- PipeWire version (
pipewire --version
): 0.3.48 - Distribution and distribution version (
PRETTY_NAME
from/etc/os-release
): Debian testing - Desktop Environment: XFCE
- Kernel version (
uname -r
):5.16.0-3-amd64
Description of Problem:
When multiple sox processes are launched (using the python subprocess module) to play multiple samples or synth notes simultaneously and in rapid succession, many of the sounds do not play when the sox process is launched, but instead are played several seconds later or not at all. This is accompanied by high memory use. The following errors typically appear in systemctl --user status pipewire-pulse.service:
Mar 14 16:34:45 e7240 pipewire-pulse[174646]: mod.adapter: usage: node.name=<string>
Mar 14 16:34:45 e7240 pipewire-pulse[174646]: pw.resource: usage: node.name=<string>
Mar 14 16:34:45 e7240 pipewire-pulse[174646]: pw.stream: 0x5649119edeb0: can't make node: Invalid argument
Mar 14 16:34:45 e7240 pipewire-pulse[174646]: pw.mem: 0x564910af5790: Failed to create memfd: Too many open files
Mar 14 16:34:45 e7240 pipewire-pulse[174646]: pw.stream: 0x564924b70750: can't make node: Too many open files
Mar 14 16:34:45 e7240 pipewire-pulse[174646]: pw.mem: 0x564910af5790: Failed to create memfd: Too many open files
Mar 14 16:34:45 e7240 pipewire-pulse[174646]: pw.stream: 0x564913ebdae0: can't make node: Too many open files
Mar 14 16:34:45 e7240 pipewire-pulse[174646]: pw.mem: 0x564910af5790: Failed to create memfd: Too many open files
Mar 14 16:34:45 e7240 pipewire-pulse[174646]: pw.stream: 0x564912ba25d0: can't make node: Too many open files
Mar 14 16:34:45 e7240 pipewire-pulse[174646]: mod.client-node: link 0x5649267f64c0: write failed Bad file descriptor
...
Mar 14 17:23:45 e7240 pipewire-pulse[174646]: mod.protocol-pulse: server 0x564910b05e60: failed to create client: Connection refused
Mar 14 17:23:45 e7240 pipewire-pulse[174646]: mod.protocol-pulse: server 0x564910b05e60: failed to create client: Connection refused
Occasionally this error also appears in dmesg:
[241285.570440] wireplumber[167574]: segfault at 68 ip 00007f4b5372aa70 sp 00007ffe99878308 error 4 in libpipewire-0.3.so.0.348.0[7f4b536d6000+69000]
[241285.570460] Code: 66 2e 0f 1f 84 00 00 00 00 00 48 8b 47 70 c3 66 66 2e 0f 1f 84 00 00 00 00 00 48 8b 47 60 c3 66 66 2e 0f 1f 84 00 00 00 00 00 <48> 8b 47 68 c3 66 66 2e 0f 1f 84 00 00 00 00 00 41 54 55 48 89 fd
Sox itself also gives the following errors multiple times:
play WARN alsa: can't encode 0-bit Unknown or not applicable
play FAIL formats: can't open output file `default': can not open audio device: Timeout
When these errors occur, the process monitor (XFCE Task manager) shows multiple residual sox processes in 'S' state. If too many samples are attempted to be played, system memory runs out.
The pavucontrol "Playback" tab shows many sox application streams, one for each sample. Many of these remain after the program playing the samples has exited, and do not disappear until pipewire is restarted.
If -t alsa
is passed to sox to make it use the alsa device (Linux only) rather than the pulseaudio default, the issue is less severe (i.e, more samples must be played in rapid succession to trigger it), but still appears.
This used to work without problems with pulseaudio.
(BTW I am otherwise very impressed with pipewire, it solves many long-standing Linux audio issues and works well)
How Reproducible:
100% on my system if the python snippet below is run. Less demanding code (e.g, fewer simultaneous samples or less frequently run) may not trigger the issue.
Steps to Reproduce:
- Run this python 3.9 snippet using a path to an audio file playable by sox:
import subprocess, time
for __ in range(32):
for _ in range(4):
subprocess.Popen(['play', '-q', '/path/to/audio_file'])
time.sleep(.2)
The issue also appears if sox synth is used, e.g. by passing ['play', '-q', '-n', 'synth', '1', 'sine', '220']
to Popen instead.
Actual Results:
Sounds are initially played correctly at the scheduled time but become increasingly delayed, with errors and high memory use as set out above, until they do not play at all.
Expected Results:
Sounds should play as soon as the sox process is launched.
Additional Info (as attachments):
-
pw-dump > pw-dump.log
:pw_dump