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.
Corrections pour que l'exemple utilise les bonnes API:
- Utilisation directe de Cache::new() au lieu de méthodes de config
- Suppression des appels à root() qui n'existent pas
- Utilisation du singleton PlaylistManager() au lieu de new()
- Ajout de cache-sink comme dépendance de playlist feature dans pmoaudio-ext
L'exemple devrait maintenant compiler correctement avec:
cargo run --example play_and_cache --features full -- <channel_id>
Improve the architecture by configuring the playlist handle directly
in register_playlist() instead of deferring it to run().
Changes:
- Remove playlist_handle_pending field (no longer needed)
- register_playlist() now calls logic_mut() to configure immediately
- run() becomes a simple delegation with no configuration logic
- Follows proper pattern: configuration before run(), not during run()
This is cleaner than the previous approach which used a pending field
and transferred it during run(). The new approach:
1. User calls register_playlist() → directly configures logic
2. User calls run() → simple delegation to inner.run()
Architecture now properly separates configuration from execution.
- Add Node::logic_mut() method to allow post-construction configuration
of node logic before run() is called
- Fix FlacCacheSink to properly transfer playlist_handle_pending to
the inner logic using logic_mut()
- Resolves FIXME at flac_cache_sink.rs:656 about missing logic_mut()
This enables the playlist registration mechanism to work correctly:
1. User calls register_playlist() on FlacCacheSink
2. Handle is stored in playlist_handle_pending
3. During run(), handle is transferred to FlacCacheSinkLogic
4. Tracks are automatically added to playlist after caching
