2026-05-15 00:40:37 veltas, I wonder how does one tell which speaker is right and which is left if they are unmarked 2026-05-15 07:10:35 Stalevar: They used to have this audio test that would say 'left' 'right' in both channels, don't know if they have that still 2026-05-15 07:23:58 I just mute one channel, then another, to find out. 2026-05-15 07:31:00 Well, I suppose $ sox -q -n -t .sw -c 2 -r 48000 - synth sine remix 1 0 | jack-stdin -q -- system:playback_1 system:playback_2 ; , and then with remix 0 1 , works as well. 2026-05-15 08:22:32 Jack doesn't exist. Is aplay better? 2026-05-15 14:27:23 Stalevar: aplay should work as long as it's using stereo 2026-05-15 15:45:51 Assuming "aplay" is for ALSA, note that sox(1) /does/ have ALSA support (unless disabled at compile time, and provided the entire package is installed; the respective module is in libsox-fmt-alsa in Debian, for instance.) So, e. g.: $ sox -q -n -t alsa -r 48000 hw:0 synth sine remix 1 0 (further assuming hw:0 is the desired ALSA output device.) 2026-05-15 16:27:58 Debian's sox package also installs a `play` command 2026-05-15 16:30:28 so `play -t alsa hw:0 synth sine remix 1 0` works too 2026-05-15 16:30:55 or `... 0 1` for the right channel 2026-05-15 16:37:28 Unless I be mistaken, the play invocation above will try to use "-t alsa hw:0" as /input/ audio stream. Note that my sox(1) command uses "-n" - "null input." 2026-05-15 16:42:47 that's true if you invoke it as `sox` but not if you invoke it as `play` 2026-05-15 16:43:00 `play -t alsa hw:0 synth 1 triangle 20-1000 remix 0 1` is maybe more fun 2026-05-15 16:53:50 actually at least on my box I can `play -d` instead of `play -t alsa hw:0` 2026-05-15 16:54:26 so `play -d synth 1 triangle 20-1000 remix 0 1 : synth 1 triangle 1000-20 remix 1 0` first plays a rising tone in the right ear and then a falling tone in the left ear 2026-05-15 17:15:44 The way I read sox(1), "$ sox (source) -d (effects) " is more or less the same as "$ play (source) (effects) " - "play" is "sox" with -d as output, and, similarly, "rec" is "sox" with -d as input. I've used play(1) earlier this day on another machine - as "$ play audiofile ", without specifying any output, but on this box it fails because the audio device is already taken - by jackd. 2026-05-15 17:15:44 It is of course possible to use "$ sox -d -d (effects) " - or, equivalently, "$ play -d (effects) " or "$ rec -d (effects) ", but given that whatever audio stream obtained from "-d" input device gets written over by the "synth" effect in the examples above, it feels wasteful. (And might fail depending on the audio device permissions.) So I use "-n" instead. 2026-05-15 17:17:47 I wonder if sox can be persuaded to talk to jack without piping to jack-stdin or similar 2026-05-15 17:19:51 you are absolutely correct that I should use `-n` instead of `-d`. I was confused about what was happening! Thank you for explaining 2026-05-15 17:35:50 Sox "-t alsa" support module relies on libasound, which in turn has a JACK client module. Its use can be configured via ~/.asoundrc , like: pcm.jack { type jack playback_ports { 0 system:playback_1 1 system:playback_2 } } . Some ALSA operations seem to require operations not provided by "type jack" (?), so for better support you'd also have: pcm.jackplug { type plug slave { pcm "jack" } } . 2026-05-15 17:37:43 I. e., device "jack" uses the ALSA JACK client directly, while device "jackplug" add some sort of ALSA compatibility layer on top of it. 2026-05-15 17:39:16 hahaha 2026-05-15 17:40:53 At least I've had issues with /some/ applications being unable to use AUDIODEV=jack , but willing to use AUDIODEV=jackplug instead. 2026-05-15 17:46:05 we're running ALSA on top of JACK on top of ALSA 2026-05-15 17:50:50 That's only because "ALSA" is a term that lumps several components together that can in fact be used separately. In this case, we're running libasound + its add-ons (part of "ALSA") on top of JACK on top of a kernel /dev/snd/ device (also "ALSA".) 2026-05-15 17:59:26 well, it's sort of like layering in networking 2026-05-15 18:00:06 you can run TCP on top of IP on top of SLIP on top of SSH on top of TCP on top of IP on top of Wireguard on top of UDP on top of IP on top of ... 2026-05-15 18:00:59 it's not always even a bad idea, just kind of funny 2026-05-15 18:07:51 "TCP/IP" is a tad similar in that a lot of important applications use both, to the point that "network address and port" commonly refers to a combination of IP address and TCP port - not unlike how "ALSA" device refers to something libasound understands, and often enough corresponds to a /dev/snd/ kernel device. 2026-05-15 18:07:51 ISTR, however, that some applications I've used (or tried to use) used "ALSA" kernel devices, seemingly directly, and paid no attention to ~/.asoundrc and (or?) AUDIODEV . 2026-05-15 18:08:01 you dawg, I heard you like protocols