sylwester

I got AES67 running and released on a cheap ESP32-P4 MCU via Ethernet.

Is there some writeup available or just the Twitter?

I run my own personal homelab, some off-site private infrastructure, company networks.

thanks!

I will check if it is possible to build for Android.

If it is possible and Apple accepts the app.

I read HN on my phone every day and never really settled on a reader, so I wrote my own and finally tidied it up enough to put out there.

It's plain SwiftUI with no third-party dependencies. A few things I spent the most time on:

Comments are parsed and drawn as native text instead of being dumped into a web view. Links, italics, quotes and code blocks behave like the rest of the OS, text selection works, and threads collapse instantly. The whole comment tree comes back from the Algolia API in a single request, which felt a lot nicer than walking the Firebase API node by node.

Accessibility. Nothing depends on color on its own, so points, read state and selection all carry a shape or an icon too. VoiceOver reads each story as one coherent element with proper actions, Dynamic Type and Reduce Motion are respected, and there's a color-blind mode. The first-run setup actually looks at your device's accessibility settings, switches on the matching options, and tells you what it changed instead of making you hunt for them.

Then the usual things you'd expect: Top/New/Best/Ask/Show/Jobs, search, saved stories, read tracking, an in-app reader, light and dark, and a handful of accent colors.

It only talks to the public HN APIs, there's no account and nothing is tracked. Source and screenshots are in the repo.

I'd most like feedback on the comment rendering and the accessibility choices, since those were the parts I cared about getting right. Happy to answer anything about how it's put together.

I have just released a online book on that, free of charge: https://github.com/DatanoiseTV/practical-reverse-engineering

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.

Repository: https://github.com/DatanoiseTV/vult-o-mat Vult Language: https://vult-dsp.github.io/vult/

Thank you. Looking forward for your feedback. Any wishes? I wanted to implement model rerouting next.

Yes, kind much with a few additions.

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've added several improvements over the last couple of days.

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.

Thank you so much. I just added a lot of new features and polished some old ones now.

Here is a little writeup on medium.com: https://syso42.medium.com/tinyice-how-i-created-a-single-bin...

XML-based big configuration, confusing for new users. No "run a single binary" and that's it :)

This should be working in tinyice without issues. Feel free to test it and if the problem is also present, I will fix it.

I've just added better docs, the CI/CD pipeline is now releasing binaries for all major platforms and custom ACME URLs are supported.

That should work! :) Just added m3u/m3u8 support.

thank you for trying. I have added it in the latest release.

I built TinyIce as a vibing side project to spin up an Icecast2-compatible server in seconds, because I was frustrated with IceCast. One static Go binary, embedded assets, auto-generated creds on first run, built-in ACME (Let’s Encrypt), relays, multi-tenant admins, Prometheus metrics, and a modern web UI.