From: VDR U. <use...@gm...> - 2010-08-27 20:08:51
|
Hi. Xine seems to have a problem with ac3 audio dropping out frequently, which ruins the ability to watch hdtv for example. I have made a sample which exhibits this problem, which plays just fine in mplayer so I assume that means root causes such as a buggy system scheduler can be ruled out. The sample also plays fine on my main Windows desktop as well. Adjusting things such as engine.buffers.audio_num_buffers in xine's config has no affect. It has been suggested that the problem may be xine not properly handling a stream error. If anyone can and is willing to take a look at this and hopefully resolve the problem once and for all, that would be great. The sample is 20MB so it can't be attached to this post. Until I can find a better place to host the sample, I've temporarily uploaded it to: http://rapidshare.com/files/415479559/xine_ac3_dropout_bug.tar.bz2 System details are: debian testing stable kernel 2.6.35.3 (quiet notsc clocksource=hpet) gcc 4.4.4-8 alsa-base 1.0.23+dfsg-1 alsa-utils 1.0.23-2 xine-lib-1.2 hg r11577 xine-ui hg r3054 VDR-1.7.15 mplayer-nogui 2:1.0~rc3++svn20100804-0.0 I recently tried the notsc and clocksource=hpet kernel options, which also had no affect. I want to reiterate that the dropout problem only occurs in xine. The error I see in the xine log when the dropout occurs is: pcm_hw.c: snd_pcm_hw_delay() SNDRV_PCM_IOCTL_DELAY failed (-32). I accidentally posted this to the alsa-dev mailing list and one of their devs Jaroslav Kysela wound up responding to it with the following: > -32 means -EPIPE - underrun has occured. It means that xine does not deliver > samples in time to the driver for some reason. Because mplayer works, it > does not seem like a general ALSA issue. I would ask xine developers for > further debugging of this issue (compare the audio write calls with the > realtime clock)." Best regards, Derek |
From: VDR U. <use...@gm...> - 2010-09-10 16:27:13
|
On Fri, Aug 27, 2010 at 1:08 PM, VDR User <use...@gm...> wrote: > Hi. Xine seems to have a problem with ac3 audio dropping out > frequently, which ruins the ability to watch hdtv for example. I have > made a sample which exhibits this problem, which plays just fine in > mplayer so I assume that means root causes such as a buggy system > scheduler can be ruled out. The sample also plays fine on my main > Windows desktop as well. Adjusting things such as > engine.buffers.audio_num_buffers in xine's config has no affect. It > has been suggested that the problem may be xine not properly handling > a stream error. > > If anyone can and is willing to take a look at this and hopefully > resolve the problem once and for all, that would be great. The sample > is 20MB so it can't be attached to this post. Until I can find a > better place to host the sample, I've temporarily uploaded it to: > http://rapidshare.com/files/415479559/xine_ac3_dropout_bug.tar.bz2 > > System details are: > > debian testing > stable kernel 2.6.35.3 (quiet notsc clocksource=hpet) > gcc 4.4.4-8 > alsa-base 1.0.23+dfsg-1 > alsa-utils 1.0.23-2 > xine-lib-1.2 hg r11577 > xine-ui hg r3054 > VDR-1.7.15 > mplayer-nogui 2:1.0~rc3++svn20100804-0.0 > > I recently tried the notsc and clocksource=hpet kernel options, which > also had no affect. I want to reiterate that the dropout problem only > occurs in xine. The error I see in the xine log when the dropout > occurs is: pcm_hw.c: snd_pcm_hw_delay() SNDRV_PCM_IOCTL_DELAY failed > (-32). > > I accidentally posted this to the alsa-dev mailing list and one of > their devs Jaroslav Kysela wound up responding to it with the > following: > >> -32 means -EPIPE - underrun has occured. It means that xine does not deliver >> samples in time to the driver for some reason. Because mplayer works, it >> does not seem like a general ALSA issue. I would ask xine developers for >> further debugging of this issue (compare the audio write calls with the >> realtime clock)." Will someone PLEASE look into this. Thank you. |
From: Reinhard N. <rn...@gm...> - 2010-09-16 20:20:52
|
Hi, Am 10.09.2010 18:27, schrieb VDR User: >> System details are: >> >> debian testing >> stable kernel 2.6.35.3 (quiet notsc clocksource=hpet) >> gcc 4.4.4-8 >> alsa-base 1.0.23+dfsg-1 >> alsa-utils 1.0.23-2 >> xine-lib-1.2 hg r11577 >> xine-ui hg r3054 >> VDR-1.7.15 >> mplayer-nogui 2:1.0~rc3++svn20100804-0.0 >> >> I recently tried the notsc and clocksource=hpet kernel options, which >> also had no affect. I want to reiterate that the dropout problem only >> occurs in xine. The error I see in the xine log when the dropout >> occurs is: pcm_hw.c: snd_pcm_hw_delay() SNDRV_PCM_IOCTL_DELAY failed >> (-32). >> >> I accidentally posted this to the alsa-dev mailing list and one of >> their devs Jaroslav Kysela wound up responding to it with the >> following: >> >>> -32 means -EPIPE - underrun has occured. It means that xine does not deliver >>> samples in time to the driver for some reason. Because mplayer works, it >>> does not seem like a general ALSA issue. I would ask xine developers for >>> further debugging of this issue (compare the audio write calls with the >>> realtime clock)." > > Will someone PLEASE look into this. Well, I was able to reproduce this issue with your supplied .xine/config. The problem is caused by a too small number of video input buffers (you used the default value of 500 buffers). What is a reasonable buffer size? When using vdr-xine to connect VDR to xine, each video input buffer will get 2048 byte of the video stream. Given that your HD channel broadcasts at 10 Mbit/s, you'll need that much buffers to hold a single second of video: 10000000 bit / 8 bit/byte / 2048 byte/buffer = 610 buffer What about audio buffers. vdr-xine puts a single audio frame (let's assume such a frame equals 24 ms of audio) into an audio input buffer. So for a second of audio, you'll need that much buffers: 1000 ms / 24 ms/frame / 1 frame/buffer = 41 buffer To allow an a/v offset at the input stage of up to +/-3 seconds, you'll need 1831 video input buffers and 125 audio input buffers. On top of that, you'll add another 2 seconds to allow for some latency at the receiving and processing stages, so you'll end up with 3051 video input buffers and 208 audio input buffers. As you can see, 208 audio buffers is a bit less that what is the default (230). But 3051 video buffers are much more than the default (500). The memory footprint of the above buffer counts is like that: xine uses 8192 byte per input buffer, so you'll get 3259 buffer * 8 kbyte/buffer = 26072 kbyte or roughly 25 MB. The actual number of input buffers may be chosen a bit lower as a part of the a/v offset can also be buffered during decoding and by the output buffers. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rn...@gm... |
From: VDR U. <use...@gm...> - 2010-09-17 00:35:59
|
On Thu, Sep 16, 2010 at 1:20 PM, Reinhard Nissl <rn...@gm...> wrote: > Well, I was able to reproduce this issue with your supplied > .xine/config. The problem is caused by a too small number of > video input buffers (you used the default value of 500 buffers). This baffles me because the very first thing I tried when I encountered this problem was stop everything, then edit the buffer settings by adding a 0 so audio_num_buffers and video_num_buffers both became 5000. Then restarted everything but the problem still existed so I had ruled out buffers as the problem and put them back to the default values. During the course of trying to fix this I've actually done that a few times while trying other things along with it and every time it was still a problem. However, everything you explained makes perfect sense so I'm not sure what's different this time as opposed to others. This time I only changed the video_num_buffers to 5000 and left audio_num_buffers alone. Is it possible setting too big of an audio_num_buffers could've been an issue before? I can't imagine it would but maybe that along with some other condition created a problem? Best regards, Derek |
From: Holger R. <ho...@do...> - 2010-09-17 08:15:09
|
Am 16.09.2010 um 22:20 schrieb Reinhard Nissl: > > The actual number of input buffers may be chosen a bit lower as a > part of the a/v offset can also be buffered during decoding and > by the output buffers. > Hi Reinhard, thanks for your explanation. As I'm also "suffering" from those dropouts on Ubuntu Lucid (actually yaVDR) I'd like to ask another question: What settings do you recommend for the xine plugin itself? With the settings below I experience dropouts even on SD channels that are broadcasted with PCM audio (e.g. "VOX") xine.modeLiveTV.monitoringDuration = 10 xine.modeLiveTV.monitoringMode = monitoringOnce xine.modeLiveTV.prebufferFramesAudio = 4 xine.modeLiveTV.prebufferFramesVideoHD = 4 xine.modeLiveTV.prebufferFramesVideoSD = 4 xine.modeLiveTV.prebufferHysteresis = 4 Increasing only the "prebufferFrames*" does not help, it seems to me that the dropouts just appear a bit later. BUT: if I use "0" for "xine.modeLiveTV.monitoringDuration" and thus disable it and use "25" for the "prebufferFrames*" theses dropouts are completely gone. Does this make any sense to you? regards Holger |
From: Reinhard N. <rn...@gm...> - 2010-09-17 19:10:06
|
Hi, Am 17.09.2010 10:15, schrieb Holger Reichelt: > thanks for your explanation. As I'm also "suffering" from those dropouts > on Ubuntu Lucid (actually yaVDR) I'd like to ask another question: What > settings do you recommend for the xine plugin itself? With the settings > below I experience dropouts even on SD channels that are broadcasted > with PCM audio (e.g. "VOX") > > xine.modeLiveTV.monitoringDuration = 10 > xine.modeLiveTV.monitoringMode = monitoringOnce > xine.modeLiveTV.prebufferFramesAudio = 4 > xine.modeLiveTV.prebufferFramesVideoHD = 4 > xine.modeLiveTV.prebufferFramesVideoSD = 4 > xine.modeLiveTV.prebufferHysteresis = 4 While you are using the values documented in vdr-xine's MANUAL, I've changed them a little bit for me: xine.modeLiveTV.monitoringDuration = 30 xine.modeLiveTV.monitoringMode = monitoringOnce xine.modeLiveTV.prebufferFramesAudio = 4 xine.modeLiveTV.prebufferFramesVideoHD = 32 xine.modeLiveTV.prebufferFramesVideoSD = 4 xine.modeLiveTV.prebufferHysteresis = 4 What do these settings do: during prebuffer phase (which starts immediately after zapping to a channel), vdr-xine extracts the presentation time stamps (PTS) of video and audio packets immediately after receiving them in VDR and compares those timestamps to the current replay time stamp in xine (STC). By setting xine's replay speed to 12.5 % after the first image is displayed, data comes in "faster" than it goes out to screen, which establishes a buffer within less than a few seconds. By comparing replay and input timestamps one can calculate the established buffer size -- for simplicity, I've chosen the unit "frames" where 25 frames specify a time span of 1 second. The established buffer sizes are calculated individually for audio and video packets. When both buffer sizes exceed their corresponding prebufferFrames count plus prebufferHysteresis (e. g. 36 vor HD video and 8 for audio in my case), vdr-xine switches to 100 % replay speed. As data now comes in at the same speed as it goes out, the established buffer should never shrink and live TV should be possible without any issues. But for some reasons, the established buffer size might have been reached just for a short moment and the actual buffer size might therefore be lower. Therefore, after switching to 100 % replay speed, monitoring kicks in and checks the established buffer size continuously for the specified duration when using mode "monitoringOnce" or forever otherwise. When any of the established buffers drops below the configured prebuffer value (without hysteresis, e. g. 32 and 4 for the above example) during monitoring, vdr-xine will switch back to speed 12.5 % and hysteresis is increased by 1. So the next prebuffer/monitor cycle will establish a little larger buffer (i. e. 37 and 9) and hopefully not drop below the configured prebuffer values again. In case monitoring duration passes over with no drop below the configured prebuffer values, vdr-xine will switch to a less time and memory consuming operation mode internally. There are a few situations where vdr-xine returns to prebuffer mode, e. g. when a discontinuity happens, but that's a different story. > Increasing only the "prebufferFrames*" does not help, it seems to me > that the dropouts just appear a bit later. BUT: if I use "0" for > "xine.modeLiveTV.monitoringDuration" and thus disable it and use "25" > for the "prebufferFrames*" theses dropouts are completely gone. Does > this make any sense to you? Sure, using 50 frames (e. g. 25 video SD + 25 hysteresis) is more than 6 times the default buffer (4 + 4) and therefore there should be absolutely no dropouts. The drawback of a huge prebuffer is that replay starts quite "a while" after switching to a channel so zapping with a quick glance of what is running on that channel isn't as fast as possible (not to mention it will never be as fast as on a complete hardware solution like a receiver or settop box). Finally, why did I increase monitoringDuration? Especially for HD content with variable bit rate, it is likely that monitoring duration passes in a scene with low bit rate so you'll get a buffer underrun in a scene with high bit rate. Monitoring buffer size over a longer period tries to minimize this error. Regarding prebufferFramesVideoHD I'm still unsure which value is sufficient. My current value is useful to make sure that there are no buffer underruns while debugging vdpau decoding so any dropouts noticed are not a matter of insufficient buffering. Choosing that many buffers has an impact on zapping as mentioned above. But due to the lack of any other HD receiver I cannot compare zapping speeds for optimizing this value. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rn...@gm... |
From: James Courtier-D. <Ja...@su...> - 2010-09-17 07:54:57
|
On 10/09/10 17:27, VDR User wrote: > On Fri, Aug 27, 2010 at 1:08 PM, VDR User <use...@gm...> wrote: >> Hi. Xine seems to have a problem with ac3 audio dropping out >> frequently, which ruins the ability to watch hdtv for example. I have >> made a sample which exhibits this problem, which plays just fine in >> mplayer so I assume that means root causes such as a buggy system >> scheduler can be ruled out. The sample also plays fine on my main >> Windows desktop as well. Adjusting things such as >> engine.buffers.audio_num_buffers in xine's config has no affect. It >> has been suggested that the problem may be xine not properly handling >> a stream error. >> >> If anyone can and is willing to take a look at this and hopefully >> resolve the problem once and for all, that would be great. The sample >> is 20MB so it can't be attached to this post. Until I can find a >> better place to host the sample, I've temporarily uploaded it to: >> http://rapidshare.com/files/415479559/xine_ac3_dropout_bug.tar.bz2 >> >> System details are: >> >> debian testing >> stable kernel 2.6.35.3 (quiet notsc clocksource=hpet) >> gcc 4.4.4-8 >> alsa-base 1.0.23+dfsg-1 >> alsa-utils 1.0.23-2 >> xine-lib-1.2 hg r11577 >> xine-ui hg r3054 >> VDR-1.7.15 >> mplayer-nogui 2:1.0~rc3++svn20100804-0.0 >> Try with kernel 2.6.32 2.6.35 has scheduling bugs. James |