Re: synth seems to generate "pops"?

On Tue, Mar 25, 2025 at 11:58:15AM -0300, Brian Watson wrote:
>    Hi,
>    I'm thinking of using sox's synth capability to make myself a simple
>    hearing tester.  It will play a bunch of tones at various frequencies,
>    channels and volumes and record my response, or not.
>    After a bit of reading I have figured that something like this:
>    play -r 44100 -n -t alsa synth 0.5 sin 5000 vol -25dB remix 1 0
>    wrapped into a script with the frequency, gain and remix parameters
>    replaced with variables will work exactly as I had hoped.
>    Except - when I listen to the generated sounds there is a small pop, or
>    crack, at the start and end of each sound.  This is going to invalidate
>    my results as the pop/crack is, obviously, not at the frequency of the
>    test tone.

I do not get a pop, but I removed "-t alsa" from your line - that should not be necessary unless your default
driver/device differ from what you want to use. I tried on MacOS and Windows, where it worked flawlessly,
and on a Ubuntu WSL2 instance, where it worked but had the typical buffering issues I see in that environment.

>    The obvious answer is that this pop/crack comes from ALSA, or my DAC or
>    my headphones.  The only thing that makes me think that it is sox is
>    that the "vol" given to "synth" changes the volume of the pop/crack.

On MacOS, my driver was of course coreaudio. On Windows, it was waveaudio. On the WSL2 instance, I believe
it was ao; alsa did not work there.

>    If I do, for example:
>    play -r 44100 -n -t alsa synth 0.5 sin 5000 vol -100dB remix 1 1
>    I get nothing but silence.  I'm taking this as sox being able to open
>    my sound hardware and play the very quiet sound with no pop/crack?

A very quiet sound amid total silence will not produce a big enough transient to make a pop/crack likely.

>    I've seen discussion on similar topics where duration of the tone is
>    manipulated to ensure it aligns with write buffers.  I suspect that's
>    the problem I am seeing, but I don't understand enough to take that
>    information and apply it here.

You might try --buffer with various lengths to see if that fixes the issue. I'd start with 4096, then 2048,
then 1024, etc., to find the smallest value that does not pop.

>    Also, I'm doing this as a learning exercise/experiment and am not
>    trying to create a "product", but if this has already been done or
>    there are better ways to do it I'd be interested to learn.

I've used SoX as a rudimentary hearing tester for many years but never packaged my methods into anything
coherent.


-- 
Doug Lee                 [email protected]                http://www.dlee.org
"I am a leader by default, only because nature does not allow a vacuum."
Bishop Desmond Tutu