Live data from Hacker News

A low latency guitar effects processor suitable for running on a Raspberry Pi

github.com

131–140 of 147 posts

Re: A low latency guitar effects processor suitable for running on a Raspberry Pi

#131
post #73

Earlier quoted context omitted.

While video needs more CPU power, it can tolerate higher latency than sound.

Spot on. For context: 60fps gives you ~17ms of wiggle room before you start dropping/delaying frames. With 96kHz audio you have 0.01ms between samples. Drift above 0.05ms and you'll start introducing time domain issues in the human hearing range. In other words, 'realtime' audio processing needs to happen 1700x faster that 'realtime' image work. Bandwidth isn't limiting factor, deterministic and uniform latency is th…

Drift really isn't a problem with audio cards. Latency is. To put things in perspective, it takes sound 1ms to travel 1 foot.

The general consensus is that guitar effects have to have no more than 10ms latency.

Re: A low latency guitar effects processor suitable for running on a Raspberry Pi

#132
post #70

Earlier quoted context omitted.

According to Analog's product page [1] for the ADSP-21469, it delivers 2.7 GFLOPS at 450 MHz. And Wikipedia's page of all the RPi models says that the latest (4B) manages 8 GFLOPS at around 1.8 GHz. If that means that the answer to your question is "yes" or "no" is unfortunately a lot harder to Google and/or figure out. I would assume that the SHARC-based devices run on the metal, whereas most applications for the Ra…

There's also a real-time version of the Linux kernel which is meant for exactly this type of application.

Most of the real-time Linux kernel has been ported into mainline. Mainline is perfectly capable of producing stable low-latency audio, as long as you're running on threads with real-time priority.

The real-time kernel provides additional improvements. But it's incredibly difficult to find up-to-date real-time kernels these days.

Re: A low latency guitar effects processor suitable for running on a Raspberry Pi

#133
post #21

Earlier quoted context omitted.

Sep 2 of the build instructions says it requires RtAudio.

what is the latency of a raspberry pi running this type of software? can't find figures anywhere

3.9ms measured audio latency using a loopback cable.

https://rerdavies.github.io/pipedal/AudioLatency.html

Re: A low latency guitar effects processor suitable for running on a Raspberry Pi

#134

Earlier quoted context omitted.

My normal chain is a noise gate, followed by a comp, a little emulated tube drive, an SVT amp model, an impulse response modeled cab simulator (of course running a 8x12 SVT cab), a plate reverb, and a limiter. I've got some crazier ones, but as a beginner bassist, that's all I really need. There are literally hundreds of effects to choose from though. Convolution reverb is an option, but it ended up being a little mo…

Just double checked my jack settings; I'm running my interface at 48000hz with a buffer size of 128 and 2 periods for a theoretical latency of 5.33ms. I'm sure USB adds a fraction of a millisecond as well.

You'll get lower latency with 3 buffers. Try 16/3.

Re: A low latency guitar effects processor suitable for running on a Raspberry Pi

#135
post #21

Earlier quoted context omitted.

Sep 2 of the build instructions says it requires RtAudio.

what is the latency of a raspberry pi running this type of software? can't find figures anywhere

I also wonder about the latency of the behringer interface. I've had one before, the sound quality is pretty good for entry level high-fi audio, but when I've run the audio into a DAW and back out post-processing there has always been an audible delay.

Granted, this was in windows, but from what I understand there is always going to be some audible processing delay with a USB 2.0 interface.

Re: A low latency guitar effects processor suitable for running on a Raspberry Pi

#136
post #22

Earlier quoted context omitted.

Modern CPUs are great if your watt (and thus thermal) profile is unlimited. Not so great when they aren't.

Most processing of audio isn't CPU performance limited... For most realtime audio mixing, it doesn't matter if you use 1 watt or 10 watts for your CPU - the big speakers will easily be drawing far more, and the performers time will be costing far more than the electric bill anyway.

It's CPU limited in the sense that it's extraordinarily latency/jitter sensitive.

Re: A low latency guitar effects processor suitable for running on a Raspberry Pi

#137
post #22

Earlier quoted context omitted.

Modern CPUs are great if your watt (and thus thermal) profile is unlimited. Not so great when they aren't.

Does this form a problem for digital mixing consoles? As far as I know, these already have fairly beefy fans for heat exhaust, so I don't know if they couldn't just add more airflow?

Not especially. I'm more thinking of things that have a potential of being near a live mic, where a cooling fan is a no go, at least without a defeat switch.

Re: A low latency guitar effects processor suitable for running on a Raspberry Pi

#138

As an amateur musician, three things stand out: 1. I'd have a hard time seeing that small screen onstage, and my big foot would likely mash the wrong effects button. Others might find it easier. 2. There are tons of good, cheap effects boxes out there, and easy to find used. I like Pi boxes, but this seems like a homebrew replication of what's on the market. 3. All good boxes are low-latency, in my experience. It's a…

You’re definitely right. I think the draw of all of this is to make it yourself. The same could be said of people who make their own diy home weather stations or web servers. You could always outsource for the same thing that’s better, more frequently updated and probably cheaper when you factor in the time it takes to make. It’s just neat to make the tools that you ordinarily have to dish out catch to get. :)

Re: A low latency guitar effects processor suitable for running on a Raspberry Pi

#139

Earlier quoted context omitted.

Spot on. For context: 60fps gives you ~17ms of wiggle room before you start dropping/delaying frames. With 96kHz audio you have 0.01ms between samples. Drift above 0.05ms and you'll start introducing time domain issues in the human hearing range. In other words, 'realtime' audio processing needs to happen 1700x faster that 'realtime' image work. Bandwidth isn't limiting factor, deterministic and uniform latency is th…

Drift really isn't a problem with audio cards. Latency is. To put things in perspective, it takes sound 1ms to travel 1 foot. The general consensus is that guitar effects have to have no more than 10ms latency.

Poor word choice on my behalf. Drift was meant in terms of sync between different channels or parallel processing paths and in reference to GP. Guitar effects (generally single channel, sequentially processed) bypass that.

That 10ms benchmark is a good one though. At that time window you've reached a full wavelength at 100Hz and it's right about the point where well practiced humans (e.g. musicians) will begin to perceive delay. It's a fascinating intersection between physics/engineering and psychology as signal latencies make the jump from being perceived as timbre to delay.

Re: A low latency guitar effects processor suitable for running on a Raspberry Pi

#140

Earlier quoted context omitted.

There's also a real-time version of the Linux kernel which is meant for exactly this type of application.

Most of the real-time Linux kernel has been ported into mainline. Mainline is perfectly capable of producing stable low-latency audio, as long as you're running on threads with real-time priority. The real-time kernel provides additional improvements. But it's incredibly difficult to find up-to-date real-time kernels these days.

Also worth mentioning that there are enormous USB audio improvements in kernel version 5.10.0, both for performance, stability, and compatibility. As far as I know, there are no real-time kernels available for Pi 4 with a kernel version greater than 5.10.0, and building one is painfully difficult.
Post reply on HN