Fixed critical busy-loop polling bug in AsyncRead implementations for both
FLAC and OGG-FLAC client streams that prevented data transmission beyond
the initial header.
The issue was calling `cx.waker().wake_by_ref()` immediately when receiving
`TryRecvError::Empty`, creating an infinite poll loop that:
- Never properly waited for new data from the broadcast channel
- Consumed 100% CPU in busy-loop polling
- Prevented clients from receiving stream data after the header
Solution: Replace immediate wake with a delayed waker using tokio::spawn
and tokio::time::sleep(10ms). This avoids the busy-loop while still
ensuring the stream remains responsive to new data.
Testing verified:
- FLAC streaming: 884 KB in 8 seconds (~110 KB/s)
- OGG-FLAC streaming: 892 KB in 8 seconds
- Both formats properly recognized by `file` command
- TimerNode backpressure working correctly (~50ms per chunk)
Affected files:
- streaming_flac_sink.rs: FlacClientStream and IcyClientStream
- streaming_ogg_flac_sink.rs: OggFlacClientStream
a8d31353c3