Viewing profile — kixelated

Yeah that's a really good way of framing the argument, I wish I wrote that. The way robots listen/respond is bounded by compute, not time. Buffering audio isn't a great experience …

Close, but that's a minimum latency. We want a maximum latency knob.

To clarify, I meant waiting an extra 200ms if the alternative was dropping part of the prompt. During periods of zero congestion, the latency would be the same.

HELLO MR SEAN, 1. Of course users want lower latency, but they also want fewer instances where the LLM "misheard" them. It would be amazing to run A/B experiments on the trade-off …

Hello Mr Author here. Apologies that my comment replies aren't as funny. Every low-latency application has to decide the user experience trade-off between quality and latency. Cong…

QUIC libraries work by looping over pending streams (in priority order) to determine which UDP packet to send next. If there's more stream data than available congestion control, t…

Yep, it's similar to multicast but L7. But a huge difference is that there's a plan for congestion. We heavily rely on QUIC to drain network queues and prioritize/queue media based…

Yeah for Safari support I'm using polyfills; it sucks. - libav.js for AudioEncoder/AudioDecoder. - QMux over WebSockets for WebTransport. Both are NPM packages if you want to use t…

Absolutely agree. You can convert any push-based protocol into a pull-based one with a custom protocol to toggle sources on/off. But it's a non-standard solution, and soon enough y…

Hey lewq, 40Mbps is an absolutely ridiculous bitrate. For context, Twitch maxes out around 8.5Mb/s for 1440p60. Your encoder was poorly configured, that's it. Also, it sounds like …

Yeah, technically it's SCTP over DTLS for data channels. Only the media layer gets to use raw UDP, limiting the scope.

QUIC has a much better alternative to FORWARD-TSN, either via RESET_STREAM or QUIC datagrams. I've implemented SCTP before to hack in "datagram" support by spamming FORWARD-TSN. Fu…

For sure, if you want an ordered/reliable stream then WebSocket is ideal. WebTransport is useful when you also want prioritization and semi-reliable networking, similar in concept …

I like to frame WebTransport as multiple WebSocket connections to the same host, but using a shared handshake. It's common to multiplex a WebSocket connection but you don't need th…

I maintain https://github.com/kixelated/web-transport But yeah the HTTP/3 integration definitely makes WebTransport harder to support. The QUIC connection needs to be shared betwee…

There's no probing in any QUIC implementation but it's possible. There's a QUIC extension in the IETF similar to transport-wide-cc but it would still be up to the browser to use it…

SCTP and by extension, WebRTC data channels, are supposed to use the same congestion control algorithms as TCP/QUIC. But I don't know which CC libsctp does these days. WebTransport…

I had a 30 minute intro call and got a rejection a few days later. It was VERY timely (Sep 21 email, Sep 23 meeting, Sep 26 rejection). We both weren't sure if my project was a goo…

Thanks! You don't need multicast! CDNs effectively implement multicast, with caching, in L7 instead of relying on routers and ISPs to implement it in L3. That's actually what I did…

QUIC has support for preferred address, where anycast is used for the QUIC handshake then the connection migrates to a unicast address. It still has issues but it's nice to have st…

Oh and the autoplay restrictions for don't apply when muted.