Reputation: 54487
I am trying to understand how live audio streaming is accomplished as far as buffer management goes.
For the audio case: if you have a source capturing a frames at 44100hz +/- clock error, and a receiver with an audio card DAC consuming frames at 44100hz +/- clock error.
Because of the clock errors at each end the buffer at the receiver would (eventually) either grow out of control or under run.
For one source live streaming to many receivers a flow control stream is not possible.
My only guess at a solution would be to keep track of buffer fill at the receiver (over a longer period than network jitter effects) and either insert samples or drop samples.
Any insight on this would be greatly appreciated. Thanks!
Upvotes: 1
Views: 1099
Reputation: 21
It does matter. Streaming continuous, long term, live audio over a network is often done in industry where it's no joking matter. It's too simplistic to assume that two oscillators will be within such a small deviation that it can be ignored.
(As an aside, it's OK to say it doesn't matter in some circumstances. Take, for instance, Pugsley Adam's question to his older sister, Wednesday Adams, when seeing two wicked adults fall into open graves. He asks "Are they dead?" and she answers, dryly, "Does it matter?")
Here are three possible approaches to coping with the problem and, if you can think of more or better solutions, please share: 1) Implement some kind of frequency lock loop, whereby the receivers' clocks are adjusted slightly to accommodate the input stream 2) Perform sample rate conversion at the receivers to correct the error 3) Monitor the number of samples in a buffer or queue so that, when underrun or overrun is imminent, a few samples are generated or dropped in order to avoid serious degradation in audio quality.
If you have control over the receivers' clocks, the first solution is best. I'm not sure how to do that with high-level audio software modules like ALSA or PulseAudio (any suggestions gratefully received!) Performing sample rate conversion might be nice, philosophically, but would be far more CPU intensive than it's worth (and add unnecessary risk of failure) So I'm in favour of monitoring buffer depth (as suggested by May) and slipping samples in or out inconspicuously.
Any more ideas?
Upvotes: 2
Reputation: 163242
It is definitely the case that the clocks fall out of sync. The truth is, it doesn't matter.
Suppose a clock is off by as much as 5Hz (which is a few magnitude over what is normal). Over the course of an hour, the clocks only drift by 0.4 seconds, which is less than the usual 2-5 seconds of buffer time.
Network issues often cause rebuffering far more often than clock sync issues. In reality, the clocks usually differ by 1Hz or less, making this almost a non-issue.
Now if you want to synchronize playback, that is a whole 'nother problem. Fortunately, listeners of streaming audio don't usually do this.
Upvotes: 1