[xine-devel] delay

[Paul F. <pa...@da...>]

Guenter Bartsch writes:
 > Hi Paul,
 > 
 > sorry that you'll have to wait for answers on your mails once again. 

That's OK - it's only that my home machine has two installations, one RH7 and
one RH 6.2 - I _still_ haven't set mail up correctly on the former so I worry
that it gets lost.

 > 
 > The realtime problem you mentioned (and the downsampling solution) is
 > really important stuff - so don't you think I want to reject that or
 > anything. 

You might want to do the resampling "properly" and apply a filter to remove
anything above 22Khz although even linear interpolation sounds better than
48Khz samples played at 44.1 (possibly becasue most** movie soundtracks don't
have any frequencies that high).

Whether filtering is needed for upsampling I'm not sure. However, I don't
think that it's a practical proposition for 48000->48662 (the ES 1370 case)
because their least common multiple is 1167.888Mhz!

** Well, the one that I was watching anyway

 > A while ago I talked about that with walken (the mpeg2dec guy). We found
 > that if we can come up with a good solution for that (and I think what
 > you've done by downsampling is part of that solution) it could really be
 > time for xine to go for bigger publicity.
 > 
 > in short:
 > 
 > I think one last problem is that xine uses the audio device as master
 > clock - besides the effect you saw with multicasting this has other
 > disadvantages - probably the biggest drawback is that some audio drivers
 > do not provide precise timing information. So I think we should switch
 > over to a different synchronization model that's based on the system
 > clock. So metronom would generate a master clock and both, video _and_
 > audio have to sync on it (audio would do that by up/downsampling or, in
 > worst cases inserting zero samples or dropping samples). This would bring
 > us nice independance from any braindead audio driver implementations /
 > audio hardware that doesn't know what it's playing _and_ would give us the
 > ability to play streams that don't have an audio track at all.

Yes, I think that would be better. Ideally for streamed media the master
clock would be derived from the input - the problem with the ES1370 made it
fairly obvious but I'd expect some drift between the client clock and server
clock which could cause problems (even if the clock is accurate to 1ppm
that's still 86ms out after 24 hours which is more than enough to throw
xine).