sox-users Mailing List for SoX - Sound eXchange

On Wed, Apr 01, 2026 at 11:01:46AM +0200, Martin Guy wrote:
> On 3/30/26 4:43 PM, Doug Lee wrote:
> > I am wondering if it would make sense, and how difficult it would be, to make it possible to run sox_ng As a filter node in the Pipe wire graph
> 
> I haven't programmed for pipewire and am now in maintenance mode, not
> development mode.
> 
> The idea seems excellent, so if anyone wants to try it out...
> 
> There is something similar on the branch "jack" which makes SoX appear as JACK
> units in *its* graph. There are basically two ways to do it, and the one in
> branch "jack" creates a new node each time you use "-t jack" for an input or
> output file, so you get a unit with one input or one output for each jacked
> stream (basically because that was easier!)
> The other way would be for SoX to appear a a single unit with one or more
> inputs and outputs - the first solution is essentially sox-as-jack-client and
> the second jack-as-SoX-client. I assume a pipewire version of the same thing
> would present a similar choice.
> 
>     M

I'm not a developer for either sox_ng or Pipewire at this time, but my
understanding is this:

For direct Pipewire connection, you'd probably want "-t pipewire" to
take a node.serial or node.name property value by which to match an
existing node. This is a different idea than what I proposed but is
probably both more universally understandable and more universally
useful. :)

Example:
sox -t pipewire 35 -t pipewire "alsa_output.usb-ZOOM_Corporation_H1essential_000000000000-00.analog-stereo" speexdsp

would send object.serial 35's audio (all channels) to the object with
the given node.name. This just cuts out the pw-record at the start and
pw-play at the end of the pipe that is otherwise necessary now. The
number of ports (channels) on each of those two nodes is governed by
whatever created them, which is not sox_ng.

My proposal, though, was about Pipewire filter nodes. For those, sox_ng
becomes the process that does the audio processing for the node, and the
node has input ports and output ports for the channels being processed.
I don't yet know the specifics of how this is implemented, except that
Pipewire 1.6.2 (currently default in Ubuntu Resolute Raccoon which comes
out of beta this month) uses json to configure such nodes while older
Pipewires use lua.

Use of this approach in practice would involve creating a filter node,
then routing audio through it with pw-link, pw-loopback, etc., or with
Pipewire lib calls I'm sure.



-- 
Doug Lee                 dg...@dl...                http://www.dlee.org
"Maturity is knowing that the world owes you nothing. Freedom is knowing you owe it the same. Character is how
you respond to the knowing." --Jack Kincaid

On 3/30/26 4:43 PM, Doug Lee wrote:
> I am wondering if it would make sense, and how difficult it would be, to make it possible to run sox_ng As a filter node in the Pipe wire graph

I haven't programmed for pipewire and am now in maintenance mode, not 
development mode.

The idea seems excellent, so if anyone wants to try it out...

There is something similar on the branch "jack" which makes SoX appear 
as JACK units in *its* graph. There are basically two ways to do it, and 
the one in branch "jack" creates a new node each time you use "-t jack" 
for an input or output file, so you get a unit with one input or one 
output for each jacked stream (basically because that was easier!)
The other way would be for SoX to appear a a single unit with one or 
more inputs and outputs - the first solution is essentially 
sox-as-jack-client and the second jack-as-SoX-client. I assume a 
pipewire version of the same thing would present a similar choice.

     M

Please pardon me if this seems like a truly wild idea, but it seems to me excellent timing because of ongoing but fairly mature adoption of pipe wire as the standard way of handling sound routing in Linux. There will be a release of Ubuntu Resolute Raccoon (26.04) around April 23, and that has prompted me to think about what follows:

I am wondering if it would make sense, and how difficult it would be, to make it possible to run sox_ng As a filter node in the Pipe wire graph. I suspect this would tremendously reduce latency as compared to using a pw_record | sox_ng | pw_play pipeline. I also suspect that some of the effects, and definitely the ability to combine many effects in a single node, would be advantageous to pipe wire users.

-- 
Doug Lee                 dg...@dl...                http://www.dlee.org
"It is difficult to produce a television documentary that is both
incisive and probing when every twelve minutes one is interrupted by
dancing rabbits singing about toilet paper."  --Rod Serling

Hi
  A relatively serious defect is being reported in sox_ng-14.6 and 14.7
whereby, due to me changing the default from --single-threaded to
--multithreaded, SoX can become incredibly slow: in one case
increasing the wallclock time from 0.38 seconds to 7m23s and in
another from 5 seconds to 210.

  The cause is that when two OpenMP threads need the same resource
by default they busy-wait for a while ("spinning") before going to sleep
and waiting to be woken up. Bad OpenMP.

  The workarounds are to include --single-threaded as an option
(or set SOX_OPTS=--single-threaded) or to set the environment
variable OMP_WAIT_POLICY=PASSIVE before launching SoX
to make it use multiple processors efficiently.

  We are still figuring out what the best solution to this can be;
at worst we can revert to only using one processor by default.

Thanks to danadam for finding the cause and workarounds for this.
Expect another slew of patch releases soon ;-/

    M

Cheers, Dr. TM

Hi again
  There's a new set of bugfix releases from 14.4.6 to 14.7.1 at
https://codeberg.org/sox_ng/sox_ng/releases and yet another
bleeding-unstable interim one.

  The news as usual is that more distros are switching to sox_ng
and it'll be part of Debian stable in 2027 or 8, hence Ubuntu, Mint...

  After the next new features release in May I plan to stop working full time
on SoX and look at distributed networks, which seem a more urgent need so
if you want to say thank you to me with money for the last two years' work,
this would be a good time to help pay off the overdraft.
  http://martinwguy.net/donate.html
  After May, I'll still be around to apply critical bug fixes,
to help with mysteries and to do the releases.

  Thanks to akwizgran, Alfred Wingate, Case@hydrogenaudio, Daniel Adamski,
Dave Jones, Doug Lee, jwdevel, Prof Spock, Sebastian Ramacher and others
for recent creative input, as always to the admins of the GCC Compile Farm
and to the ever-occasionally-present historic SoX developers.

SoXian blessings to all

   M

Hi again
  There is a new set of patch releases of sox_ng

Mostly, the Windows exes now include support for opus format
and are optimized for speed and the PDFs of the manual pages are
included in the distribution tarballs.

https://codeberg.org/sox_ng/sox_ng/releases

    M

On Thu, 22 Jan 2026 at 04:47, Doug Lee <dg...@dl...> wrote:
> On Thu, Jan 22, 2026 at 03:38:29AM +0100, Martin Guy wrote:
> >On Wed, 21 Jan 2026 at 21:57, Doug Lee <dg...@dl...> wrote:
> >> I also find some anomalies with headroom: Depending on multiplier, high headroom values result in sudden sound cutoff as the volume starts ramping up. I see no recovery from this state. (I tried values above 1.0, like 2, 5, etc., to try to cap the volume ramp far enough below max volume that other sounds in my headset could still be heard.)
> >
> >Sorry, I'm not sure exactly the scenario you mean. with softwol -D?
> >Can you give a sample command line as an example of this?
>
> play_ng -n synth 10 sin 220 fade 5 softvol 1 .5 5
>
> goes silent for me at about 5 seconds even though it still plays through 10 as expected.

Yes. It was dividing two int64s hoping to get a float. Oops.
More patch releases with fix: https://codeberg.org/sox_ng/sox_ng/releases

    M

On Thu, Jan 22, 2026 at 03:38:29AM +0100, Martin Guy wrote:
>On Wed, 21 Jan 2026 at 21:57, Doug Lee <dg...@dl...> wrote:
>> v and V work on a softvol effect on my old Mac; but they are effectively negated if the doubletime is not 0. This seems mathematically sensible but intuitively unexpected.
>
>Thanks, will investigate
>
>> I also find some anomalies with headroom: Depending on multiplier, high headroom values result in sudden sound cutoff as the volume starts ramping up. I see no recovery from this state. (I tried values above 1.0, like 2, 5, etc., to try to cap the volume ramp far enough below max volume that other sounds in my headset could still be heard.)
>
>Sorry, I'm not sure exactly the scenario you mean. with softwol -D?
>Can you give a sample command line as an example of this?

play_ng -n synth 10 sin 220 fade 5 softvol 1 .5 5

goes silent for me at about 5 seconds even though it still plays through 10 as expected.

My read of softvol's documentation is that this example should let the sine wave increase in amplitude up to -5 dB and then hold at that level.

>> I wonder if v and V should affect headroom
>
>v and V only tweak the hardware mixer settings and don't interact with headroom.

True; I was speculating whether it would make sense to alter v and V behavior to do that when softvol is handling those keys.

>softvol instead doesn't currently support gain -h ... gain -r
>as that is always calculated and set when an effect starts.
>It never clips itself, but would have to know the quietest prolonged
>period of the input file to know how high it could amplify by.
>
>> or if v and V should be able to apply to vol instead of softvol so that the dynamics of softvol won't alter the result.
>
>vol, oddly enough, is another effect that doesn't support headroom.
>I would have thought it should, as it's pretty easy to know how much
>it amplifies by
>unless, of course, its gain is adjusted while it's running by a keymap
>as you suggest,
>in which case again it wouldn't be able to know at effect startup time.
>
>    M


-- 
Doug Lee                 dg...@dl...                http://www.dlee.org
"Even Capitalism sucks without morality."
--James Bentley

On Wed, 21 Jan 2026 at 21:57, Doug Lee <dg...@dl...> wrote:
> v and V work on a softvol effect on my old Mac; but they are effectively negated if the doubletime is not 0. This seems mathematically sensible but intuitively unexpected.

Thanks, will investigate

> I also find some anomalies with headroom: Depending on multiplier, high headroom values result in sudden sound cutoff as the volume starts ramping up. I see no recovery from this state. (I tried values above 1.0, like 2, 5, etc., to try to cap the volume ramp far enough below max volume that other sounds in my headset could still be heard.)

Sorry, I'm not sure exactly the scenario you mean. with softwol -D?
Can you give a sample command line as an example of this?

> I wonder if v and V should affect headroom

v and V only tweak the hardware mixer settings and don't interact with headroom.

softvol instead doesn't currently support gain -h ... gain -r
as that is always calculated and set when an effect starts.
It never clips itself, but would have to know the quietest prolonged
period of the input file to know how high it could amplify by.

> or if v and V should be able to apply to vol instead of softvol so that the dynamics of softvol won't alter the result.

vol, oddly enough, is another effect that doesn't support headroom.
I would have thought it should, as it's pretty easy to know how much
it amplifies by
unless, of course, its gain is adjusted while it's running by a keymap
as you suggest,
in which case again it wouldn't be able to know at effect startup time.

    M

I never saw those keys work with hardware. I may have used them if they did, but not extremely often.

v and V work on a softvol effect on my old Mac; but they are effectively negated if the doubletime is not 0. This seems mathematically sensible but intuitively unexpected.

I also find some anomalies with headroom: Depending on multiplier, high headroom values result in sudden sound cutoff as the volume starts ramping up. I see no recovery from this state. (I tried values above 1.0, like 2, 5, etc., to try to cap the volume ramp far enough below max volume that other sounds in my headset could still be heard.)

I mention that unrelated anomaly because I wonder if v and V should affect headroom, or alternatively, if v and V should be able to apply to vol instead of softvol so that the dynamics of softvol won't alter the result.

On Wed, Jan 21, 2026 at 05:42:55PM +0100, Martin Guy wrote:
Hi
  The manual has long said that pressing the v and V keys
in interactive mode (i.e. "play" or "-d") will decrease and
increase the volume of the audio mixer, but this was only ever
implemented for Solaris (-t sunau) and OSS on Linux, not for
alsa, ao (Xiph's libao device driver), coreaudio (Mac),
pulseaudio, sndio or waveaudio (Windows)

  However, the OSS compatibility layer for ALSA is not generally
enabled by default, or is not included in many Linux distributions,
which is presumably why 'v' and 'V' don't work any more.

  So my question is whether anyone actually uses and likes 'v' and 'V'
or whether I can just remove this functionality, which would be easier
than writing the code to drive half a dozen audio mixer controllers.

   As of sox-14.9 in May you'll be able to achieve the same effect
by including a final "softvol" effect and using

    --keymap v:softvol.volume-2 --keymap V:softvol.volume+2

or that could be the default mapping for v and V.

Thanks

    M


-- 
Doug Lee                 dg...@dl...                http://www.dlee.org
"Believe, when you are most unhappy, that there is something for you
to do in the world. So long as you can sweeten another's pain, life is
not in vain." --Helen Keller

Hi
  The manual has long said that pressing the v and V keys
in interactive mode (i.e. "play" or "-d") will decrease and
increase the volume of the audio mixer, but this was only ever
implemented for Solaris (-t sunau) and OSS on Linux, not for
alsa, ao (Xiph's libao device driver), coreaudio (Mac),
pulseaudio, sndio or waveaudio (Windows)

  However, the OSS compatibility layer for ALSA is not generally
enabled by default, or is not included in many Linux distributions,
which is presumably why 'v' and 'V' don't work any more.

  So my question is whether anyone actually uses and likes 'v' and 'V'
or whether I can just remove this functionality, which would be easier
than writing the code to drive half a dozen audio mixer controllers.

   As of sox-14.9 in May you'll be able to achieve the same effect
by including a final "softvol" effect and using

    --keymap v:softvol.volume-2 --keymap V:softvol.volume+2

or that could be the default mapping for v and V.

Thanks

    M

This one's a doozey. You can now make arbitrary keystrokes
adjust some of the effects' parameters in --interactive mode.

What asked for it was dolbyb.gain to set 1.0 to correspond to 220nWb
magnetic tape density:

    play -V --keymap D:dolbyb.gain+2 --keymap d:dolbyb.gain-2 foo.mp3

there's also * and / to do exponential adjustment and = to set it to a value.

The current bindings are:

centercut.gain for the -a parameter
chorus.(gain-in|gain-out)
contrast.amount
dolbyb.gain
echo.(gain-in|gain-out)
echos.(gain-in|gain-out)
overdrive.(gain|color)
phaser.(gain-in|gain-out|regen)
saturation.(blend|offset|drive|color|threshold)
softvol.(volume|double-time|headroom)
vad.(trigger-level|trigger-time|gap)
vol.gain adjusted by the gain type you specified

i.e. all the ones where the parameter value is used unadorned
in the sample loop, or a derivative of it that's easy to convert.

For things where tables need to be recalculated or
memory sizes changed, I am open to suggestions
of which parameters of which effects it would be
most useful to be able to twiddle, and evaluate
their relative difficulties to implement.
https://codeberg.org/sox_ng/sox_ng/releases

Thanks to many for the input

  M

Sorry for all this noise!

A new effect, "centercut" has just gone into sox_ng, dug out of the
feature requests with patches on sox.sf.net, a more sophisticated
version of "oops" that, instead of simply subtracting one channel from
the other to remove the center, preserves the stereoness of the left
and right channels while providing the stuff common to both on a
third channel, the center channel, by means of a Fast Hartley Transform, separating the channels in the frequency domain and resynthesizing,
so the "karaoke" effect with the center bass preserved in L and R is:

   sox_ng in.wav out.wav centercut -b remix 1 2

There is an interim release sox_ng-14.7.0+git20251208 on
https://codeberg.org/sox_ng/sox_ng/releases for anyone
who would like to try this out, with a few other trivial bug fixes.

    M

On Thu, 4 Dec 2025 at 09:29, Doug Lee <dg...@dl...> wrote:
> On Wed, Dec 03, 2025 at 02:55:38PM +0100, Martin Guy wrote:
> >On Tue, 2 Dec 2025 at 21:20, Doug Lee <dg...@dl...> wrote:
> >> play FAIL oops: this effect takes no parameters
> >Thanks. 14.7.0.2 is up.
> Works in 14.7.0.3 which landed in Brew today; thanks much.

You're welcome. That explains why every release immediately gets
36 downloads of the .tar.gz: that 36 distros' (or other) bots are watching it.
Currently, 20 of the 57 distros that I track package sox_ng,
https://codeberg.org/sox_ng/sox_ng/wiki/Distros
of which ArchLinux is the biggest and T2 SDE was the first.

> "Determine that the thing can and shall be done, and then...find
> the way." - Abraham Lincoln

Oh Lord, give me the courage to change the things I can change,
the serenity to accept the things I can't change and the wisdom
to distinguish between them.

    M

On Wed, Dec 03, 2025 at 02:55:38PM +0100, Martin Guy wrote:
>On Tue, 2 Dec 2025 at 21:20, Doug Lee <dg...@dl...> wrote:
>>
>> MacOS with sox_ng 14.7.0.1 installed via Brew:
>>
>> $ play -n synth 1 pink vol .1 channels 2 remix 1 1v.3 oops
>> play FAIL oops: this effect takes no parameters
>
>Thanks. 14.7.0.2 is up.

Works in 14.7.0.3 which landed in Brew today; thanks much.



-- 
Doug Lee                 dg...@dl...                http://www.dlee.org
"Determine that the thing can and shall be done, and then...find
the way." - Abraham Lincoln

On Tue, 2 Dec 2025 at 21:20, Doug Lee <dg...@dl...> wrote:
>
> MacOS with sox_ng 14.7.0.1 installed via Brew:
>
> $ play -n synth 1 pink vol .1 channels 2 remix 1 1v.3 oops
> play FAIL oops: this effect takes no parameters

Thanks. 14.7.0.2 is up.

    M

MacOS with sox_ng 14.7.0.1 installed via Brew:

$ play -n synth 1 pink vol .1 channels 2 remix 1 1v.3 oops
play FAIL oops: this effect takes no parameters

(That chain should produce a quiet pinknoise because one channel is louder than the other, so they won't cancel fully.)

-- 
Doug Lee                 dg...@dl...                http://www.dlee.org
"It's not easy to be crafty and winsome at the same time, and few accomplish
it after the age of six." --John W. Gardner and Francesca Gardner Reese

A third option under consideration is fixed-point FFTs as an option for
FPU-less machines (embedded systems mainly)

with 31 bits other than the sign bit, which limits the number of bins to
205887 for 2*PI/acos, enough to be useful for the usual sizes of a few thousand.
In any case, we probably want to prefer a large margin of extra precision
rather than sailing close to the theoretical limit where I assume that only just
being able to distinguish one bin from the one next to it is less
likely to produce
good results.

Thanks again for the clarifications and formulae; I'd be lost without
you in these areas

    M

Hello Sergei,


thanks for your clarification!

 > > [Thomas does not quite understand the implications of the
 > >  cancellation]
 > The issue, as already pointed out, is spectral resolution. I.e. when
 > two adjacent DFT bins frequencies become the same, instead of having
 > two SEPARATE bins (maybe with some magnitude error) we have a
 > DUPLICATED bin.

Okay, that sounds plausible.

 > Regarding the "whether it invalidates the complete transformation or
 > only part of it" in DFT by its nature (see the link to FFTW
 > documentation) every point in frequency domain depends on every
 > point in time domain and vice versa. But the detrimental effect is
 > most pronounced the peaks/dips of 'cos' and 'sin' components.

I am quite aware of the juggling around of factors in the FFT
algorithm, but I have no good mental model of the effects when some
coefficients are bad.  My gut feeling is that the transformation
results are collectively off somehow, but I cannot quantify how far.

 > Regarding "cos(1/n)" in your estimates - I think it should rather be
 > cos(2 * pi / N).

That's correct, sorry for the lapse.  So there is a factor of six
missing. The correct analysis is:
     cos(0) - cos(2*pi/n) = 1 - cos(2*pi/n) < m
     ==> n > 2*pi/arccos(1 - m)

I have to still think whether the maximum acceptable distance is
2^(-24) (resp. 2^(-53) for double) or one magnitude less, but at
least we are in the ballpark described by you.


	Best regards,

		Thomas

Hello Martin, hello Sergei,


Sergei's observation can also be analyzed as follows:

We are looking for DFT bin counts n, where cos(0) - cos(1/n) is
less than the machine precision (indicated by the number of bits in
the mantissa).  In that case cos(1/n) does not differ enough from
cos(0) so that the difference is zero (this is referred to as
"numerical cancellation" by the way).

For floats the machine precision m is 2^(-24), for doubles it
is 2^(-53).

So we have:
     cos(0) - cos(1/n) = 1 - cos(1/n) < m
     ==> n > 1/arccos(1 - m)

For floats this leads to n > 2896, for doubles n > 67108864.

So Sergei is correct: a bin count of 4096 is too big for float and
a bin count of 2^27 is too big for double.

But to be honest, I have not yet understood how this cancellation
propagates within the DFT/FFT algorithm and whether it invalidates
the complete transformation or only part of it.


	Best regards,

		Thomas

https://codeberg.org/sox_ng/sox_ng/issues/558
and your article is summarized in the wiki in Discrete_Fourier_Transform
so if there's anything that needs correcting there let me know

Blessings

    M

Sergei's analyses seem not to have made it to sox-users, nor my
attempt to forward them
(maybe for the number of links in them? Ah, legacy cruft!) so I've
preserved his work in
https://codeberg.org/sox_ng/sox_ng/wiki/Discrete-Fourier-Transform

    M

Sergei's analysis seems not to have made it to the sox-users archive,
so herewith:

On Sat, 29 Nov 2025 at 07:23, Sergei Steshenko <ser...@ya...> wrote:
> Let's start from very basic things.
>
> FT (Fourier Transform - not necessarily DFT - Discrete Fourier Transform) is a subset of transforms in which the function to be transformed is decomposed, i.e. presented as a sum of orthogonal functions - see https://en.wikipedia.org/wiki/Orthogonal_functions .
>
> And on DFT specifically, see, for example, "Nailing Fourier Series and Orthogonal Decompositions" - https://medium.com/@ivethium/nailing-fourier-series-and-orthogonal-decompositions-ff94b9d7476a . And/or https://fftw.org/fftw3_doc/What-FFTW-Really-Computes.html#What-FFTW-Really-Computes .
>
> So, in DFT the 'cos' and 'sin' components are the set of orthogonal functions to do the decomposition on. I emphasize the point - each cos(2 * pi * Bn / N) and sin(2 * pi * Bn / N) (Bn is bin number and N is number of points DFT) is orthogonal each other when Bn is different - this is by definition of orthogonality.
>
> Mathematically the above cos(2 * pi * Bn / N) and sin(2 * pi * Bn / N) are orthogonal, but computationally they are not necessarily orthogonal because of insufficient number of bits.
>
> If we take DFT bin number 0 (Bn is 0), cos(2 * pi * Bn / N) becomes cos(0) which is 1, and if bin number 1 (Bn is 1) cos(2 * pi * Bn / N) becomes cos(2 * pi  / N) . With large enough N because of limited number of bits the 2 * pi  / N will become effectively 0 and thus cos(0) will become equal to cos(2 * pi  / N), thus instead of two orthogonal (i.e. different) functions we'll have just ONE (cos(0)) function.
>
> So, we'll break the orthogonality assumption and thus we will NOT be performing DFT.
>
> A quick check in Julia:
>
> "
>
> julia> let; x::Float32 = 1.0 / 4096; cos(x) end
> 1.0f0
>
> julia> let; x::Float32 = 1.0 / 2048; cos(x) end
> 0.9999999f0
> ",
>
> i.e. N = 4096 is already  too much for 32 bit FP numbers.
>
> ...
>
> I think I'll be able to find other FFT libraries which work with non-power of 2 numbers 64 bit floats.

> To emphasize the point(s).
>
> If/when we perform spectral analysis, we are interested in two (three) things:
>
> 1) presence/absence of spectral components;
>
> 2) magnitude of spectral components;
>
> 3) maybe phase of spectral components.
>
> The issue I described causes lack of resolution when looking for spectral components. I.e. not sufficient number of bits in DFT prevents properly detecting spectral components. With 32 bit FP numbers signal itself has ~23 bit resolution, but frequency domain resolution is less than 12 bits.

> And the same kind of test for 64 bit FP numbers:
>
> "
>
> julia> let; x::Float64 = 1.0 / (2^27); cos(x) end
> 1.0
>
> julia> let; x::Float64 = 1.0 / (2^26); cos(x) end
> 0.9999999999999999
>
> julia> 2.0^26 / 44100
> 1521.742947845805
>
> ",
>
> i.e. 27 bits is too much. Which means that for audio applications 64 bit floats are quite OK as long as buffer size is less than 1522 seconds @ 44100Hz sample rate.

> And back to the issue whether 'pffft' supports 64 bit FP numbers - in https://github.com/cpuimage/pffft/blob/master/fftpack.h one can see (line #52) :
>
> "
>
> // just define FFTPACK_DOUBLE_PRECISION if you want to build it as a double precision fft
>
> #ifndef FFTPACK_DOUBLE_PRECISION
>   typedef float fftpack_real;
>   typedef int   fftpack_int;
> #else
>   typedef double fftpack_real;
>   typedef int    fftpack_int;
> #endif
>
> ".
>
> --Sergei.

On Sat, 29 Nov 2025 at 14:37, Martin Guy <mar...@gm...> wrote:
>
> Thanks, that's all clear now.
>
> > OK as long as buffer size is less than 1522 seconds @ 44100Hz sample rate
>
> I think we can guarantee that!
>
> > // just define FFTPACK_DOUBLE_PRECISION
>
> Good. SoX's internal "fft4g" routine has the same thing:
>
> #ifdef FFT4G_FLOAT
>   #define double float
>   #define sin   sinf
>   #define cos   cosf
>   #define atan  atanf
>
>   #define cdft  lsx_cdft_f
>   #define rdft  lsx_rdft_f
> ...
>
> which means some jiggery pokery to compile it twice into different object files
> to get both versions (something I was already contemplating for fft4g) and
> that means including the pffft source in SoX' source tree to be able to do this,
> something that would be necessary anyway as it's not included in many distros,
> only ArchLinux, MacPorts and FreeBSD Ports.
> https://repology.org/project/pffft/versions
>
> Thanks for your exhaustive analysis of the necessary precision in DFTs.
> I will be careful with them.
>
>     M

Thanks, that's all clear now.

> OK as long as buffer size is less than 1522 seconds @ 44100Hz sample rate

I think we can guarantee that!

> // just define FFTPACK_DOUBLE_PRECISION

Good. SoX's internal "fft4g" routine has the same thing:

#ifdef FFT4G_FLOAT
  #define double float
  #define sin   sinf
  #define cos   cosf
  #define atan  atanf

  #define cdft  lsx_cdft_f
  #define rdft  lsx_rdft_f
...

which means some jiggery pokery to compile it twice into different object files
to get both versions (something I was already contemplating for fft4g) and
that means including the pffft source in SoX' source tree to be able to do this,
something that would be necessary anyway as it's not included in many distros,
only ArchLinux, MacPorts and FreeBSD Ports.
https://repology.org/project/pffft/versions

Thanks for your exhaustive analysis of the necessary precision in DFTs.
I will be careful with them.

    M

On Fri, 28 Nov 2025 at 20:18, Sergei Steshenko <ser...@ya...> wrote:
> Regardless of particular FFT package, and regardless of the fact
> that SoX works on 32 bit FP audio data, convolutions should rather be
> performed using 64 bit FP data. If necessary I'll explain why - the
> hint: compare values of cos(0) and cos(2 * pi / N) where N number of
> points in FFT.

I don't understand the why (I'm a good code monkey but not so hot in
analogue math)
but I'll remember that, so thanks for mentioning it.
Does the same go for FFTs used for the spectrograms? I'd assumed that
25-bit floats
would lose nothing of significance there and that a 40% speedup might
be possible;
I'll assume that what you say applies to any effect that resynthesizes
audio from FFTs.

I notice that the PFFFT page says it only does single-precision so I assume that
excludes using it for convolutions?

    M