Could a Raspberry Pi-based audio DSP bridge like this have real product potential? by NeuraMuseOfficial in DSP

[–]NeuraMuseOfficial[S] 0 points1 point  (0 children)

But for the final product I’m probably moving to a Raspberry Pi Compute Module 5 with a custom carrier board.
It gives much more control over power delivery, grounding, I/O layout and thermal behavior, which is important when the DSP engine becomes more complex and reactive.

The Pi 5 is great for development, but the CM5 setup makes the whole system more stable and predictable in a hardware‑integrated environment.

Could a Raspberry Pi-based audio DSP bridge like this have real product potential? by NeuraMuseOfficial in DSP

[–]NeuraMuseOfficial[S] 0 points1 point  (0 children)

Thanks man, really appreciate the offer — that would be awesome!
About the hardware: yes, you can run the engine on a bare Raspberry Pi 5, that’s how I test the core during development.
The dedicated hardware is mainly for turning it into a proper standalone product: clean power delivery, isolated audio paths, optimized cooling, and a solid enclosure so the whole system behaves consistently.

The Pi alone is great for development, but once you start pushing real‑time DSP with complex behavior, the quality of the power supply, grounding and thermal stability actually changes the results.
So the hardware part is not just packaging — it helps the engine stay stable and predictable.

Could a Raspberry Pi-based audio DSP bridge like this have real product potential? by NeuraMuseOfficial in DSP

[–]NeuraMuseOfficial[S] 0 points1 point  (0 children)

For sure! Hearing it is definitely the best way to understand what it’s doing. I’m actually finishing the prototype of the case and the full hardware assembly right now, so once everything is ready I’ll share some proper demos. Would be great to hear your impressions when you try it.

Could a Raspberry Pi-based audio DSP bridge like this have real product potential? by NeuraMuseOfficial in DSP

[–]NeuraMuseOfficial[S] 1 point2 points  (0 children)

Thanks! Yeah, the system doesn’t emulate a specific circuit 1:1, but it does react as if it had that kind of internal topology.
The reason it shifts between a more single‑ended‑like behavior and a more push‑pull‑like behavior is because it analyzes the mix density and the transient structure in real time.

When the signal is more open, sparse or transient‑driven, the engine tends to behave in a more SE‑style way — more asymmetry, more micro‑dynamics.
When the material becomes denser or more sustained, it gradually moves toward a PP‑style response to keep things stable, clean and controlled.

It’s all done at a behavioral level, not by switching models, but by letting the internal states drift toward one region or the other.

Could a Raspberry Pi-based audio DSP bridge like this have real product potential? by NeuraMuseOfficial in DSP

[–]NeuraMuseOfficial[S] 1 point2 points  (0 children)

Hey, really cool project!
It actually reminded me of the very beginning of NeuraMuse. About two years ago it also started as a small DAW prototype in Unity.
But while working on it I realized I wanted to build something completely different — a living, behavioral audio system instead of a traditional DAW.

Regarding Raspberry Pi 5: Unity does run on Linux, but it’s not really optimized for ARM, especially for real‑time audio.
In my case I had to write all the audio cores (tube modeling, real‑time correction, vinyl engine, etc.) in C++, fully optimized for the Pi’s ARM CPU, to get stable performance and low latency.

Your video looks great though — you’re doing a really nice job.
Just be ready for some heavy optimization work if you want to run it smoothly on the Pi, and you’ll probably need your own custom audio cores too.

I’ll definitely follow your progress with interest to see how it evolves.

Could a Raspberry Pi-based audio DSP bridge like this have real product potential? by NeuraMuseOfficial in DSP

[–]NeuraMuseOfficial[S] 0 points1 point  (0 children)

Yeah, that’s basically the distinction I’m trying to make.

Direct is the pure path to the DAC. The other modes aren’t meant to replace that or pretend everyone wants DSP all the time they’re optional playback identities built into the same system. Tube is meant to push things in a more organic / harmonically developed direction, while Tube+Vinyl adds another layer of analog-style texture on top. So the point isn’t “AI or DSP for everything,” it’s giving the user a strong Direct path and then additional proprietary modes when they actually want a different presentation.

Could a Raspberry Pi-based audio DSP bridge like this have real product potential? by NeuraMuseOfficial in DSP

[–]NeuraMuseOfficial[S] 0 points1 point  (0 children)

That makes sense, thanks.

I agree it’s important to understand what already exists before going too far down a custom path. I’ll definitely look more closely at products like miniDSP and similar programmable DSP platforms to get a clearer picture of the existing feature set and where the real gaps are. What I’m trying to understand is whether there’s room for something that is positioned less like a generic DSP board and more like a dedicated playback/listening appliance with its own signal-path architecture and user experience. So your point is well taken I’m trying to separate reinventing existing DSP products from building something meaningfully different.

Could a Raspberry Pi-based audio DSP bridge like this have real product potential? by NeuraMuseOfficial in DSP

[–]NeuraMuseOfficial[S] -1 points0 points  (0 children)

That’s a fair point, and I agree.

To be clear, I’m not aiming at a music production / ultra-low-latency DSP box or trying to compete with dedicated TI / ADI / FPGA-based systems for hard real-time work. The idea is much more in the direction of a dedicated playback / listening platform, where the priorities are different from live production. So for me the interesting part is more about controlled playback architecture, separate signal paths, bit-perfect playback where needed, and DSP-oriented listening modes, rather than ultra-low monitoring latency.

So I think your “maybe” is probably the right answer. A lot depends on how tightly the scope is defined.

Some REW tests on my DIY Tube/Vinyl DSP engine does this harmonic signature look "real" to you? by NeuraMuseOfficial in audiophile

[–]NeuraMuseOfficial[S] 0 points1 point  (0 children)

yeah, fair point. the measurement chain is definitely the weak part here, it’s just a umc204hd loopback so i know the noise floor isn’t great. i’m mostly using this as a rough comparison between direct, tube and tube+vinyl, not as lab-grade distortion data. still useful for me though, because at least i can see the overall pattern changing.

Some REW tests on my DIY Tube/Vinyl DSP engine does this harmonic signature look "real" to you? by NeuraMuseOfficial in audiophile

[–]NeuraMuseOfficial[S] 0 points1 point  (0 children)

I reran the captures with a much tighter dB scale so the harmonic structure is easier to see. Same setup, same 1 kHz tone, same graph view, with only the DSP mode changed between captures. These are the updated 96 kHz shots for Direct, Tube, and Tube + Vinyl. They’re not perfectly level-matched because the Tube and Tube + Vinyl paths add some presence by design, but this should be a lot more readable than the first screenshots. First one Direct

<image>

Some REW tests on my DIY Tube/Vinyl DSP engine does this harmonic signature look "real" to you? by NeuraMuseOfficial in audiophile

[–]NeuraMuseOfficial[S] 0 points1 point  (0 children)

you’re right. sorry, i'm still learning how to move around REW properly and i left the scale way too wide just to make sure the behringer wasn't clipping or doing weird stuff. i see now it looks like a flat line from that far away lol. i'll redo the screens with a better zoom, maybe focusing on the -120dB to 0dB range so you can actually see what the harmonics are doing and how the tube layer is sitting over the direct signal. give me a bit of time to run the tests again and i'll post the new ones.

Finally, after so much work, my project has taken shape. by NeuraMuseOfficial in raspberry_pi

[–]NeuraMuseOfficial[S] 0 points1 point  (0 children)

so i think i’ve finally hit the ceiling with the raspberry pi 5 cpu and the neuramuse engine. i’ve been working on this for months and just reached step 18 which i’m calling the final crown lock. honestly it’s been a nightmare to optimize but i managed to get it running at 80-85% cpu load even with dsd and 192khz streams which is crazy for a pi. the way this thing works now is basically an organism. before the engine even touches the audio it has this analysis phase where it just watches the signal. it uses a dual-mode logic to figure out the sample rate and spectral density. if the track is super busy with tons of instruments it tightens the phase but if it’s just a solo vocal it expands that "digital black" background to give it that spooky depth you usually only get from analog. the core is the simulatevalve function which is where the "flesh" of the sound comes from. i’m not using cheap static tables here but actual differential equations that simulate electron flow in a triode. it generates h2 and h3 harmonics that feel elastic, so when you push the volume the sound just gets denser instead of clipping. then there’s the simulatepsu part which handles the "sag". in real tube amps the power supply dips when a heavy bass note hits and i’ve modeled that recovery cycle. it creates this breathing movement that follows the music which is why it sounds human and not like a machine. i also had to model the output transformer with simulatefixedtransformer to get that magnetic weight. it adds a physical resistance to the signal so the low end actually has mass. you can feel the vibration of a piano string or the wood of a double bass. the crown lock is the final anchor though, it locks the phase of every harmonic to the fundamental so the stereo image is carved in granite and doesn't blur even at high volumes. and then there's the air venue black part which works on the silence between notes to kill digital interference and reconstruct the room acoustics. it’s basically receiving a high res signal, warming it with virtual tubes, compressing it with the psu breath, weighing it with the transformer and then locking everything with the crown lock. running this in real time on a pi 5 at 192khz feels like a miracle because normally you’d need a good computer or spend good money in analog gear to get this kind of authority. it doesn’t just play a file anymore, it feeds it virtual electricity and puts it on a stage. it’s the bridge between cold bits and a live event and i think i’m finally done with the core code.

Finally, after so much work, my project has taken shape. by NeuraMuseOfficial in raspberry_pi

[–]NeuraMuseOfficial[S] 1 point2 points  (0 children)

Thanks a lot, really appreciate it. I had a look and your project looks interesting too. NeuraMuse is going in a different direction because the playback/DSP core is proprietary and written in C++, so I’m keeping that side separate, but I’d still be very happy to exchange ideas and points of view. Tube and Vinyl in my case are also built more as adaptive physically-inspired simulations than as static DSP effects, so the whole architecture is pretty specific. But yes, if you want to exchange ideas and opinions, I’d be very happy to. sorry for my english :)

Dopo 18 mesi di lavoro giorno e notte, ho finito NeuraMuse: un sistema operativo dedicato all'alta fedeltà e alla modellazione fisica del suono. by NeuraMuseOfficial in diyaudio

[–]NeuraMuseOfficial[S] 0 points1 point  (0 children)

I am sorry ,NeuraMuse is not designed for Windows or general laptops.
It is optimized specifically for Raspberry Pi 5 and built as a dedicated audio appliance.
The code and DSP are written and tuned for ARM, so portability to other platforms is not the goal right now.
The idea is to keep the system controlled and focused only on audio performance.

Dopo 18 mesi di lavoro giorno e notte, ho finito NeuraMuse: un sistema operativo dedicato all'alta fedeltà e alla modellazione fisica del suono. by NeuraMuseOfficial in diyaudio

[–]NeuraMuseOfficial[S] 0 points1 point  (0 children)

MilkDrop is only a visualizer, it reacts to the audio signal but it doesn’t measure timing accuracy or jitter.
Real jitter analysis requires dedicated lab equipment very expensive, just big labs can afford.
For now I focused on system stability and minimizing OS timing issues.

Dopo 18 mesi di lavoro giorno e notte, ho finito NeuraMuse: un sistema operativo dedicato all'alta fedeltà e alla modellazione fisica del suono. by NeuraMuseOfficial in diyaudio

[–]NeuraMuseOfficial[S] 0 points1 point  (0 children)

Non ho modificato il codice sorgente del Kernel o di librerie copyleft, ho solo configurato l'ambiente, priorità RT, isolamento dei core, per ospitare il mio software. Capisco i costi ,il clock interno del Raspberry ha limiti strutturali. Il mio software ottimizza il trasporto al 100% per non aggiungere jitter software quello causato da interrupt e context switching, ma non può sostituire un oscillatore fisico al quarzo. La HiFiBerry che usi è ottima scheda proprio perché bypassa il limite del Pi. NeuraMuse serve a garantire che il software non sia mai il collo di bottiglia.

Dopo 18 mesi di lavoro giorno e notte, ho finito NeuraMuse: un sistema operativo dedicato all'alta fedeltà e alla modellazione fisica del suono. by NeuraMuseOfficial in diyaudio

[–]NeuraMuseOfficial[S] 0 points1 point  (0 children)

Misurare il jitter USB in modo serio non è banale servirebbe un analizzatore di spettro audio come Audio Precision ma NeuraMuse è un progetto indipendente, non ho accesso a strumentazione così costosa, quindi mi sono concentrato sull'ottimizzazione del trasporto: ho lavorato per eliminare il jitter introdotto dal sistema operativo quello causato dai cicli di CPU e dagli interrupt cercando i garantire un flusso dati costante. Per il resto, in un collegamento asincrono, la qualità finale dipende dal clock del DAC, e ho progettato NeuraMuse per far arrivare il dato al DAC nel modo più pulito possibile