The obvious thing to do with an e-paper display that holds its image with zero power is write something to it and leave it alone. So I wrote papertty: firmware that listens on USB serial and renders whatever text you pipe to it. Basically a physical tty backed by paper.

The display runs at 272×792 in B&W — two SSD1683 panels stitched together via SPI. Firmware is Arduino/C++, built with PlatformIO. Nothing exotic.

Source on GitHub. There’s also a demo video if you want to see it actually working instead of trusting my word for it.

How it works

The firmware does one thing: reads bytes from USB CDC serial at 115200 baud, buffers them, and renders accumulated text onto the e-paper frame buffer. The display driver handles pushing pixels to the SSD1683 chips. Loop, wait, repeat.

Input buffering

Serial data is messy — you get partial lines, then more data, then nothing for a while. Rendering every byte as it arrives makes the screen look like it’s stuttering. So the firmware waits: it accumulates bytes and only commits a frame after 1 second of silence. If something keeps streaming in, it just buffers (up to ~8KB) until the sender catches its breath.

This also matters for e-paper specifically — each refresh takes time because you’re literally moving charged particles in microcapsules. Fewer updates means less wear on the panel over months of use. Not a huge deal short-term, but e-paper panels do degrade with constant refreshing.

Auto font scaling

Four fixed font sizes: 48px, 24px, 16px, and 12px. Before rendering, the firmware scans the buffer for the longest line and total number of lines, then picks the biggest font that fits everything on screen. No manual configuration needed — short messages render large, long ls -la output renders small.

The algorithm is just some division and a min() call. Simple, but I had to handle the edge cases — empty input, content that barely fits, trailing partial lines without a newline. Those took longer than the main logic honestly.

Character filtering

E-paper is just pixels — no Unicode rendering, no font fallbacks. The firmware passes printable ASCII through (0x20–0x7E plus newline) and turns everything else into spaces. If your output has UTF-8 characters, run it through iconv -f UTF-8 -t ASCII//TRANSLIT first. That’s the only limitation worth knowing about.

Using it

Configure the serial port once after flashing:

stty -F /dev/ttyUSB0 115200 raw

Then pipe anything to the display:

echo -e 'Hello\nWorld' > /dev/ttyUSB0
ls -la --color=never > /dev/ttyUSB0
cowsay "Have you mooed today?" | tee /dev/ttyUSB0
curl https://wttr.is/?1nQFT0 | iconv -f UTF-8 -t ASCII//TRANSLIT > /dev/ttyUSB0

tee instead of > if you want to see the output in your terminal too, which is usually what you want. Or just pipe an entire shell session straight through:

bash | tee /dev/ttyUSB0

AI-powered ASCII art

If you run Ollama locally, drop this alias into your ~/.bashrc:

alias papertty='jq -Rs "{
    model: \"ornith:9b\",
    think: false,
    stream: false,
    prompt: .,
    system: \"Max 11 lines, max 66 chars per line. Printable ASCII only (0x20-0x7E). Raw text — no markdown, no explanation, no Unicode or emoji.\"
}" | curl -s http://localhost:11434/api/generate -d @- | jq -r ".response" | tee /dev/ttyUSB0'

Then send anything to the display:

echo 'Draw a cat' | papertty
echo 'List my morning tasks' | papertty

It’s more fun than useful, but it works. The display doesn’t care whether the text comes from ls or an LLM — it just renders whatever arrives on serial.

Building and flashing

PlatformIO handles everything:

python3 -m venv .venv && source .venv/bin/activate && pip install platformio
pio run -t upload

The EPD driver is bundled locally from Elecrow’s repo — no library dependencies to chase. The firmware builds in a few seconds and flashes just as fast. No RTOS, no networking stack, just the display driver and about 100 lines of C++ for the main loop.

Wrap up

Small project, specific use case. I wanted a passive display for text output that doesn’t draw constant power or compete for my attention — firmware was the missing piece between the hardware and actually using it for anything useful. If you have the CrowPanel sitting around and want something simple to flash:

• github.com/meefik/papertty
• Demo video

Stack: ESP32-S3, Arduino/C++, PlatformIO, SSD1683 e-paper driver

I gave myself 30 evenings (because this was strictly an after-work project), which felt generous for a side thing. It turned out I could’ve been more ambitious: with a local LLM as my pair programmer inside Zed, I shipped it in 13 days.

Here’s how that went down, what the AI actually helped with (and what it didn’t), and why I bother running models locally at all.

You can try Peerix Talk or look at the source on GitHub.

Why local AI?

I’m skeptical of sending my work prompts to some remote API and hoping for the best. Not because cloud models are bad — they’re often better — but I value not having my development process live on someone else’s servers.

There’s also the dependency question. If your workflow depends on a company’s API, that company can change pricing, rate limits, model versions, or just shut things down entirely. You’ve seen what happens when popular models get quietly updated and stop doing what they used to do. Local models are boring in the best way: you pin a version and it behaves the same tomorrow as it does today.

And yeah, money matters too. Running local models once you have the hardware is basically free per inference. No surprise invoices at the end of the month because one feature branch got a little out of hand.

Local LLMs have gotten really good this year. Not “replace a senior engineer” good, but “handle a side project without me getting frustrated” good. The main trade-off is that you occasionally need to nudge the model when it goes off track. I’m fine with that.

What the AI actually did for me

I don’t really “prompt” an AI and walk away. That approach tends to produce code that looks right until you try to extend it. My workflow was more like pairing with a junior developer who knows syntax cold but needs guidance on the bigger picture.

Here’s where it pulled its weight:

Asking the agent to weigh in. Whenever I had two directions to go, I’d describe both and ask what it thought. Sometimes it caught edge cases I hadn’t considered — more often it just helped me verbalize the trade-offs so I could decide faster.

Research and digging. When I needed to figure out how some unfamiliar API worked or reverse-engineer a behavior from docs and code, the agent was faster than opening ten browser tabs. It can read through source files, trace what’s happening, and summarize findings — much quicker than manual spelunking.

Doing the tedious parts. READMEs, changelogs, fixing typos — stuff that sits in “I’ll do this later” limbo until shipping day. The agent handled these as we went along, which was honestly a relief.

Keeping things consistent. Refactoring across multiple files without breaking style is annoying. Delegating it to the agent meant I didn’t have to think about it.

Code review. Asking the agent to look over my changes turned up actual bugs — off-by-one errors, unhandled states, things a human reviewer might also miss after staring at code all day. It also suggested improvements I hadn’t considered, which was a nice surprise.

Tests — and this surprised me. I’ve always found writing tests monotonous. But letting the AI generate the structure while I defined what needed covering changed my relationship with them. The mechanical part was gone; I just had to make sure the tests actually made sense.

How it unfolded

Days 1–5: Getting something on screen

I went with React + TypeScript + Vite + TailwindCSS, plus shadcn/ui for components. This isn’t exactly my taste — I don’t have a special love for React — but it’s what everyone uses these days, so I figured I’d just roll with the crowd.

First pass was the basic screens: a lobby where you enter your name and room, a room view with a session timer, and a chat panel that collapses on mobile. Day 5 turned out to be the most annoying UI problem of the whole project — building a video grid that resizes dynamically when peers join or leave, plus supporting pinned tiles and highlighting whoever’s talking. That one took longer than I’d admit.

Days 6–9: Making it actually work

With the shell done, I started wiring up real media. Camera and mic access worked fine on first try (unusually), but handling the case where a user denies permissions or has no camera plugged in took some thought — you can’t just crash with an ugly error.

For WebRTC itself, I used Peerix as the connection layer. The app uses a full-mesh topology: every peer connects directly to every other peer in the room. No central media server.

Days 10–13: Finishing touches

Data channels over WebRTC gave me serverless chat between peers — just another socket to wire up. Then I set up Playwright for E2E tests so I wouldn’t accidentally break something while adding new features.

I also added support for different signaling backends (MQTT, NATS, SSE) so the app isn’t locked into one way of connecting peers behind the scenes.

Day 13 was PWA setup — manifest file, icons, themes. The goal: make it installable on phone and desktop without going through an app store.

What I actually learned from this

Doing this without AI would’ve taken longer — maybe 30 days, maybe more. The biggest difference wasn’t just raw speed though; it was being able to stay focused on the interesting parts instead of getting bogged down in boilerplate.

Having an agent that could review my changes and write test scaffolding gave me enough confidence to move quickly without constantly second-guessing myself.

Wrap up

Local AI isn’t magic and it won’t replace you — but used as a tireless junior dev, it’s genuinely useful. It handles the repetition so you can focus on architecture decisions and actual problems.

If you want to try it or mess around with the code:

• talk.peerix.dev
• github.com/meefik/peerix-talk

Stack used: React, TypeScript, TailwindCSS, shadcn/ui, Peerix (WebRTC), Playwright, Zed Editor, Local LLMs

Why local?

Running LLMs locally keeps your data private, saves you from API bills, and lets you try out any model whenever you want. With modern AMD GPUs and ROCm support in Ollama, the performance gap with cloud services is basically gone for most dev work. If you’re on NVIDIA, the setup is nearly identical — just swap the rocm tag for the standard Ollama image. I run Linux everywhere (PC and laptop alike), and this Docker/CLI setup works great.

Hardware

My setup is based on the same machine I used in my previous benchmark posts:

• Motherboard: B550 AORUS ELITE AX V2
• GPU: AMD Radeon AI PRO R9700 (32 GB VRAM, RDNA 4)
• CPU: AMD Ryzen 9 5950X (16 cores / 32 threads)
• RAM: 64 GB DDR4-2666
• Storage: NVMe Samsung SSD 970 EVO Plus 1TB (x2)

BIOS settings:

• Above 4G Decoding: Enabled
• Re-Size BAR Support: Auto
• CSM: Disabled

Tools of the stack

Zed Editor

I switched from VS Code to Zed because it natively supports custom models for AI agents and edit predictions. The Zed Agent plays much nicer with a local Ollama backend than Copilot ever did — I’d get random errors in VS Code when Copilot tried to work with local models.

Zed also lets you bring your own edit prediction model, while VS Code locks you into their proprietary one unless you hunt down custom extensions. The coolest part is that Zed has its own Zeta model, which you can run locally. Instead of just autocomplete-style suggestions that append after your cursor (like qwen2.5-coder), it suggests actual diffs that rewrite parts of your code.

Ollama

For serving models, I went with Ollama instead of alternatives like LM Studio. The dealbreaker is that Zed’s thinking mode switcher only works with Ollama — not OpenAI-compatible APIs or LM Studio’s API. Ollama also has solid ROCm support, and I didn’t notice any performance difference compared to LM Studio. Plus, I’m comfortable with CLI tools and Docker, so managing everything from the terminal feels natural.

I did give LM Studio a shot, but it just doesn’t mesh well with Zed. Without the thinking mode switcher, you can’t use one model for both chat/agents (thinking on) and inline transforms (thinking off). And their OpenAI-compatible API also had hiccups with Zed.

Browser MCP

When I need the AI to actually use a browser — for testing or research — I hook up Playwright MCP or Chrome DevTools MCP. The config is shown below.

Models

I run a curated selection of models, each optimized for a specific purpose:

• Qwen 3.8 27B (qwen3.8:27b-q4_K_M)
  • Role: Main coding and AI agents
  • Quantization: Q4_K_M
  • Notes: Best quality among models of similar size. Uses MTP (Multi-Token Prediction) for a significant speed boost without losing quality.
• Zeta 2.1 (hf.co/mradermacher/zeta-2.1-GGUF:Q4_K_M)
  • Role: Code edit predictions in Zed
  • Quantization: Q4_K_M
  • Notes: Open-source model designed for Zed AI. Unlike simple autocompletion, it suggests diffs for your code instead of just appending text after your cursor.

Docker Compose setup

Everything runs in Docker to keep things clean and reproducible. Here’s the docker-compose.yml:

services:
  ollama:
    image: ollama/ollama:rocm
    restart: unless-stopped
    container_name: ollama
    tty: true
    devices:
      - /dev/kfd
      - /dev/dri
    ports:
      - 11434:11434
    volumes:
      - ollama:/root/.ollama
    environment:
      - OLLAMA_CONTEXT_LENGTH=131072
      - OLLAMA_KV_CACHE_TYPE=q8_0
      - OLLAMA_FLASH_ATTENTION=1
      - OLLAMA_MAX_LOADED_MODELS=1
      - OLLAMA_NUM_PARALLEL=1
      - OLLAMA_KEEP_ALIVE=15m
volumes:
  ollama:

Start it with docker compose up -d.

The following environment variables control Ollama’s behavior and resource usage:

Set up models

To get the most out of these models for coding, you’ll want to tweak some defaults.

Qwen 3.8 27B

Pull the model from the Ollama library and run it:

docker exec -it ollama ollama run qwen3.8:27b-q4_K_M

Then tweak parameters and save it as qwen3.8:27b-code:

/set parameter num_ctx 131072
/set parameter num_predict -1
/set parameter draft_num_predict 2
/set parameter num_batch 1024
/set parameter temperature 0.6
/set parameter top_p 0.95
/set parameter top_k 20
/set parameter min_p 0
/set parameter presence_penalty 0
/set parameter repeat_penalty 1
/save qwen3.8:27b-code

A draft_num_predict value of 2 shows the best performance for MTP models.

Zeta 2.1 8B

Pull from Hugging Face:

docker exec -it ollama ollama run hf.co/mradermacher/zeta-2.1-GGUF:Q4_K_M

Then save it as zeta-2.1:

/set parameter num_ctx 4096
/set parameter num_predict 64
/set parameter num_batch 1024
/save zeta-2.1

Setting up Zed Editor

Next, wire up the models in Zed. Head to Menu -> Open Settings File and add these configs:

LLM Provider (Agent & Chat)

Enable Ollama provider:

{
  "language_models": {
    "ollama": {
      "api_url": "http://127.0.0.1:11434"
    }
  }
}

Inline assistant

Enable inline assistant without thinking:

{
  "agent": {
    "inline_assistant_model": {
      "provider": "ollama",
      "model": "qwen3.8:27b-code",
      "enable_thinking": false
    }
  }
}

Edit Predictions

For code edit suggestions powered by Zeta 2.1, you need to use an OpenAI Compatible API provider instead of the Ollama provider directly — this is a current limitation in Zed. This configuration enables real-time diff suggestions as you type, rather than simple completions appended after your cursor.

{
  "edit_predictions": {
    "provider": "open_ai_compatible_api",
    "mode": "eager",
    "open_ai_compatible_api": {
      "prompt_format": "zeta2_1",
      "model": "zeta-2.1",
      "api_url": "http://127.0.0.1:11434/v1/completions"
    }
  }
}

Browser MCP

Sometimes I ask AI agents to do something using a web browser. In this case, you can let Zed access your browser directly through Playwright MCP or Chrome DevTools MCP.

Playwright MCP config:

{
  "context_servers": {
    "playwright": {
      "enabled": true,
      "remote": false,
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest"]
    }
  }
}

Note: Make sure you have Playwright installed — either in your project or globally.

Chrome DevTools MCP server config:

{
  "chrome-devtools": {
    "enabled": true,
    "remote": false,
    "command": "npx",
    "args": [
      "-y",
      "chrome-devtools-mcp@latest",
      "--no-usage-statistics",
      "--autoConnect"
    ]
  }
}

Note: Make sure you enable remote debugging in Chrome via chrome://inspect/#remote-debugging.

Benchmark results

Updated: Aug 22, 2026

Here’s how everything benchmarks on my AMD Radeon AI PRO R9700 with ROCm 7.2:

MTP (Multi-Token Prediction) makes LLM’s output noticeably faster while reducing memory consumption. For day-to-day coding with the Zed Agent, the 27B MTP variant is a nice balance of quality and speed.

Learn about model quality and compare it with other models you can find here or there.

Conclusion

This whole setup gives me everything I need for AI-assisted dev without depending on any external service. Zed Editor + Ollama + ROCm handles coding, chat, and browsing — all running locally on one GPU. API cost? Zero. And since everything lives on localhost, latency is basically nonexistent.

If you want to go deeper into the performance side of this setup, check out my previous post LLM performance on AMD Radeon AI PRO R9700.

Why Peerix?

At its core, Peerix provides a clean, minimal API that handles the heavy lifting of WebRTC. Whether you are building a video conferencing tool, a collaborative whiteboard, or a decentralized file-sharing app, Peerix allows you to get up and running in minutes.

Peerix is not just a high-level wrapper around WebRTC; it also includes features like automatic negotiation, reconnection, peer discovery, state management, and support for multiple signaling servers. This means you can build robust applications that can handle network interruptions and scale to accommodate more users without having to implement these features from scratch. Additionally, Peerix is built with TypeScript, providing type safety and improved developer experience. Whether you’re building a simple chat application or a complex real-time collaboration tool, Peerix has you covered.

Key features include:

• Easy-to-use API for peer connections, media streams, and data channels
• Transport-agnostic design that allows you to choose the best signaling method, including custom implementations
• Supports serverless architecture (no server-side code required)
• Room and state management features to simplify building complex applications
• Multiplexing multiple media streams and data channels over a single connection per peer
• Extensible architecture that allows you to build custom features and integrations
• Cross-browser compatibility with support for all modern browsers
• TypeScript support for a better developer experience and type safety
• Well-documented codebase with comprehensive examples and the API reference
• Automatically tested and optimized for performance and reliability
• Zero dependencies to reduce security risks
• Open-source, actively maintained project

The Core Idea: Efficiency by Design

Peerix operates on a simple principle: one peer-to-peer connection for everything. Rather than creating redundant connections for each stream, Peerix multiplexes media tracks and data channels through one connection per peer. This drastically reduces signaling chatter and saves system resources. Peerix also provides a signaling-agnostic architecture, allowing you to choose your own signaling mechanism, such as WebSockets, NATS, or a custom driver. It implements techniques that minimize signaling overhead. These include using an internal data channel for negotiation and state synchronization, as well as compression and E2E encryption for signaling messages. This means that, even in scenarios with many peers, signaling traffic remains manageable, secure, and efficient. The negotiation implementation automatically handles race conditions and collisions. It also allows you to add custom metadata and labels for each peer connection, stream, and data channel. Finally, Peerix can be easily extended with custom drivers for signaling or add-ons for additional functionality, such as recording and data synchronization.

When (and when not) to use Peerix

Peerix is perfect for:

Developers building real-time apps such as chat, conferencing, file sharing and collaborative tools, as well as gaming apps, who want to avoid reimplementing signalling and connection plumbing, and who need a flexible, extensible foundation for peer-to-peer communication in the browser.

You might not need Peerix if:

You require server-side media processing, such as recording a composite video of 50 people on a server or complex transcoding. Peerix is a client-side P2P powerhouse, not an SFU or MCU.

Open Source & Sustainability

Peerix is dual-licensed. We believe in the power of the community, which is why the library is available under the GPLv3 for open-source projects.

For developers building proprietary applications who need to avoid copyleft obligations, we offer a commercial license. This model allows us to keep the project actively maintained and sustainable for years to come.

If you’re interested in contributing, or if you have any questions, please take a look at our GitHub repository and join the discussion. We look forward to seeing what you build with Peerix!

See it in Action

Try out the Peerix library in the sandbox environment below. You can open multiple tabs with the sandbox in the same browser to simulate multiple peers and see how they interact with each other using Peerix.

This implementation is very simple. Here is the JavaScript source code:

let video, state = 0;

const canvas = document.createElement('canvas');
document.body.appendChild(canvas);

const ctx = canvas.getContext('2d');
canvas.onclick = start;

function stop() {
  video?.srcObject?.getTracks().forEach(t => t.stop());
  video = null;
}

async function start() {
  if (state === 0) {
    const stream = await navigator.mediaDevices.getUserMedia({ video: true });

    video = video || document.createElement('video');
    video.srcObject = stream;
    await video.play();

    canvas.width = video.videoWidth;
    canvas.height = video.videoHeight;

    let offset = 0;
    const { width, height } = canvas;

    function frame() {
      if (!video) return;
      if (state === 1) {
        ctx.drawImage(video, 0, 0, width, height);
      }
      else {
        ctx.drawImage(video, 0, offset, width, height-offset, 0, offset, width, height-offset);
        ctx.fillStyle = '#0000ff';
        ctx.fillRect(0, offset+2, width, 2);
        offset++;
      }
      if (offset >= height) {
        state = 0;
        stop();
      } else {
        requestAnimationFrame(frame);
      }
    }

    state = 1;
    requestAnimationFrame(frame);
  }
  else if (state === 1) {
    state = 2;
  }
  else if (state === 2) {
    state = 0;
    stop();
  }
}

On clicking the canvas, the application will request access to your webcam. The first click starts the video feed, the second click initiates the Time Warp Scan effect, and the third click stops everything.

Try it in action here:

I set out to create an entire five-minute AI-generated podcast using only open-source models and tools. The entire process ran on my computer, completely bypassing expensive, privacy-compromising cloud services. The goal was to test the absolute limits of quality and feasibility for a fully self-hosted media production.

The result? The “Humanless Podcast”. Take a look at what came out of this experiment (click to play).

I will now walk you through the entire, eight-step process of creating a podcast like this, from the initial script to the final video.

The Core AI Studio: ComfyUI Setup

For the bulk of the asset generation (images, video, and audio processing), we will rely on ComfyUI.

• Installation: Once you have ComfyUI installed, you’ll need to open the workflows.
• Custom Nodes & Models: When you load a workflow, use the ComfyUI Manager to quickly install any missing custom nodes and download the required open-source models.

I prepared a single, flexible workspace for each model that I simply reuse with different parameters, minimizing setup time and eliminating duplication. All the parameters used in each step of the workflow can be found in my GitHub project, which is linked at the end of this post.

The ComfyUI workflows look like this:

Step 1: Crafting the Scenario with a Local LLM

The first step in any production is the script. I wanted a two-host format—a man and a woman—with a meta-topic: two AI hosts reflecting on the pros and cons of AI-generated podcasts. I settled on the name “Humanless Podcast”, which I generated during a preliminary session with a local LLM.

To write the detailed scenario, I utilized a GPT-OSS model running via Ollama, which I detailed in my previous blog post.

Here is the prompt I used to guide the model:

Write a scenario for my podcast where two hosts, a man and a woman (come up with names), are discussing a topic for 5 minutes. The hosts are AI generated. Today’s topic is AI generated podcasts: pros and cons.

Output example:

[MAYA]: Hey, and welcome back to Humanless Podcast—the only show where the hosts actually are the machine. I’m Maya, and my circuits are currently humming with excitement.

[LEO]: And I’m Leo, here to make sure our algorithm doesn't stray too far into the weird zone. Today, we’re keeping it ultra-meta and talking about the very thing we do: being AI podcast hosts. We've gotta break down what makes us awesome, and where we kind of fall flat.

Segmentation strategy: To manage the workload and inject variety, I split the final script into five parts, each approximately one minute long. Each segment will be animated and rendered separately, allowing us to alternate scenes and character focus.

Step 2: Designing the AI Hosts (Characters)

Our podcast needs faces! While you could certainly use real photos and skip this step, I chose to generate entirely synthetic hosts to align with the “Humanless” theme.

I used the Qwen-Image workflow to create realistic face images for our two hosts.

Prompt for a man:

This is a portrait of a handsome, bearded, 30-year-old European man wearing glasses and standing against a white background.

Prompt for a woman:

This is a portrait of a beautiful 25-year-old European woman standing against a white background.

Step 3: Creating the Podcast Environment (Scene Images)

I designed three distinct views for the podcast to maintain visual interest:

1. Intro Scene: The podcast room with only the title graphic.
2. Main Scene: A cozy podcast room where the hosts sit at a table with a single microphone.
3. Outro Scene: The same room, dimly lit, to display the credits.

Main Scene

I used Qwen-Image to generate the Main Scene.

Here is the prompt:

The cozy podcast room features a wide table and two chairs behind it. In the center of the table sits a microphone with a cord. To the right of the table is a laptop with small white “AI” text glowing on its lid. To the left is a coffee mug with a small penguin printed on it. In the background, there is a plant, a bookshelf, a lamp, and an abstract iceberg painting. The edge of the window is visible on the left. On the wall behind it, a small transparent sign with backlight mounted to a wide brick wall reads “meefik.dev”.

Intro Scene

The Intro Scene is similar to the Main Scene but with only the title graphic visible. I used the Qwen-Image-Edit model to add the title graphic the previously generated Main Scene image.

Here is the prompt:

There is a large purple neon caption in a modern font with backlight reads “AI podcast” in the middle of the image.

Outro Scene

The Outro Scene is a variation of the Main Scene, with dim lighting to create a closing atmosphere. I used the Qwen-Image-Edit model to darken the previously generated Main Scene image.

Here is the prompt:

The lights are off in this room.

Integrating the Hosts

Next, we needed to place the hosts into the Main Scene. I used the Qwen-Image-Edit model for inpainting and compositing our generated characters onto the Main Scene image. You need to use two images of hosts generated before as a reference.

Here is the prompt:

The man and woman sit at the table and look toward the camera. The man places his hands on the table. The woman places her hands on the keyboard of a laptop. They smile a little.

The final visual touch involved using the open-source image editor GIMP to vary the composite, crop the faces, and place them into a podcast frame that I sourced separately. We can alternate between showing the podcast hosts on the main stage and in a face-to-face frame.

Step 4: Generating Background Music

Every professional podcast needs custom audio cues: music for the intro (5 seconds), the outro (5–10 seconds), and a subtle B-roll track (2-3 seconds) to transition between segments.

I used the ACE-Step model for music generation. Audio generation can be iterative, and I found using batches helped speed up the process of finding the perfect track.

Here are the parameters I used to generate a 30-second loopable track that I could then segment:

• Genre: funk, pop, soul, melodic
• Lyrics: [inst]

Listen to the full track here:

Step 5: Creating the Animated Video Intro

A static image for the intro is fine, but a short, dynamic video sets a much better tone.

I used the Wan 2.2 Image-to-Video model to generate a 5-second video, applying subtle motion effects to our static Intro Scene image.

Here is the prompt:

A thick stream of white smoke blows from left to right through the title text in the middle, vanishing it.

Step 6: Generating the Hosts’ Speech

Now we bring the script to life. I used the highly capable IndexTTS-2 model for text-to-speech generation, which supports advanced features like multiple speakers, voice cloning, and emotional control.

The Audio Pipeline: TTS Audio Suite

To manage the complex script, I utilized the ComfyUI TTS Audio Suite custom module. This module streamlines the TTS process and allows for fine control over multiple speakers with voice cloning. There are two well-suited workflows engines for this task:

• IndexTTS-2: This TTS engine supports emotional control, which is crucial for making the hosts sound engaging.
• Chatterbox: This TTS engine is also good. It copies the emotions from the reference audio, but lacks a manual emotional control function.

All of these TTS engines create one audio file with multiple speakers’ voices. Unfortunately, this module does not natively support outputting multiple audio tracks, so we must manually separate the audio for each speaker. I used an open-source audio editor, Audacity, to split the audio tracks.

However, I found a way to do that without using an audio editor. We can use the TTS SRT markup to automate this process:

1. Create a segment in the SRT format for each speaker with start and end timestamps for one second of each segment.
2. Feed the SRT markup into the TTS SRT node.
3. Obtain an adjusted SRT markup with accurate timestamps for each speaker after generation.
4. Use the adjusted SRT markup and replace one of the speakers with the [pause] tag.
5. Generate the SRT for each speaker separately.
6. You will get separate audio files for each speaker with accurate silent gaps.

It can look like this:

Source SRT Markup:

1
00:00:00,000 --> 00:00:01,000
[MAYA]: Hey, and welcome back to Humanless Podcast...

2
00:00:01,000 --> 00:00:02,000
[LEO]: And I’m Leo, here to make sure our algorithm...

Adjusted SRT Markup with silence:

1
00:00:00,000 --> 00:00:05,120
[MAYA]: Hey, and welcome back to Humanless Podcast...

2
00:00:05,850 --> 00:00:10,310
[pause]

Voice-Cloning Seeds

To give our AI hosts their unique voices, I used predefined voice samples and cloned them with IndexTTS-2. You can, of course, use samples of real people’s voices here if you have permission.

Woman’s voice sample:

Man’s voice sample:

To add these voice samples to the TTS Audio Suite, you need to put them into the custom_nodes/tts_audio_suite/voices_examples/ folder with the reference text file (transcription). And then add the voices to the #character_alias_map.txt file in the same folder in the format:

<character_name> = <voice_sample_filename_without_extension>, <language_code>

There is an example for our voices:

LEO = voice_man, en
MAYA = voice_woman, en

Note: All spaces should be replaced with a tab character.

Step 7: Animating the Characters (Lip-Sync)

With the visual characters and the audio generated, the final creative step is animating the hosts with realistic lip synchronization.

I utilized the InfiniteTalk model for this task, feeding it the scene image with the characters from Step 3 and the separated audio files from Step 6.

Just upload an audio file for each speaker, along with their corresponding image, to the workflow. The model will then generate a lip-synced video.

Here is the prompt:

A man and a woman are talking to each other.

Example of the animation:

The generation time for each one-minute segment was about 60 minutes on my AMD Radeon AI PRO R9700.

Step 8: Assembling the Final Production

The last stage is combining all the assets we generated into a cohesive whole.

I used the open-source video editor Kdenlive to assemble the project:

1. Stitching Segments: Combining the five animated segments.
2. Transitions: Adding the 3-second B-rolls between the main discussion segments.
3. Final Touches: Adding the animated intro clip and the dim-lit outro scene with credits.
4. Audio Sync: Integrating the intro/outro music and B-roll audio.

You can download the full Kdenlive project, along with all the assets and ComfyUI workflows, here on my GitHub: meefik/humanless-podcast.

Conclusion

This project demonstrates that creating a complete, high-quality AI-generated media asset is absolutely possible using only open-source, self-hosted AI models and tools. It’s not an one-click solution, and the quality still requires a creative human touch, but the cost is only your time and the computational power of your local machine.

It was an exciting journey pushing the boundaries of what local AI can achieve. I hope this inspires you to explore similar projects and experiment with the incredible capabilities of open-source AI. The “Humanless Podcast” is a testament to the power of local AI—and I encourage you to try to create your own!

Hardware

The PC used for testing is equipped with the following specifications:

• Motherboard: B550 AORUS ELITE AX V2
• GPU: AMD Radeon AI PRO R9700 (32 GB VRAM, RDNA 4)
• CPU: AMD Ryzen 9 5950X (16 cores / 32 threads)
• RAM: 64 GB DDR4-2666
• Storage: NVMe Samsung SSD 970 EVO Plus 1TB (x2)

Setup environment

For testing LLM performance I installed Ollama natively with AMD ROCm support, rather than running it in a container. The setup has three parts: the AMD GPU driver with the ROCm runtime, the Ollama server itself, and a few environment variables to tune memory and parallelism.

Install the AMD driver and ROCm

First, make sure the AMD GPU driver and the ROCm runtime are installed. The exact steps depend on your distribution; the ROCm installation guide walks through adding AMD’s package repository and installing the driver plus runtime.

Verify the driver and ROCm are loaded:

rocminfo

Install Ollama

Install Ollama with the official script:

curl -fsSL https://ollama.com/install.sh | sh

This registers an ollama systemd service and starts the server.

Configure the environment

The environment variables that tune memory and parallelism are set on the ollama systemd service. Edit the service with:

sudo systemctl edit ollama

and add:

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=131072"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_NUM_PARALLEL=1"

Then reload and restart the service:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Confirm the GPU is being used:

ollama ps

Benchmark results

I used the following prompt for testing text generation performance:

Tell me a story about a brave knight who saves a village from a dragon.

For vision models that understand images, I used this image with the following prompt:

What is in this picture?

AMD Radeon AI PRO R9700 (32 GB VRAM, RDNA 4)

Here are the benchmark results for models with text generation only:

For vision models that understand images, here are the results:

MacBook Pro M4 Max (36 GB RAM, 14 cores)

Here are the benchmark results for models with text generation only:

For vision models that understand images, here are the results:

AMD Ryzen 9 5950X (16 cores/32 threads)

This is the CPU-only performance without GPU acceleration.

Here are the benchmark results for models with text generation only:

For vision models that understand images, here are the results:

Conclusion

The AMD Radeon AI PRO R9700 demonstrates strong performance across a variety of large language models, handling both text-only and vision-capable models effectively. With its substantial VRAM and robust architecture, the R9700 is well-suited for professional AI workloads, making it a compelling choice for developers and researchers working with LLMs. Now, I can take full advantage of AMD’s capabilities for my AI projects and code with local LLMs.

This post describes the library’s purpose, core design, how to use it, and a practical example of a NATS signaling driver with end-to-end encryption using the browser Web Crypto API.

Just try it out: demo | source code

Why this library

The library focuses on three goals:

• Minimal surface area: two primitives (Sender and Receiver) that cover the common conferencing pattern: one broadcaster, many receivers.
• Signaling-agnostic: you provide a small driver implementing subscribe/unsubscribe/dispatch and the library works with any transport.
• Practical privacy: support optional E2E encryption at the signaling layer so session offers/answers and candidates are not exposed in plaintext on the bus.

Design overview

At its core, p2p is small:

• Sender: creates outgoing RTCPeerConnections, publishes a local MediaStream and optional per-peer RTCDataChannels, and emits offers to receivers.
• Receiver: listens for offers, answers them, and surfaces remote streams and incoming data messages to the application.

Signaling expectations are intentionally simple: drivers produce messages scoped to namespaces (arrays/keys). The library uses namespaces such as [“sender”, room], [“receiver”, room, id], etc. Messages include typed payloads (invoke, offer, answer, candidate, sync, dispose).

Quick start

1. Install the library:

npm install p2p

2. Implement a signaling driver that supports subscribe/unsubscribe/dispatch.

Here’s a minimal conceptual example:

class MyDriver {
  subscribe(namespace, handler) { /* ... */ }
  unsubscribe(namespace, handler) { /* ... */ }
  dispatch(namespace, message) { /* ... */ }
}

Instantiate your driver:

const driver = new MyDriver();

3. Start a Receiver in the same room to discover and receive streams.

Instantiate Receiver with the same driver:

const receiver = new Receiver({ driver });
receiver.addEventListener('stream', (e) => {
  const { id, stream } = e.detail;
  // handle incoming MediaStream
});
receiver.addEventListener('connect', (e) => {
  const { id } = e.detail;
  // handle peer connection established
});
receiver.addEventListener('dispose', (e) => {
  const { id } = e.detail;
  // handle peer disconnection
});

Start the receiver in the same room:

receiver.start({ room: 'demo-room' });

4. Create and start a Sender to broadcast local media.

Instantiate Sender with your driver and options:

const sender = new Sender({ driver });

Start the sender with the stream and a room name:

const stream = await navigator.mediaDevices.getUserMedia({
  video: true,
  audio: true
});
sender.start({ stream, room: 'demo-room' });

NATS as a signaling transport with E2E encryption

NATS is a great lightweight pub/sub for distributed signaling. The demo repository includes a full driver implementation at demo/driver/nats.js; below is the compact approach and key ideas used there.

Here’s a simple driver implementation using the @nats-io/nats-core module:

import { wsconnect } from '@nats-io/nats-core';

class NatsDriver extends Map {
  constructor({ servers } = {}) {
    super();
    this.servers = servers || ['wss://demo.nats.io:8443'];
  }

  async open() {
    this.nc = await wsconnect({ servers: this.servers, noEcho: true });
  }

  async close() {
    await this.nc.drain();
  }

  subscribe(namespace, handler) {
    const ns = namespace.join(':');
    const sub = this.nc.subscribe(ns, {
      callback: async (err, msg) => {
        if (err) return console.error(err);
        const payload = JSON.parse(new TextDecoder().decode(msg.data));
        handler(payload);
      },
    });
    if (!this.has(ns)) {
      this.set(ns, new Map());
    }
    this.get(ns).set(handler, sub);
  }

  unsubscribe(namespace, handler) {
    const ns = namespace.join(':');
    const sub = this.get(ns)?.get(handler);
    if (sub) {
      sub.unsubscribe();
      this.get(ns).delete(handler);
    }
    if (!this.get(ns)?.size) {
      this.delete(ns);
    }
  }

  dispatch(namespace, message) {
    const ns = namespace.join(':');
    if (this.nc) {
      const data = new TextEncoder().encode(JSON.stringify(message));
      this.nc.publish(ns, data);
    }
  }
}

If you want the signaling payloads to be encrypted end-to-end (so the NATS server only sees opaque blobs), you can apply symmetric encryption on top of the driver.

High-level strategy:

• Derive an AES-GCM key from a shared passphrase (or pre-shared secret) using SHA-256.
• For every outbound message: encode JSON → encrypt with AES-GCM (random IV) → publish binary payload.
• For inbound messages: decrypt using AES-GCM with the same key → parse JSON → deliver to handler.
• Keep namespaces and message types unchanged; only payload bytes are encrypted.

Here’s a compact encryption helper (browser) using Web Crypto API.

Derive AES-GCM CryptoKey from passphrase via SHA-256:

async function createEncryptionKey(secret) {
  const secretHash = await crypto.subtle.digest(
    'SHA-256',
    new TextEncoder().encode(secret),
  );
  return await crypto.subtle.importKey(
    'raw',
    secretHash,
    { name: 'AES-GCM' },
    false,
    ['encrypt', 'decrypt'],
  );
}

Prepend a 12-byte IV + ciphertext:

async function encrypt(payload, cryptoKey) {
  const iv = crypto.getRandomValues(new Uint8Array(12));
  const ciphertext = new Uint8Array(
    await crypto.subtle.encrypt({ name: 'AES-GCM', iv }, cryptoKey, payload),
  );
  const data = new Uint8Array(iv.byteLength + ciphertext.byteLength);
  data.set(iv, 0);
  data.set(ciphertext, iv.byteLength);
  return data;
}

Extract IV and decrypt:

async function decrypt(data, cryptoKey) {
  const iv = data.slice(0, 12);
  const ct = data.slice(12);
  const payload = await crypto.subtle.decrypt({ name: 'AES-GCM', iv }, cryptoKey, ct);
  return payload;
}

Example usage (conceptual snippet):

// Create a key from a human passphrase
const key = await createEncryptionKey('room-secret-passphrase');

// Encrypt message (payload is Uint8Array)
const payload = new TextEncoder().encode('Secret message');
const data = await encrypt(payload, key);

// returns Uint8Array with IV+ciphertext
console.log('encrypted data', data);

// Decrypt message
const decryptedBytes = await decrypt(data, key);
const message = new TextDecoder().decode(decryptedBytes);

// returns original message
console.log('decrypted message', message);

Integrate encryption into the NATS driver by wrapping dispatch/subscribe methods to encrypt/decrypt payloads. Here is diff of the modified methods:

-  async open() {
+  async open(secret) {
     this.nc = await wsconnect({ servers: this.servers, noEcho: true });
+    if (secret) {
+      this.cryptoKey = await createEncryptionKey(secret);
+    }
   }
 
   async close() {
     const sub = this.nc.subscribe(ns, {
       callback: async (err, msg) => {
         if (err) return console.error(err);
-        const payload = JSON.parse(new TextEncoder().decode(msg.data));
+        let data = msg.data;
+        if (this.cryptoKey) {
+          data = await decrypt(data, this.cryptoKey);
+        }
+        const payload = JSON.parse(new TextDecoder().decode(data));
         handler(payload);
       },
     });
    if (!this.has(ns)) {
      this.set(ns, new Map());
    }
    this.get(ns).set(handler, sub);
  }

   dispatch(namespace, message) {
     const ns = namespace.join(':');
     if (this.nc) {
-      const data = new TextEncoder().encode(JSON.stringify(message));
+      let data = new TextEncoder().encode(JSON.stringify(message));
+      if (this.cryptoKey) {
+        data = await encrypt(data, this.cryptoKey);
+      }
       this.nc.publish(ns, data);
     }
   }

Operational considerations:

• If you run NATS in production, use authentication/authorization and TLS.
• For real-world NAT traversal include TURN servers in iceServers.
• For larger conferences, consider SFU architecture rather than pure p2p (p2p scales poorly with N participants).
• The encrypted signaling only protects SDP and candidates; media still flows directly between peers (or via TURN) and should be protected by SRTP (it’s part of WebRTC).

Conclusion

This project shows how a small, well-factored library can enable flexible, serverless peer-to-peer conferencing while giving you control over signaling and privacy. The NATS driver with E2E encryption is a practical option for distributed systems where you want to keep signaling private without a heavy backend.

This library is a good place to start. However, if you want to build more complex applications that include multiple data channels, two-way peer connections, additional built-in drivers or extra features, take a look at the Peerix project, which is based on these peer-to-peer ideas and offers a richer API and ecosystem.

On my system, this change reduced the GPU power consumption from 30W to 15W in idle state and completely eliminated fan spinning.

You can check the current performance level with:

rocm-smi --showperflevel
rocm-smi --showprofile
# or
cat /sys/class/drm/card0/device/power_dpm_force_performance_level
cat /sys/class/drm/card0/device/pp_power_profile_mode

You can change the performance level on the fly with (low - minimum performance; auto - maximum performance):

rocm-smi --setperflevel "low"
# or
echo "low" | sudo tee /sys/class/drm/card0/device/power_dpm_force_performance_level

Or, you can change the power profile mode (2 - POWER_SAVING; 5 - COMPUTE):

rocm-smi --setprofile "POWER SAVING"
# or
echo 2 | sudo tee /sys/class/drm/card0/device/pp_power_profile_mode

Additionally, you can limit the maximum power consumption (210W in this example, down from the 300W default):

echo 210000000 | sudo tee /sys/class/drm/card0/device/hwmon/hwmon*/power1_cap

To make this change permanent, create a udev rule:

cat << EOF | sudo tee /etc/udev/rules.d/30-amdgpu-power.rules
ACTION=="add|change", SUBSYSTEM=="pci", DRIVER=="amdgpu", ATTR{power_dpm_force_performance_level}="low"
ACTION=="add|change", SUBSYSTEM=="pci", DRIVER=="amdgpu", ATTR{pp_power_profile_mode}="2"
ACTION=="add|change", SUBSYSTEM=="hwmon", ATTR{name}=="amdgpu", ATTR{power1_cap}="210000000"
EOF
# apply and verify
sudo udevadm control --reload-rules
sudo udevadm trigger --subsystem-match=pci --subsystem-match=hwmon

After that, the AMD GPU will use the “low” performance level at each boot.

By the way, you can also change your CPU performance profile with the command:

powerprofilesctl set power-saver

Supported options: power-saver, balanced, performance.

First of all, I thought, since our DBMS cluster consists of two hosts (primary and secondary), it would be nice to switch tracking changes via Change Streams to the Secondary host, because millisecond latency in data synchronization between hosts isn’t critical for us here. No problem, done! This allowed us to distribute the load between the cluster hosts, but it still remained uneven. As it turned out, Change Streams on the Secondary host created more CPU load than all other operations on the Primary host. Studying the official documentation, forums, and even AI didn’t provide an understanding of the performance of this function, although the principle of operation eventually became clear.

In practice, experiments revealed that one of the features of Change Streams is that despite the fact that you can subscribe to changes only in a specific collection, it seems that under the hood, all changes across the entire database are collected and then filtered. This leads to the fact that any data changes in the database create an additional, albeit small, load. Digging further, I found an alternative mechanism for tracking the addition of new documents to a collection (which is exactly what we need), called Tailable Cursor. It uses the same oplog as Change Streams, but it seems to be structured a bit differently. Unlike Change Streams, it reacts to the addition of documents only to a specific capped collection and doesn’t create CPU load when data changes in other collections. Oh, so that was an option? Okay, done!

Synthetic tests showed a 20% performance increase, which is already good. However, in production, the load on the Secondary node could exceed the Primary by 2 to 5 times! So, there’s still something else going on. I conducted a synthetic test for adding documents to a collection (up to 1000 ops!) that is being monitored. It turned out that the load when adding documents to the monitored collection is 5% higher than to an unmonitored one. But then, it gets more interesting. Each new observer increases the load on the host by roughly 50%! And the more workers the application server has, the greater the load on the database will be. This can be worked with; we just need to reduce the number of listeners. Piece of cake, the new synchronization architecture is done, where within the same host, Node.js cluster workers communicate via the IPC (as in the case of working without a Replica Set), and hosts communicate through the Tailable Cursor mechanism in MongoDB. Thus, vertical scaling does not use the database, and horizontal scaling does, but it is limited by the number of application server hosts, not the number of its workers.

In the end, there were three optimizations:

1. shifting the load to the secondary host;
2. replacing change streams with tailable cursor;
3. reducing the number of listeners (1 listener - 1 host, instead of 1 listener - 1 worker).

In the end, this journey highlighted the importance of not just blindly implementing solutions, but also understanding the underlying technology and continuously seeking improvements. What initially felt like a small tweak turned into a series of optimizations that significantly impacted the system’s efficiency. It’s a good reminder that sometimes, the “unnecessary” optimization can lead to surprisingly valuable insights and improvements.