Erich Eckner <erich@xxxxxxxxxx> wrote: > Hi Frank, > > i think, sox can't duplicate audio without "buffering" in a file. > However, (in linux) there are other commands, which can copy the data, > e.g. "tee". > I think fiddling around with named pipes and tee, you should be able to > do the trick: > > mkfifo sound > mkfifo sound_copy > sox -M "|sox sound -p remix 1 $left_channel_effects" "|sox sound_copy -p > remix 2 $right_channel_effects" $output $effects_to_both > > and then in a separate terminal/thread: > > sox $stereo_input -p | tee sound > sound_copy > > Hmm, I just tried it and it doesn't work, also > > sox $stereo_input -p | tee sound sound_copy > /dev/null > > as second command doesn't work. Probably some buffering issue (feeding > the pipes from two separate sox commands works)? > Maybe someone else knows how to make this idea work? The annoying thing about FIFOs is opening them for either reading or writing blocks the process until the other end also opens for reading or writing. So whenever you do "tee FIFO1 >FIFO2" or "tee FIFO1 FIFO2", you're generally screwed :) At the very least, you would need "tee FIFO1 | cat >FIFO2" to open in parallel. On Linux, you can "strace -p $PID" and watch processes get stuck like this. But reading is still order-dependent on the "sox -M" process when writing two FIFOs like that, and tee does not write in parallel. I create an intermediate split.fifo to workaround this problem: #!/bin/sh INPUT=/my/favorite/song.flac # in stereo :) mkfifo l.sox mkfifo r.sox mkfifo split.fifo # the key intermediate buffer (sox $INPUT -p | tee split.fifo | cat >l.sox) & (cat split.fifo >r.sox) & # The above ensures r.sox and l.sox are opened in # parallel and also get written to in parallel; # something tee alone cannot do. # This means the read end can go about doing its thing: sox -M "|sox l.sox -p remix 1" "|sox r.sox -p remix 2" -p | play -p --- In contrast, the following is order-dependent, since 'sox -M" will read from the r.sox process before the l.sox one. #!/bin/sh INPUT=/my/favorite/song.flac mkfifo l.sox mkfifo r.sox # The order in the pipeline when we write to FIFOs matters. # (sox $INPUT -p | tee l.sox | cat >r.sox) & # broken! (sox $INPUT -p | tee r.sox | cat >l.sox) & # works! # With strace, I saw "sox -M" tried reading from the # second (r.sox) process before reading from the l.sox process. # Which is why the "tee" above writes to r.sox, first: sox -M "|sox l.sox -p remix 1" "|sox r.sox -p remix 2" -p | play -p --- But yeah, the ordering-dependency makes it non-intuitive. ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape _______________________________________________ Sox-users mailing list Sox-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/sox-users
