OP here. You're right. The processed outputs and the recorded tracks are expected to be available <= 2s after the stream ends. That forces our hand to not be ab

OP here. You're right. The processed outputs and the recorded tracks are expected to be available <= 2s after the stream ends. That forces our hand to not be able to use memory conservatively. For example, one way to avoid massive memory usage will be to record concurrently (this has small memory footprint since we flush to disk after the write buffer hits 512KB so for about 50 concurrent recordings we need ~25MB), but process and upload sequentially. The recorded audio tracks are big, and have to be loaded to memory since the other tools we use for processing can't work with file on disk yet. The <= 2s requirement is impossible to meet when things are done sequentially.