francolargo <francolargo@xxxxxx> wrote:
> Curiosity got the better of me and I ran a couple more tests.
>
> Conclusions:
> 1) "-t alsa hw:0,0" works fine for 4 channel output - no ALSA plug needed
> (though it doesn't hurt).
> 2) Adding 'delay' to each process seems seamless. How much delay?
> Increments of 8192 samples sound darn close... Note that very little
> competition for CPU is anticipated because the Beaglebone Black is a
> dedicated music player.
>
> Question: How would one precisely find the size of the delay added by each
> of the first 3 SoX filter processes?
The default pipe size is 65536 in the Linux kernel and
current versions of sox do not change that, so you could
use
I'm also unsure of the overhead in the .sox ('-p') data stream.
When I care about delay from the pipe,
I use something like FMT='-t s32 -c2 -r48000'
and use $FMT (no quotes) where you would use '-p' to avoid the
metadata overhead.
However, you may not need to care about delay...
> What is playing now:
>
> chrt -f 45 sox -M \
> '| sox -t alsa dsnoop:1,0 -p remix 1v1 ladspa ACDf 22 1 0 640 0.707 0 0
> delay 24576s' \
> '| sox -t alsa dsnoop:1,0 -p remix 1v1 ladspa ACDf 21 1 0 640 0.707 0 0
> delay 16384s' \
> '| sox -t alsa dsnoop:1,0 -p remix 2v1 ladspa ACDf 22 1 0 640 0.707 0 0
> delay 8192s' \
> '| sox -t alsa dsnoop:1,0 -p remix 2v1 ladspa ACDf 21 1 0 640 0.707 0 0' \
> -t alsa hw:0,0
Am I correct dsnoop acts like a UDP multicast channel?
(and you have 4 subscribers in the above case)
If so, perhaps try an expanded version with using the extra FIFO
in my response to Erich. I had two channels, and one extra FIFO
for the previous example. With 4 channels, it would require 3
intermediate FIFOs for a total of seven FIFOs.
The following probably works for you:
#!/bin/sh
mkfifo llo.sox
mkfifo rlo.sox
mkfifo lhi.sox
mkfifo rhi.sox
mkfifo split1.fifo
mkfifo split2.fifo
mkfifo split3.fifo
# One dsnoop subscriber feeds multiple pipes:
(sox -t alsa dsnoop:1,0 -p | tee split1.fifo | cat >llo.sox) &
# Notice a pattern? You could add more FIFOs into this chain :)
(tee <split1.fifo split2.fifo | cat >lhi.sox) &
(tee <split2.fifo split3.fifo | cat >rlo.sox) &
# "sox -M" actually reads from this, first
(cat <split3.fifo >rhi.sox) &
# You shouldn't have to worry about synchronization/delays here,
# either. "sox -M" will block on reading (which is why we
# used so many background processes above) and they're all
# fed from the common "sox -t alsa dsnoop:1,0 -p" process
sox -M \
"|sox llo.sox -p remix 1v1 ladspa ACDf 22 1 0 640 0.707 0 0" \
"|sox lhi.sox -p remix 1v1 ladspa ACDf 21 1 0 640 0.707 0 0" \
"|sox rlo.sox -p remix 2v1 ladspa ACDf 22 1 0 640 0.707 0 0" \
"|sox rhi.sox -p remix 2v1 ladspa ACDf 21 1 0 640 0.707 0 0" \
-t alsa hw:0,0
wait # for backgrounded processes to exit
--
EW
------------------------------------------------------------------------------
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
