Paul Hodges wrote:
--On 20 March 2014 11:14 +0000 Andy Furniss <adf.li...@gmail.com>
wrote:
I think it's just like playing any compressed audio file.
But it isn't, because a slight mismatch in clock speeds would mean
that the playback could run ahead and eventually run out of buffered
samples to play. Of course, this issue is the same for any Internet
audio, and always has been.
Yea, I did also mention buffering, just that I assume the buffer is
normally big enough so that it doesn't run out/overflow in a reasonable
time.
I guess broadcast is in the same situation, mp2/aac/ac3 are all ahead by
600 ms in transport streams, though I don't know why, it could be to
give some leeway.
Transport streams do have extra clock timestamps, but I wonder if
TVs/receivers that have internal dacs + spdif + hdmi out really can/do
slave the clocks that control them to the clock reference in the stream
or whether they rely on buffering to help.
Looking at a sample of R3 AAC downloaded to disk I see it has
presentation time stamps - I am not sure how (or if) players handle the
soundcard clock being at a different rate to the master clock.
The open source video players I use base their a/v sync on sound, so
will adjust video to fit the sound card clock. There are exeptions, XBMC
does have an option to sync to video and resample sound to fit.
_______________________________________________
Sursound mailing list
Sursound@music.vt.edu
https://mail.music.vt.edu/mailman/listinfo/sursound
