Curious if you thought their approach was necessary, it seemed like a ton of complexity to reduce one of the faster parts of a voice AI setup. Having a fast model and accurate VAD seems way more important than fine tuning WebRTC transit times.
I think It’s a case of you improve what you own. The owners of WebRTC servers were aggressively improving their part. They don’t own the inference servers.
I read parts of it a while ago when I had an idea on using webRTC data channels to pass data from databases to browser clients via a CLI. Your book made me understand that it's probably not a great fit for my use case. I just used a centralized control plane and websockets instead.
I still feel like there is something fun that we can do with webRTC data channels + zero copy Apache Arrow arraybuffers + duckdb WASM, but haven't figured it out yet
You can't beat Websockets :) Especially since you have so much tooling/existing stuff that works with HTTP.
I have been trying to get a website off the ground that does Datachannels + SQlite in the browser and then users sync between each other. I have gotten distracted so many times though.
> WebRTC is a standardized protocol for P2P communication. It allows two peers to exchange media and data. It is encrypted by default, and handles connectivity establishment in many different network conditions. It is supported in browsers, and has multiple out of browser implementations.[0]
import ("github.com/go-sql-driver/mysql")
so it's standard to have the library files in the root directory. ├── cmd
│ └── binary-name
│ └── main.go (may subpackage for things like CLI porcelain, etc)
├── go.mod
└── internal
└── app.go (and subpackages, etc)To me go code looks like somebody vomitted stuff in the root dir and i have to wade through that every time. No namespacing. nothing
I guess I qualify as a Go fanboi -- it is not perfect but gets the job done for a lot of us, sorry it doesn't work for you.
But back to your point about "vomit in the root dir", Go does have namespacing of sorts via packages, and the pattern you criticized is not the only way -- often just a simple main.go at the root bringing in packaged functionality.