A Stateless Service for Audio Processing
summary
Claims a production stateless pipeline for multi‑participant live audio used at Periscope/Twitter that decodes WebRTC opus→AAC transcode per short request, mixes streams by simple summation, and streams results back with a chunked HTTP streaming transport. It uses a 1 s reorder buffer on the ingest side, sends priming audio to avoid AAC artifacts, caps server requests around 5 s, supports a few guests and reduces long deploy windows while running in production.
AI-written summary · about
chapters (18)
- 0:00Intro
- 0:49What is this stateless thing?
- 2:51Going live on Twitter
- 5:21Conversational broadcast participants
- 5:58Conversational broadcast infrastructure
- 7:47Multiple audio stream processing
- 7:57Separate audio tracks
- 9:17Mixed audio track
- 9:52What do we need to do?
- 10:11Audio processor: stateful or stateless?
- 12:35Client-server audio processing
- 13:47AAC audio priming
- 15:01Audio client Ingest server
- 17:26Chunked HTTP Transport
- 18:38Audio processing server
- 20:21Audio processing Originally intended to do stateful audio processing
- 22:06Simple Solution: Add and Clip
- 23:31What's next?
related talks
01h 23mLive Streaming Platform As An Instrument, Experience And Pastime
17mLive Video Streaming as "tail -f"
08mDynamic server-side content stitching for personalized streams.
19mLow Latency Live from a Different Vantage Point
19mAudio Streaming - Using WebRTC for building your own Voice AIs
12mIt's time to WHIP WebRTC into shape
24mMeet the Packets: How audio travels into your browser
23mAudio and Video Manipulation