Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A lot of audio hardware does this - it switches the audio off only when the signal is at a zero crossing. So it can be implemented by the OS by telling the codec that the zero value is an underrun rather than a desired signal.


I solved that problem years ago by keeping a canned piece of white noise in a const buffer that I would switch to if there was an underrun, with an immediate ramped gain reduction to zero. The result were quite good!


Interesting. So what would happen if a sine wave of, say, 1Khz is suddenly shut off by a buffer underrun?


It would be cool if the hardware did some Fourier analysis to resample the buffers it gets (so it could make them run for longer if the buffers run dry), but it probably would cause some kind of latency issue. I reckon that just avoiding buffer underruns is less overhead.


I had to cut off an audio file abruptly once, and I found that I could smooth out the abruptness by quickly fading in a reverberated version of the audio, just as the original audio was about to end, and then letting it ring for a fraction of a second after the original had ended.

(I say "fading in", but it might have been that I had the reverb applied but dry, and transitioned to wet just before the signal ended.)


A colleague of mine actually patented this technique: http://www.google.com/patents/US8538038


:-/


Yep, this should not be a patent..It's a trivial solution to the problem that could be devised by any sound engineer!


If you have any evidence of prior work to that patent (I really hope you do), then you can topple that patent. If your code to do what you said isn't free software I'd recommend you release it as free software now.


I can't check right now, but it's possible that the patent predates my use of the technique. Even if not, I don't know how I could prove it.

By the way, it wasn't done in code; I did it manually in Ardour [0].

[0] <https://ardour.org/>


This seems like the most sensible thing to do, and was actually what I was getting at :)

What do you mean by latency issues? Why would there be any?


Quoting from the Waldorf microwave XT synthesizer FAQ:

The brightness of the click depends on the speed of the level change. The faster the level changes, the brighter is the click. So, the level change speed can be compared with the cutoff of a lowpass filter. There is an easy formula for it:

Let's consider a level change from full to zero (or from zero to full) output from one sample to another on a machine that uses 44.1kHz sample rate. So, we first transfer the sample to milli seconds:

1 sample equals 1/44100 second, which is = 0.02267573696ms.

To calculate the cutoff frequency of the click, just use this formula:

Cutoff (Hz) = 1000 / Level Change Time (ms)

which in the example results in:

44100Hz = 1000 / 0.02267573696ms

Whoops? This the sampling frequency and, err, very bright.

http://faq.waldorfian.info/faq-browse.php?product=xt#116


Waldorf seems like a cool company. It makes me smile to see that they went into such detail in the manual. Plus the Microwave XT sounds amazing.


With zero crossing detection, it would need to know the buffer is running out before the next zero crossing occurs. So if the shutdown signal is given within the last millisecond before the zero crossing, it would ignore all data that comes after the zero, and output zero for the remaining partial wave. On starting up again, it would wait until the signal is at zero before beginning to output. At least that's how the common audio codecs I've seen that implement that feature work. The most common application is volume control, where you don't want a sudden change in the amplitude of the wave to result in a glitch, so you adjust amplitude at zero crossings.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: