UPDATE: It’s fixed. The problem was I misunderstood the protocol. Instead of --mic-uri, which is for Wyoming protocol, I need to use --mic-command and netcat.
Brilliant, thank you! Now it’s working:
- My USB mic (
Blue Snowball) is active all the time. - It’s connected to
VoiceMeeter Banana - In VM/Banana there are two logical outputs, B1 goes to zoom/meet/whatever voice input, B2 is available
- I run
ffmpegto stream raw audio from VM/Banana’s B2 via TCP:
ffmpeg -f dshow -i audio="VoiceMeeter Aux Output (VB-Audio VoiceMeeter AUX VAIO)" -ar 16000 -ac 1 -f s16le -acodec pcm_s16le -listen 1 -max_delay 0 -listen 1 tcp://0.0.0.0:10600
- on the receiving end, as advised, I changed to:
script/run --name "test-satellite" --uri "tcp://0.0.0.0:10700" --mic-command "nc 192.168.11.30 10600" --snd-command "aplay -r 22050 -t raw" --debug
and it all works now!
Now I must figure out the best way of playing back the response (on windows or not)…
Original message:
So, with this new Wyoming-satellite it looks like mic/snd is decoupled from the satellite proper.
I have an always-on mic on my windows box, connected to VoiceMeeter.
I’m running ffmpeg in win10 so that it can use DirectShow to capture audio:
I can connect to it (nc 192.168.11.30 10600 > snd.raw) and can verify that ffmpeg is streaming properly.
However, when I call the script:
script/run --name "test-satellite" --uri "tcp://0.0.0.0:10700" --mic-uri "tcp://192.168.11.30:10600" --snd-command "aplay -r 22050 -t raw" --debug
I get errors:
Any idea what isn’t to its liking?