alsa-project/alsa-lib issue #14 was opened from bharris6:
When using the [ALSA File plugin](https://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html) you can tell it to pipe playback data to either a file or a program/shell command.
Output filename (or shell command the stream will be piped to if STR starts with the pipe char).
Piping to a shell command (as shown below) causes a deadlock where alsa waits for the shell command to return at the same time that the shell command is waiting for alsa to write to its STDIN.
From the [source code](https://github.com/alsa-project/alsa-lib/blob/master/src/pcm/pcm_file.c), it appears that [popen](https://pubs.opengroup.org/onlinepubs/009695399/functions/popen.html) is being used to initialize/open the output file specified in configuration:
static int snd_pcm_file_open_output_file(snd_pcm_file_t *file) { int err, fd;
/* fname can contain keys, generating final_fname */ err = snd_pcm_file_replace_fname(file, &(file->final_fname)); if (err < 0) return err; /*printf("DEBUG - original fname: %s, final fname: %s\n", file->fname, file->final_fname);*/
if (file->final_fname[0] == '|') { /* pipe mode */ FILE *pipe; /* clearing */ pipe = popen(file->final_fname + 1, "w"); if (!pipe) { SYSERR("running %s for writing failed", file->final_fname); return -errno; } fd = dup(fileno(pipe)); err = -errno; pclose(pipe); if (fd < 0) { SYSERR("unable to dup pipe file handle for command %s", file->final_fname); return err;
Although I can confirm the file I pass in my ALSA configuration gets started fine, it never receives anything on its `stdin` like ALSA's (and popen's) documentation states it should:
If mode is w, *when the child process is started its file descriptor STDIN_FILENO shall be the readable end of the pipe*, and the file descriptor fileno(stream) in the calling process, where stream is the stream pointer returned by popen(), shall be the writable end of the pipe.
My /etc/asound.conf:
pcm.!default { type plug slave.pcm "duplicator }
pcm.default { type plug slave.pcm "duplicator" }
pcm.dmixer { type dmix ipc_key 1024 ipc_key_add_uid false ipc_perm 0666 slave { pcm "hw:0,0" period_time 0 period_size 1024 buffer_size 8192 rate 44100 } }
pcm.duplicator { type plug slave.pcm { type multi slave { a { pcm "dmixer" channels 2 } b { pcm "fileout" channels 2 } } bindings [ { slave a channel 0 } { slave a channel 1 } { slave b channel 0 } { slave b channel 1 } ] } ttable [ [ 1 0 1 0 ] [ 0 1 0 1 ] ] }
pcm.fileout { type file slave.pcm "null" file "|safe_fifo_alt" format raw perm 0666 }
safe_fifo_alt:
#!/usr/bin/python3 import os, sys
BUFFER_SIZE = 16384
path = "/tmp/audio" if not os.path.exists(path): os.mkfifo(path)
_fifo_in = os.open(path, os.O_RDONLY | os.O_NONBLOCK) _fifo_out = os.open(path, os.WR_ONLY | os.O_NONBLOCK)
for chunk in iter(lambda: sys.stdin.buffer.read(BUFFER_SIZE), b''): os.write(_fifo_out, chunk)
os.close(_fifo_in) os.close(_fifo_out)
I based `safe_fifo_alt` on [safe_fifo](https://github.com/dpayne/cli-visualizer/blob/master/bin/safe_fifo.c) from `cli-visualizer`. They both hang indefinitely on their STDIN read because alsa is hanging on its `pclose()`.
I've tested an alternative method to simulate the popen and pipe into their STDIN to make sure it worked, specifically:
head -c 500 /dev/urandom | sh -c safe_fifo_alt
It appears this was changed in revision 022c790aabc300eabad4da8947a3f2bdadce41e1, where the `dup()` and `pclose()` calls were added and introduced the deadlock.
Issue URL : https://github.com/alsa-project/alsa-lib/issues/14 Repository URL: https://github.com/alsa-project/alsa-lib