Music production wise it's as alive as it's ever been.
I'm reminded of Behringer building entire factories on the back of a line of reissues of other people's analog synths. They worked out how to build that stuff in modern workflows without compromising the analog signal paths: I've taken apart their newer gear and saw how it was done. All you have to do is not build it like it's a cellphone, and give the audio paths quite a lot of extra signal handling capacity plus some fairly modern circuit board design knowledge.
I've got a couple MakeNoise synths that are likewise very modern designs but stand up to anything anyone's ever done, vintage or not. Designing analog circuitry is definitely in a renaissance.
Also, everything analogue feels so snappy, compared to doing stuff in “the box”. On a computer, the audio must be buffered whenever transferred between components, and this really adds up to noticeable latency when doing real time stuff.
Of course, there is stuff which is not feasible to do in analogue. Spring reverbs are cool, but it is far from digital reverbs like the Valhalla shimmer.
(Speaking of telephones, I really miss the times when the phones did not have all this latency. It feels like speaking in a walkie-talkie some times.)
Amen to that. The number of times that I've gotten into 'we both start talking at the same time' deadlocks on the phone (and video conferencing, for that matter) in the last couple of years has reached high levels of irritation.
On Linux you’ll also have to mess with pulseaudio settings, but that’s all you need on Windows.
In theory a motherboard mic input could offer the same settings, but they (correctly) assume most users have a shitty CPU that can’t handle real time tasks without lag spikes that lead to buffer underruns.
Unless you only work with other software developers (or gamers I guess) who are latency sensitive like us, most of the people you speak with over VoIP are unlikely to have a Ethernet connection.
Last time I worked full-time in an office, some people didn't even know you could connect to the internet/router via a cable instead of wireless...
If that wasn’t the case, I’d probably buy them a 50ft cable on every holiday until they stop lagging.
If you're talking with them over VoIP, my hunch is that money isn't the problem here (30m ethernet cables cost like ~$15-30), but rather being able to pull a cable through the house/apartment without making it look like an eyesore or even being in the way.
Not true. Any half-decent audio API will drive the whole audio graph from the hardware I/O callback, so there’s only a single buffer, usually of length 256-512 samples.
cc @PaulDavisThe1st
synth → reverb → output
Every 5.33ms the OS audio system (CoreAudio, JACK, etc.) calls your DAW to produce 256 samples of audio. The DAW looks at the audio graph and asks the plugin connected to the output, the reverb, to produce 256 samples of audio. The reverb calls the next plugin, the synth, to produce 256 samples of audio, then applies the reverb effect on it, then returns it to the DAW, which returns it to the OS, which writes it to the audio hardware’s buffer. This all happens within the same 5.33ms callback.
You can have as many plugins as you like, there’s no additional latency (unless the plugin explicitly adds buffering).
Again, cc @PaulDavisThe1st
Additionally, conventional hardware input/output requires at least two periods of buffering for a stable duplex session (mic input and speaker playback simultaneously). On startup, you fill the output buffer with 2 periods of silence. Every period (when input buffer grows and output buffer shrinks by 1 period), you take 1 period of input audio, feed it through the audio graph (which can take up to 1 period otherwise your speakers run out of audio to play and stutter), then write 1 period of output audio to the speakers. Smaller periods (lower sample/frame count, lower duration in ms) reduce latency, but increase the risk of stutter if your system can't schedule and run all audio apps in 1 period of time.
I was explicitly mentioning JACK and CoreAudio, because the discussion was about professional audio tools.
>Additionally, conventional hardware input/output requires at least two periods of buffering for a stable duplex session
This is not true if both the input and output are coming from the same device. In that case you can serve both input and output within the same IO callback, thus the playthrough latency will be only a single period. Multi-device playthrough is more complicated, as you'd need asynchronous sample-rate conversion due to different hardware clocks (i.e. clock drift), which inherently increases latency.
By playthrough latency, do you mean having the output play the same audio being captured from the input/mic? One period of loopback/playthrough latency is only possible if you can instantaneously copy data from the input to output buffers (for example by using the same hardware buffer for both?). In practice, PipeWire and JACK2 both introduce 2 periods (in PipeWire, quantums) of buffering latency, which I've discussed in my blog (https://nyanpasu64.gitlab.io/blog/low-latency-audio-output-d...), or you can confirm by reading their source code.
It doesn't even have to be modern... in fact, for many consumers something "modern" is undesirable.
Like "organic", "analog" and "vintage" are very effective marketing terms.
Slap those on your products and they'll sell like hotcakes.
Once ECL lost the high ground in performance, it was gone forever. You won't encounter it outside of computer museums today, except in very specialized applications. Analog computing is like that, only even more doomed. It doesn't scale.
I do think we'll get back to analog eventually, for the same reason our brains aren't digital. But that will look like alien technology compared to what we have now, so there's no near-term incentive to explore it. Right idea, wrong timeframe, probably by a hundred years or more.
It will never be over, but digital eats analog a bit more each day.
Even stuff that’s born digital, like samplers, are coming with analog parts today.
I remember several keyboardist, guitarist and engineer friends selling all their analog gear for some stuff that is completely obsolete and abandoned by players now.
The analog stuff on the other hand sells like hotcakes. Even stuff from the 90s fetches crazy prices.
And with the renaissance, people are also buying newly designed analog stuff at an amazing pace.
No, DAC means digital-to-analogue convertor. It comes after the computer. Sampling before a computer is done by an ADC.
> The signal chain is that simple.
No, the software signal chain is not simple.
> No, the software signal chain is not simple.
While the software itself might be complex, the grandparent is right: digital audio data coming out of the ADC doesn’t get transformed in the way you suggested above. There’s no secret compression, transcoding or resampling going on without the knowledge of engineers, as it would add noise and interfere with production techniques. Even things like dithering have to be added separately.
Consumer audio, even (or especially!) when things are 10x more expensive than pro products, is definitely a bit of a garbage fire.
Do you perform bit-perfect tests to be sure? The people who write the software are surely the ones in control.