69cb3eb80a
PROBLEM: When streaming Radio Paradise blocks via HTTP using FFPlay, the buffer would cycle between 0KB and ~130KB approximately once per second, causing audio dropouts and interruptions. VLC worked fine, but FFPlay was sensitive to the burst transmission pattern. ROOT CAUSE: In StreamingFlacSink::broadcast_flac_stream(), the broadcaster was reading 8KB (8192 bytes) at a time from the FLAC encoder and sending the entire chunk at once to all HTTP clients. This created a "burst" pattern: - Read 8KB from encoder - Send entire 8KB chunk to all clients - Sleep if ahead of real-time pacing - Repeat FFPlay's buffer would fill rapidly with each 8KB burst, then drain completely before the next burst arrived, causing the observed cycling behavior. SOLUTION: Reduced the HTTP broadcast buffer size from 8KB to 512 bytes in StreamingFlacSink::broadcast_flac_stream(). This creates a much smoother, more continuous data flow that FFPlay can handle without buffer cycling. The 512-byte buffer size is: - Small enough to prevent burst transmission - Large enough to avoid excessive overhead - Sufficient for smooth streaming with real-time pacing CHANGES: - Restore stream_block.rs example from git history - Restore StreamingFlacSink and StreamingOggFlacSink from git history - Add "streaming" feature to pmoaudio-ext - Reduce broadcast buffer from 8192 to 512 bytes - Update pmoparadise to use pmoaudio-ext streaming feature TESTING: Test with FFPlay to verify smooth buffering: ```bash cargo run --example stream_block --features full -- 0 # In another terminal: ffplay http://localhost:8080/test/stream ``` Watch the "aq=" value in FFPlay output. It should now remain stable instead of cycling between 0KB and 130KB.
15 KiB
15 KiB