Recent changes to bugs

#382 parallel stats performance scales poorly

2026-02-23T09:21:06.480000Z

In Debian testing, yes.
sox_ng has --multi-threaded enabled by default which usually completes sooner at a cost of more total CPU time due to more inter-process communication. Sorry this has caused breakage; maybe
it should go back to --single-threaded by default to avoid such scenarios.

#382 parallel stats performance scales poorly

2026-02-22T23:36:26.829000Z

Oops, apparently Debian switched from sox to sox_ng and I didn't realize it. I filed this at https://codeberg.org/sox_ng/sox_ng/issues/826 so this issue can be closed.

#382 parallel stats performance scales poorly

2026-02-22T23:08:39.260000Z

I just tested on another computer I have access to. It's an AMD 5600G running Debian trixie, sox 14.4.2+git20190427-5+b3 and linux 6.12.63+deb13-amd64. On that system, running in parallel is actually faster than in series, which is what I'd normally expect:

$ time (for x in {1..3}; do sox silence.wav -n stats -b 16 & done; wait)
[...]

real    0m0.040s
user    0m0.114s
sys     0m0.004s

$ time (for x in {1..3}; do sox silence.wav -n stats -b 16; done; wait)
[...]

real    0m0.118s
user    0m0.102s
sys     0m0.016s

parallel stats performance scales poorly

2026-02-22T23:00:33.475000Z

The program that I use to rip CDs performs really poorly when I rip a handful of CDs at the same time, and it looks like sox is the bottleneck. To isolate the bug, I first created a test file:

sox -n -b 16 -r 44100 -c 2 silence.wav trim 0 60

The sox command whipper uses ran relatively quickly when only one was running in parallel:

$ time sox silence.wav -n stats -b 16
             Overall     Left      Right
DC offset          0         0         0
Min level         -1        -1        -1
Max level          1         1         1
Pk lev dB     -90.31    -90.31    -90.31
RMS lev dB    -96.33    -96.33    -96.33
RMS Pk dB     -95.89    -95.92    -95.89
RMS Tr dB     -96.83    -96.83    -96.78
Crest factor       -      2.00      2.00
Flat factor     2.18      2.18      2.19
Pk count        661k      662k      661k
Bit-depth       2/16      2/16      2/16
Num samples    2.65M
Length s      60.000
Scale max      32767
Window s       0.050

real    0m0,067s
user    0m0,384s
sys     0m0,008s

If I run the same command 3 times in parallel, it takes 38 seconds instead of less than 1:

$ time (for x in {1..3}; do sox silence.wav -n stats -b 16 & done; wait)
[...]

real    0m38,170s
user    7m23,014s
sys     0m0,240s

And changing the command above to run in series instead of parallel, it goes back to taking a reasonable amount of time:

$ time (for x in {1..3}; do sox silence.wav -n stats -b 16; done; wait)
[...]

real    0m0,379s
user    0m4,052s
sys     0m0,024s

Assuming sox doesn't do any inter-process communication between those 3 processes, I'm not sure why running 3 in parallel should be so much slower than running them in series on a 6-core CPU with an audio file on a tmpfs filesystem.

I'm running sox 14.7.0.9+ds1-1 on linux 6.18.5+deb14-amd64 from Debian testing, with an Intel i5-11600.

From here on, I'm just guessing/speculating: Is there any chance that sox is using some CPU instructions that interact really poorly with context switching between threads/processes? I vaguely remember reading something about AVX-512 have some multi-threaded performance issues, but I'm not really familiar with it.

Missing checks for misplaced command line arguments.

2026-01-19T14:16:19.613000Z

The man page for "play" says that global command line options must come before format and effect options. If this is indeed a requirement - then there should be checks and appropriate error messages when the user gets it wrong. Many online resources for SOX don't explain this - and many examples violate the requirement and somehow still work - while others do not.

The -V0 parameter to 'play' doesn't turn off all output.

2026-01-19T14:09:31.297000Z

The -V0 option to 'play' doesn't turn off all output (Ubuntu) :

My command:

play -V0 -e signed-integer -b 16 -r 44100 -c 2 -t raw tmp.pcm

I get output:

tmp.pcm:

 File Size: 487k      Bit Rate: 1.41M
  Encoding: Signed PCM    
  Channels: 2 @ 16-bit   
Samplerate: 44100Hz      
Replaygain: off         
  Duration: 00:00:02.76

And then a ton of...

In:100%  00:00:02.76 [00:00:00.00] Out:122k  [      |      ]        Clip:0 
Done.

WIth -V -V I get:

play DBUG formats: opening format plugin `lsx_alsa_format_fn': library 0x556e4a033ab0, entry point 0x7f5102b86900

play DBUG formats: opening format plugin `lsx_amr_nb_format_fn': library 0x556e4a034d20, entry point 0x7f5102b7fab0          

play DBUG formats: opening format plugin `lsx_amr_wb_format_fn': library 0x556e4a035ac0, entry point 0x7f5102b7a760          

play DBUG formats: opening format plugin `lsx_caf_format_fn': library 0x556e4a036850, entry point 0x7f5102b74400             

play DBUG formats: opening format plugin `lsx_fap_format_fn': library 0x556e4a038f30, entry point 0x7f510265a400             

play DBUG formats: opening format plugin `lsx_flac_format_fn': library 0x556e4a039740, entry point 0x7f5102654560            

play DBUG formats: opening format plugin `lsx_gsm_format_fn': library 0x556e4a03a010, entry point 0x7f510264d790             

play DBUG formats: opening format plugin `lsx_lpc10_format_fn': library 0x556e4a03a7a0, entry point 0x7f5102648700           

play DBUG formats: opening format plugin `lsx_mat4_format_fn': library 0x556e4a03af10, entry point 0x7f5102360400            

play DBUG formats: opening format plugin `lsx_mat5_format_fn': library 0x556e4a03b810, entry point 0x7f5102359400            

play DBUG formats: opening format plugin `lsx_paf_format_fn': library 0x556e4a03c3e0, entry point 0x7f5102352400

play DBUG formats: opening format plugin `lsx_pvf_format_fn': library 0x556e4a03cbf0, entry point 0x7f510234b400

play DBUG formats: opening format plugin `lsx_sd2_format_fn': library 0x556e4a03d520, entry point 0x7f5102344400

play DBUG formats: opening format plugin `lsx_sndfile_format_fn': library 0x556e4a03dee0, entry point 0x7f510233e580

play DBUG formats: opening format plugin `lsx_vorbis_format_fn': library 0x556e4a03e6f0, entry point 0x7f5102337120

play DBUG formats: opening format plugin `lsx_w64_format_fn': library 0x556e4a03f460, entry point 0x7f510232f400

play DBUG formats: opening format plugin `lsx_wavpack_format_fn': library 0x556e4a03fc70, entry point 0x7f5102329c60

play DBUG formats: opening format plugin `lsx_xi_format_fn': library 0x556e4a0409e0, entry point 0x7f5102323400

play DBUG sox: Looking for a default device: trying format `alsa'
play WARN alsa: can't encode 0-bit Unknown or not applicable
play DBUG alsa: selecting format 1: U8 (Unsigned 8 bit)
play:      SoX v14.4.2
time:     Sep  5 2023 16:19:05
issue:    Ubuntu
uname:    Linux gnosis 5.15.0-139-generic #149~20.04.1-Ubuntu SMP Wed Apr 16 08:29:56 UTC 2025 x86_64
compiler: gcc 9.4.0
arch:     1288 48 88 L OMP

Input File     : '.tmpSndImage_SOX_742351_1.pcm' (raw)
Channels       : 2
Sample Rate    : 44100
Precision      : 16-bit
Duration       : 00:00:02.76 = 121856 samples = 207.238 CDDA sectors
File Size      : 487k
Bit Rate       : 1.41M
Sample Encoding: 16-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no

play DBUG alsa: selecting format 2: S16_LE (Signed 16 bit Little Endian)

Output File    : 'default' (alsa)
Channels       : 2
Sample Rate    : 44100
Precision      : 16-bit
Duration       : 00:00:02.76 = 121856 samples = 207.238 CDDA sectors
Sample Encoding: 16-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no

play INFO sox: effects chain: input        44100Hz  2 channels (multi) 16 bits 00:00:02.76
play INFO sox: effects chain: output       44100Hz  2 channels (multi) 16 bits 00:00:02.76
play DBUG sox: automatically entering interactive mode
play DBUG sox: start-up time = 0.008271
In:100%  00:00:02.76 [00:00:00.00] Out:122k  [      |      ]        Clip:0    
Done.

#307 Filename with Special Characters fail

2026-01-08T11:07:53.062000Z

Eight years on... You're welcome & thanks for confirming it works OK
https://codeberg.org/sox_ng/sox_ng/issues/203

#307 Filename with Special Characters fail

2026-01-06T23:15:33.217000Z

@martinwguy, that seems to have worked. Thanks very much.

#314 Incorrect work of sox_read function with In-memory output buffers

2025-12-27T10:50:04.735000Z

Hi! I've had another look at this, and the problem may be that the code calls sox_memstream_write(), writes a load of stuff into it and then calls sox_read on the same sox_format_t that was opened for writing, whereas what it should do is sox_close() the output and then read the data directly from the memory buffer pointer and length that are updated only by stdio when the file is flushed or closed.
I suspect that it "works" when using a disk file because either SoX or stdio has separate read and write pointers to the file.
I've updated https://codeberg.org/sox_ng/sox_ng/issues/241 with more details that led to this way of thinking and I suspect that the real defect is that libsox allowed you to call "read" on a descriptor opened for writing without complaining at you. And that the documentation for libsox is appallingly scarse or nonexistent.

#343 speed effect not effective using soxlib APIs

2025-12-27T10:37:49.644000Z

Hi! I've had a look at this and it seems that the reason is that "speed" changes the sample rate but the call to sox_open_write() specifies the sample rate of the output file as a copy of that of the input file.
It is sox.c, which is "just" another client of libsox, that automatically inserts effects in the chain to adapt the sample rate at the end, make the number of channels match, not libsox, which is why it works from the command line as you expected.
If you add a "rate 48000" (or whatever the sample rate of the output file is) after the "speed", you get the output you expected, or you can achieve the "speed" effect you wanted simply by multiplying or dividing signal_in.rate by the factor in question before copying it into signal_out.rate withuot any "speed" effect at all.

https://codeberg.org/sox_ng/sox_ng/issues/442