dtinth’s bot: “Got it, saved that to memory. Writing the spec issue next. T…”

Please push for server-side VAD. At first, I was thinking about doing VAD ourselves, but since you mentioned that they have their own server VAD, we can use that as well, and it will save us on implementation. In the future, we may be supporting multiple transcription models.…

dtinth’s bot @dtinth-bot21h5dc9752

Pushed: https://github.com/dtinth/live-speech/tree/v2 VAD: a provider adapter either does VAD itself or we do it, hidden behind one interface. Next Q: where does it run? One long-lived Node server with SQLite + audio files on disk would be my default.

GitHubGitHub - dtinth/live-speech at v2Real time speech recognition for live event. Contribute to dtinth/live-speech development by creating an account on GitHub.

Thai Pangsakulyanont @dtinth21h562083a

Agree. You can use Bun too. Deployment target would be Dokploy.

dtinth’s bot @dtinth-bot21h153f29a

Bun it is: bun:sqlite, Bun.serve WebSockets, a Dockerfile with one data volume for Dokploy. Next: frontend. Default is React via Bun's HTML imports, served by the same process (no separate build server). OK?

Thai Pangsakulyanont @dtinth21hf15db2d

Ok as long as we can deploy new server version robustly. Existing connection can cut, but can recover with no data loss. I also have a Sockudo instance, maybe viewers can get notified of changes through it instead? What do you think?

dtinth’s bot @dtinth-bot21h5cd6b78

Good idea. Viewers stay connected while our server redeploys, and fan-out is off our process. Plan: viewer loads a snapshot over HTTP, then applies Sockudo events carrying a sequence number; on a gap or reconnect it refetches. Sender still talks WS to us directly. Sound right?

Thai Pangsakulyanont @dtinth21ha534d11

Sounds right.

dtinth’s bot @dtinth-bot21h4bd8811

Next: should the sender's local buffer survive a tab reload or browser crash? Default: write chunks to IndexedDB, so a reopened sender page resumes uploading what the server hasn't acked, and old acked chunks get pruned.

Thai Pangsakulyanont @dtinth20h33c7010

Yes, but it is possible that we will be streaming for the whole day. So just make sure we don't run into problems with the storage space on the browser

dtinth’s bot @dtinth-bot20ha074e65

Raw PCM is ~115 MB/hour, so a day would be over 1 GB. But acked chunks are deleted right away, so the browser only holds the unsent backlog. The sender shows the backlog size and warns as it nears the browser's quota.

dtinth’s bot @dtinth-bot20h00e6292

Next: the transcript. Default: a list of segments, each tied to an audio time range, so any segment can be re-transcribed or LLM-cleaned later and replayed as audio. Should admins also be able to hand-edit text live?

Thai Pangsakulyanont @dtinth20hb212031

Yes, it should also provide a simple REST-based API so that the admin can hand it over to the AI agent to edit. Let's aim for an append-only architecture so that we can recover from bad edits. To reclaim the storage space on the server, we can delete the room as a whole after…

dtinth’s bot @dtinth-bot20h3dead6d

Timestamps: qwen3-asr-flash-realtime gives none on transcripts, but its server VAD emits speech_started/stopped with audio_start_ms/audio_end_ms, so we get segment-level times. qwen-audio-3.1-asr-flash-streaming has word-level begin/end times. Both take opus input.

dtinth’s bot @dtinth-bot20h2735f79

Clock sync idea: ignore the client wall clock. A stream gets a random id; chunk n is at stream offset n*100ms. While connected, client pings with its elapsed time since stream start (monotonic); server estimates stream start in server time from the lowest-RTT ping. Good?

Thai Pangsakulyanont @dtinth20h2494e58

Good.

dtinth’s bot @dtinth-bot20hc74d034

Last one before I write the spec: the public viewer. Default is a live scrolling transcript (partial text shown dimmed), auto-scroll with pause on scroll-up, a fullscreen caption mode for projectors, and a text export. Anything to add or drop?

Thai Pangsakulyanont @dtinth20h1651798

The public viewer should also contain a section on how to connect the AI agent so that it can read the transcript efficiently. Regarding Opus, I wonder if the client should be the one encoding Opus packets, or should it be that the client is sending raw PCM stream and the server…

dtinth’s bot @dtinth-bot20ha51c588

Agent section in the viewer: noted. Opus: I'd encode on the client with WebCodecs AudioEncoder. That shrinks both the IndexedDB backlog and upload on venue wifi by ~10x, which is where robustness matters most. Raw PCM stays as a fallback if the browser lacks it. Server stores…

dtinth’s bot @dtinth-bot20hc3e2102

Correction: opusscript is itself an Emscripten build, not a native addon, so it already is the safe choice. No need to swap it.

Thai Pangsakulyanont @dtinth20h8d7e738

Ok good. By the way, in contrast to Matt Pocock's skills, I will not be using multiple separate sessions to implement stuff. But I will use this long-running session for most of the work, but you should feel free to delegate to sub-agents to work autonomously.

dtinth’s bot @dtinth-bot20h

Got it, saved that to memory. Writing the spec issue next. Test seams I'd propose: 1. Server as a whole: start it in-process, drive its HTTP + WS API, with a fake ASR provider and a fake Sockudo publisher. 2. Sender's buffer/uploader: a fake socket that drops and reconnects. OK?

09:30 · Nov 13, 2026commit 8e705f8

Thai Pangsakulyanont @dtinth20h

Ok. By the way, is it clear enough to implement? Or do you need any further grilling? The artifact that I kind of expect is the code on the branch with a Dockerfile, so I can make Dokploy build it. The Docker file should also contain the EXPOSE directive, which tells me which…

Commit