From 90e498685e310116f5583014b57998e507097cf1 Mon Sep 17 00:00:00 2001 From: Michael Roitzsch Date: Sun, 9 Feb 2003 15:24:55 +0000 Subject: add some hints about audio difficulties Could someone with the necessary sgml/docbook toolchain installed please update the HTML and ASCII versions? Thanks. CVS patchset: 4121 CVS date: 2003/02/09 15:24:55 --- doc/faq/faq.sgml | 40 ++++++++++++++++++++++++++++++++++++---- 1 file changed, 36 insertions(+), 4 deletions(-) (limited to 'doc') diff --git a/doc/faq/faq.sgml b/doc/faq/faq.sgml index 165040c0c..68b681d03 100644 --- a/doc/faq/faq.sgml +++ b/doc/faq/faq.sgml @@ -758,7 +758,7 @@ Use something like: - cat stream.mpg | gxine stdin:// + cat stream.mpg | gxine stdin:/ @@ -1390,9 +1390,17 @@ Might be a soundcard problem, if it only comes in longer intervals. Your soundcard does not keep it's sampling frequency accurately enough, which results in audio and video - getting out of sync and xine has to compensate. - Maybe switching to different drivers (alsa to oss or vise-versa) - can help here. + getting out of sync and xine has to compensate. If you see the message + only from time to time, you might remedy it by using the resampling sync + method. You can do this by setting the configuration entry + audio.av_sync_method to resample. + + + If you receive the metronom message more often, + maybe switching to different drivers (alsa to oss or vise-versa) + can help here. It has also been reported that setting the configuration + entry audio.force_rate to the native sampling + rate of your soundcard (try 44100 and 48000) helps sometimes. Another, whole different possibility is that you have some background @@ -1405,6 +1413,30 @@ nothing to worry about. + + + xine seems to lose sound arbitrarily during playback, especially with DVDs + + + You are using the OSS audio output plugin, right? In order to keep video and audio + in sync, xine regularly queries the audio driver for the amount of delay induced by + the current length of the driver's audio buffer. Unfortunately some OSS drivers seem + to be broken because the can return strange values here. This confuses the xine audio + subsystem and makes it drop audio. + + + You should try the various settings of the + configuration entry audio.oss_sync_method. The options + getodelay and getoptr ask the driver and + might therefore show the problem. But chances are that only one is broken and the other + works, so you should try them both first, since they are the most accurate. + The option probebuffer does not ask the driver directly but + tries to determine the buffer length from outside. This should work with any driver + and is the way to go, of the driver dependent methods fail. + softsync is the least accurate and should be used only in + emergency situations. + + -- cgit v1.2.3