Mac mini line-in input latency

[Weakky]

Hey folks,

I'm trying to build a fancy audio visualizer with an old Mac mini and audioMotion.

I have a streamer as an audio source which I'd like to connect to my mac mini's line input to forward the song to audioMotion

Now, when using the headphone jack output on the streamer and connect it straight to the line-in of the mac mini, I'm experiencing no delay at all. Unfortunately though, when using the headphone jack of the streamer, it no longer sends audio to my amp (and thus to my speakers).

As I also have a headphone pre-amp, the Fostex HPA8 MK2, I tried connecting the streamer to the pre-amp with an optical cable, and then tried connecting the pre-amp's headphone output to the Mac mini's line-in input. When doing that, I'm experiencing audio delay, of roughly 200ms, which causes the audio spectrum to get out of sync with the audio getting out of my speakers.

I also tried using the analog RCA output of the pre-amp (using an RCA to jack cable), but the result is the same.

You might then immediately think that the delay then comes from the pre-amp, however, when connecting my headphones to the pre-amp and comparing it with my speakers, there's no delay experienced at all.

All of this makes me think there's some kind of buffer issue on the line-in input, but that still doesn't explain why I'm not experiencing such delay when connecting the mac mini straight to the headphone jack output of the streamer.

Do you folks have any idea what might be the cause? Do you think I could solve the problem by using a dumb USB sound card? Is there any way to decrease the line-in buffer, if that's even the cause? I know there are ways to do that via logic pro and all, but the use-case's different here.

I know this isn't directly related to audioMotion, so feel free to delete the issue if you think it's inappropriate.

Thanks anyway for the awesome tool 🙌

[hvianna]

Hello there!

Most of this latency is inherent to the FFT performed by audioMotion to extract audio data for visualization - it is a somewhat expensive computing operation and needs to buffer some audio frames for calculation. Using the line-in input also adds a minor delay, because it requires an additional analog-to-digital conversion.

You can solve this by connecting your speakers to your mac mini line-out instead, so the audio is only sent to the speakers after being processed by audioMotion.

[Weakky]

Hello @hvianna, thanks a ton for answering!

Most of this latency is inherent to the FFT performed by audioMotion to extract audio data for visualization

I'm fairly confident that the latency is not due to the FFT processing, and the reason is that I'm experiencing the exact same latency when simply replaying the input audio from QuickTime (on macOS). Also, forget about the latency that was supposedly non-existent when going from the streamer's headphone output. The delay is there too.

That being said, I've managed to replay the audio coming from the line-in without any latency using JACK. I'm now blocked again though as I don't know how I could re-route that audio from JACK to Chrome.

You can solve this by connecting your speakers to your mac mini line-out instead, so the audio is only sent to the speakers after being processed by audioMotion.

Unfortunately, that's not an option. I don't want to use the Mac Mini as source and ditch my streamer. Even though I could use the streamer's DAC to theoretically keep the same audio quality, I'd like to keep using the streamer as main audio source and use the Mac mini only for FFT processing using the signal coming from the streamer.

[hvianna]

Well, I can't make sense out of this 😅 but would love to know if you find a solution!

[Weakky]

Well well well, we tried with the latest M1 Mac Mini and with a (supposedly) low-latency audio interface and it doesn't change much. We reduced the latency a bit but we still have some. At this point, I think you're right that this latency is inherently due to the FFT processing + smoothing. With an FFT size of 8192 but without smoothing, we're actually super close to having a latency that's not perceivable to the eyes (but it's super shaky/ugly unfortunately)

I'm wondering though: Do you think this latency is due to JS being too slow on the FFT processing/computation in general or due to some of the browser API being slow?

I've tried a native app (https://www.soundspectrum.com/whitecap) and we're indeed getting 0 latency. It almost makes me wanna create a simpler version of audioMotion in C++ or something. I still, to this day, haven't found anything close to audioMotion in terms of beauty

[hvianna]

@Weakky Thanks for the update. I don't think it is a performance issue.. most likely the latency is caused by some buffer which the API gives us no control of. But have you tried different browsers? Chromium-based browsers (like Chrome and Brave) seem to have the best JS performance these days.

I still, to this day, haven't found anything close to audioMotion in terms of beauty

😊 Wow, that makes me really happy! The lack of a good looking (and somewhat accurate) spectrum analyzer software was exactly what drove me to start working on audioMotion.

Can I use this quote (and attribute it to your GitHub user) in a "user testimonials" section in the docs? 😁

[Weakky]

Can I use this quote (and attribute it to your GitHub user) in a "user testimonials" section in the docs? 😁

Haha, please, be my guest!

FWIW, here's a video of the result: https://www.youtube.com/watch?v=sDUXOyEH9HM (might get striked very fast...)

But have you tried different browsers?

Yeah, I tried with Chrome and Firefox. Can't say I did any scientific performance benchmarks but visually, it seemed like Firefox was actually faster than Chrome.

Most likely the latency is caused by some buffer which the API gives us no control of

Been recently trying to create a simple version of AudioMotion with JUCE in cpp. I replicated your tempered scale + pre-compute of bars etc etc. I currently have something that gives similar results than AudioMotion (minus the gradients and smoothing for now) BUT for whatever reason, doing an FFT of size > 2048 makes the app drastically lose FPS... And with an FFT size below 8192, the result doesn't look great at all in the low ends :(. Trying to figure that out, I'm confident I'll get something working at some point. The result's just too incredible to give up.

[hvianna]

Love the demo video, nice setup you got there! I tried recording from the TV before but the image was too bright and colors were all messed up.. now that I've seen your video I must try it again, it really looks much cooler than just capturing the PC screen!

BUT for whatever reason, doing an FFT of size > 2048 makes the app drastically lose FPS... And with an FFT size below 8192, the result doesn't look great at all in the low ends :(.

Yes, I've found 8192 to provide the best balance between low frequency detail and time responsivity. Maybe you just need a faster FFT library now. I've heard PFFFT (mirror on GitHub) is pretty famous for its performance.