I implemented Multi-protocol audio transmitter that repurposes the Parallel IO peripheral on the ESP32-P4 to synthesize digital audio output signals, clocked by the APLL for sample-accurate timing.
We chain three peripherals together in ways they were never designed for:
Peripheral 1 -- APLL: Generates a precise audio master clock. Standard audio frequencies (12.288 MHz for 48 kHz, 11.2896 MHz for 44.1 kHz) are native to this PLL.
Peripheral 2 -- I2S: Misused purely as a clock conduit. We allocate an I2S TX channel, configure it with I2S_CLK_SRC_APLL, but never write audio data to it. Its only job is to output MCLK on a GPIO pin. The I2S BCLK/WS/DOUT pins are left disconnected (or optionally used for real audio output as a "free" bonus).
Peripheral 3 -- PARLIO: Designed for parallel display interfaces (LCD, LED matrices). We repurpose it as a multi-channel I2S transmitter. It reads the MCLK from the GPIO (via the GPIO matrix), divides it down to BCLK, and shifts out pre-computed bit patterns from DMA buffers on every BCLK cycle.
This way we can get upto 304 channels and rates like 192kHz without a lot of CPU involvement.
In the future, when ESP-IDF implements the PARLIO RX mode, we will implement also receiving. Also, the Bitscrambler Peripheral could be used to encode data for S/PDIF and ADAT outputs.
I’ve been working on a development environment for experimenting with DSP algorithms for synthesizers and audio effects.
The project is called dsplab. It’s a browser-based DSP lab built around the Vult language. The idea is to prototype oscillators, filters, envelopes, and other audio algorithms without having to build a plugin or embedded firmware project first.
You write DSP code in Vult and run it in an isolated AudioWorklet engine. The environment includes a set of tools for inspecting signals and internal state while the algorithm is running.
Currently it includes things like:
* dual-trace oscilloscope
* logarithmic spectrum analyzer
* logic analyzer for inspecting internal variables
* telemetry viewer for real-time parameter data
* signal generators and a small sequencer for testing patches
There is also an integrated LLM agent that can work on the DSP code. It can read compiler errors, write or modify functions, fix broken code, and iterate on implementations while observing telemetry and spectrum data from the running algorithm. The idea is that it can autonomously try improvements or fixes until the code compiles and behaves as expected.
The main goal is to use this as a sandbox for DSP ideas before moving them into hardware projects.
When an algorithm is finished it can be exported as C++ suitable for embedded targets such as Teensy, Daisy, or custom audio hardware.
Still evolving, but I’d be interested in feedback from people working on synths, plugins, or embedded audio DSP.
Show HN: Vult-O-Mat – AI-Assisted DSP Workbench and Synth/FX Creator
Vult-O-Mat is a complete, browser-based diagnostic workbench for building synthesizers and audio effects. It uses the Vult DSP language (OCaml-style DSL) to create highly optimized algorithms that can be instantly executed in the browser or exported as C++ for embedded hardware like Daisy, Teensy, or custom Eurorack modules.
The workbench integrates an autonomous AI Agent that acts as a collaborative sound designer. It is capable of surgical code refactoring, fixing feedback loop stability, and performing real-time spectral analysis to verify its own work.
Key Features:
AI-Assisted Creation: Integrated LLM partner that understands DSP principles and OCaml-style syntax for collaborative synth and effect development.
Diagnostic Laboratory: Logarithmic FFT, dual-trace oscilloscope, and multi-trace logic analyzer for internal state monitoring and frequency verification.
Zero-Latency Prototyping: 128-sample block execution in isolated AudioWorklets with high-frequency telemetry.
Melodic Testing: 16-step expressive sequencer with accent and slide support for polyphonic and legato verification.
Embedded Export: One-click transcompilation to optimized C++ headers for hardware deployment.
I built an open-source AI Gateway that sits between your apps and LLM providers
I needed a way to give different clients (apps, users, teams) their own API keys and LLM provider settings without deploying separate proxies. Most solutions required complex setup or were tied to specific providers.
What it does:
- Single OpenAI-compatible endpoint (/v1/chat/completions)
- Each client gets their own API key with independent config:
- Backend provider (Gemini, OpenAI, Anthropic, Ollama, LM Studio, etc.)
- Upstream API key
- Base URL override (for local models)
- Default model
- Model whitelist
- System prompt injection
- Rate limits & token quotas
- Built-in admin dashboard with real-time stats via WebSocket
- Auto-discovers models from backends (Ollama, LM Studio)
The key insight: all provider configuration is per-client, not global. A client using LM Studio never touches your OpenAI quota. A client with a Gemini key stays isolated.
Tech: Go, SQLite, chi router, WebSocket for live dashboard updates.
Demo: admin UI shows live request streaming, token usage, model breakdown.
Would love feedback on the architecture - especially the per-client provider model. Is this useful for others running multiple LLM backends?
I am planning to add other restreaming options such as RTMP or HLS. So far, my test stream is running for more than 10h and did not have a single dropout.