From: Frank E. <fra...@an...> - 2010-03-29 09:03:49
|
hi, i discovered problems playing an audio stream through xine-lib. now i tracked the problem down into the ao_alsa_delay() function of the audio_also_out module. this function utilizes snd_pcm_delay() to get the delay, which returns -32 (broken pipe). there seems to be no real error handling for this case and this results in a broken audio output which is not resolved. so i have the following questions: - why does this happen? - how can it be resolved? i'm not very familiar with alsa. what i would try (if i knew how to do it) is to reopen the sound device in case of failure. this will surely produce an audio glitch, but i guess it'll continue to play. any help would be appreciated. thanks.. frank. -- Dipl.-Ing. (FH) Frank Enderle anamica UG (haftungsbeschränkt) Beinsteinerstr. 6 71334 Waiblingen Telefon: +49 151 14981091 Telefax: +49 7151 1335770 E-Mail: fra...@an... Internet: www.anamica.de Handelsregister: AG Stuttgart HRB 732357 Geschäftsführer: Yvonne Holzwarth, Frank Enderle |
From: Frank E. <fra...@an...> - 2010-03-30 07:25:45
|
hi, i found the root cause for the problem and this problem is now fixed. it had nothing to do with xine (while the error detection in ao_alsa_delay() should still be fixed). i had to search two days for the cause and i feel it might be important to share this experience since somebody else might run into such a problem too.. while debugging i recognized a massive jump in the hw_vpts counter. since this counter is the reference for the gap calculation xine detected a large gap, completely screwed up and dropped almost every frame which lead to the silence. the gap has been such enormous that it couldn't be compensated (> abs(60000)). i tracked the thing back and learned that hw_vpts is directly derived from the monotonic clock which in turn is generated by the kernel (ok i assume you all knew that already ;)). this lead me to a google search for monotonic clock jumps which soon resulted in tsc clocksource drifts. ironically i had a similar experience recently with the usleep() gibc function and even wrote a blog post on that.. however; it is widely known hat the tsc clocksource drifts and jumps like hell, sometimes within the range of hours, especially on amd cpus. my system here is intel atom based but is also affected. long story short: i added notsc to the kernel parameter and it runs stable now. cheers, frank Am 29.03.2010 11:03, schrieb Frank Enderle: > hi, > > i discovered problems playing an audio stream through xine-lib. now i > tracked the problem down into the ao_alsa_delay() function of the > audio_also_out module. this function utilizes snd_pcm_delay() to get the > delay, which returns -32 (broken pipe). there seems to be no real error > handling for this case and this results in a broken audio output which > is not resolved. > > so i have the following questions: > > - why does this happen? > - how can it be resolved? > > i'm not very familiar with alsa. what i would try (if i knew how to do > it) is to reopen the sound device in case of failure. this will surely > produce an audio glitch, but i guess it'll continue to play. > > any help would be appreciated. > > thanks.. > > frank. > -- Dipl.-Ing. (FH) Frank Enderle anamica UG (haftungsbeschränkt) Beinsteinerstr. 6 71334 Waiblingen Telefon: +49 151 14981091 Telefax: +49 7151 1335770 E-Mail: fra...@an... Internet: www.anamica.de Handelsregister: AG Stuttgart HRB 732357 Geschäftsführer: Yvonne Holzwarth, Frank Enderle |
From: VDR U. <use...@gm...> - 2010-03-30 19:18:34
|
Could the bug you've found be responsible for this error in xine? pcm_hw.c: snd_pcm_hw_delay() SNDRV_PCM_IOCTL_DELAY failed. Thanks |
From: Frank E. <fra...@an...> - 2010-03-30 19:24:35
|
sorry - this i don't know.. obviously this was only part of the problem.. i still have the same problems just not that often anymore. i currently do further research if the problem is really related to the monotonic clock or if it's a miscalculated delay from alsa. i'm really running out of ideas here - so if anyone has an idea feel free to share it.. Am 30.03.2010 21:18, schrieb VDR User: > Could the bug you've found be responsible for this error in xine? > > pcm_hw.c: snd_pcm_hw_delay() SNDRV_PCM_IOCTL_DELAY failed. > > Thanks -- Dipl.-Ing. (FH) Frank Enderle anamica UG (haftungsbeschränkt) Beinsteinerstr. 6 71334 Waiblingen Telefon: +49 151 14981091 Telefax: +49 7151 1335770 E-Mail: fra...@an... Internet: www.anamica.de Handelsregister: AG Stuttgart HRB 732357 Geschäftsführer: Yvonne Holzwarth, Frank Enderle |
From: Frank E. <fra...@an...> - 2010-03-30 19:40:28
|
i still see a massive drift in the logs though i disabled the tsc completely in the kernel (CONFIG_X86_TSC not set and no trace in dmesg). the system now uses hpet as clocksource. i just had a failure: this is ok: audio_out: (ao_loop:1148) gap current delay is 7807, current time is 306980191 audio_out: (ao_loop:1162) hw_vpts : 306994832 buffer_vpts : 306994795 gap : -37 this also: audio_out: (ao_loop:1148) gap current delay is 8037, current time is 306982108 audio_out: (ao_loop:1162) hw_vpts : 306997181 buffer_vpts : 306997146 gap : -35 here is the jump: audio_out: (ao_loop:1148) gap current delay is 0, current time is 307102569 audio_out: (ao_loop:1162) hw_vpts : 307102569 buffer_vpts : 306999497 gap : -103072 while the cur_time diff is usual around 1000 - 3000 it jumps in the last line by 120000 which screws the soundcard. so it's still a drift in the clocksource sinc cur_time is derived from the montonic clock.. afterwards the audio is gone.. audio_out: (ao_loop:1189) audio package (vpts = 306999497, gap = -103072) dropped audio_out: (ao_loop:1148) gap current delay is 0, current time is 307102755 Am 30.03.2010 21:24, schrieb Frank Enderle: > sorry - this i don't know.. obviously this was only part of the > problem.. i still have the same problems just not that often anymore. i > currently do further research if the problem is really related to the > monotonic clock or if it's a miscalculated delay from alsa. i'm really > running out of ideas here - so if anyone has an idea feel free to share it.. > > Am 30.03.2010 21:18, schrieb VDR User: >> Could the bug you've found be responsible for this error in xine? >> >> pcm_hw.c: snd_pcm_hw_delay() SNDRV_PCM_IOCTL_DELAY failed. >> >> Thanks > > -- Dipl.-Ing. (FH) Frank Enderle anamica UG (haftungsbeschränkt) Beinsteinerstr. 6 71334 Waiblingen Telefon: +49 151 14981091 Telefax: +49 7151 1335770 E-Mail: fra...@an... Internet: www.anamica.de Handelsregister: AG Stuttgart HRB 732357 Geschäftsführer: Yvonne Holzwarth, Frank Enderle |
From: VDR U. <use...@gm...> - 2010-03-30 21:28:43
|
Here's some more from my xine log, dunno if it's useful. 200 frames delivered, 0 frames skipped, 1 frames discarded pcm_hw.c: snd_pcm_hw_delay() SNDRV_PCM_IOCTL_DELAY failed. fixing sound card drift by 1959 pts fixing sound card drift by 1472 pts liba52:a52 frame failed crc16 checksum. pcm_hw.c: snd_pcm_hw_delay() SNDRV_PCM_IOCTL_DELAY failed. fixing sound card drift by 1953 pts pcm_hw.c: snd_pcm_hw_delay() SNDRV_PCM_IOCTL_DELAY failed. video_out: throwing away image with pts 812306225 because it's too old (diff : 2754). fixing sound card drift by 2339 pts H264: mmc 1 failed: 635 not existent - curr_pic: 643 H264: mmc 1 failed: 634 not existent - curr_pic: 643 video_out: throwing away image with pts 812327212 because it's too old (diff : 2768). video_out: throwing away image with pts 812356991 because it's too old (diff : 2985). fixing sound card drift by 1755 pts fixing sound card drift by 1318 pts 200 frames delivered, 0 frames skipped, 3 frames discarded liba52:a52 frame failed crc16 checksum. pcm_hw.c: snd_pcm_hw_delay() SNDRV_PCM_IOCTL_DELAY failed. fixing sound card drift by 2056 pts liba52:a52 frame failed crc16 checksum. audio jump, diff=-46920 pcm_hw.c: snd_pcm_hw_delay() SNDRV_PCM_IOCTL_DELAY failed. audio_out: inserting 20220 0-frames to fill a gap of 37922 pts H264: mmc 1 failed: 383 not existent - curr_pic: 391 H264: mmc 1 failed: 382 not existent - curr_pic: 391 H264: mmc 1 failed: 389 not existent - curr_pic: 393 H264: mmc 1 failed: 387 not existent - curr_pic: 395 H264: mmc 1 failed: 386 not existent - curr_pic: 395 |
From: Darren S. <li...@yo...> - 2010-03-30 21:50:50
|
I demand that VDR User may or may not have written... > Here's some more from my xine log, dunno if it's useful. > 200 frames delivered, 0 frames skipped, 1 frames discarded [snip] > audio_out: inserting 20220 0-frames to fill a gap of 37922 pts > H264: mmc 1 failed: 383 not existent - curr_pic: 391 [snip] Could you both check current xine-lib-1.2 hg? (I don't expect that this'll have any effect on the -EPIPE problem, though. We need somebody who knows ALSA to help out here...) -- | Darren Salt | linux at youmustbejoking | nr. Ashington, | Doon | using Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army | + http://www.youmustbejoking.demon.co.uk/ & http://tartarus.org/ds/ weekend: n. Period of time made for programming. |
From: Frank E. <fra...@an...> - 2010-03-30 23:16:13
|
> Could you both check current xine-lib-1.2 hg? i compiled the f8524daa6eec changeset and till now it runs fine. i will do more intense tests tomorrow but i also have not that much hope that it fixes my issues. Am 30.03.2010 23:48, schrieb Darren Salt: > I demand that VDR User may or may not have written... > >> Here's some more from my xine log, dunno if it's useful. > >> 200 frames delivered, 0 frames skipped, 1 frames discarded > [snip] >> audio_out: inserting 20220 0-frames to fill a gap of 37922 pts >> H264: mmc 1 failed: 383 not existent - curr_pic: 391 > [snip] > > Could you both check current xine-lib-1.2 hg? > > (I don't expect that this'll have any effect on the -EPIPE problem, though. > We need somebody who knows ALSA to help out here...) > -- Dipl.-Ing. (FH) Frank Enderle anamica UG (haftungsbeschränkt) Beinsteinerstr. 6 71334 Waiblingen Telefon: +49 151 14981091 Telefax: +49 7151 1335770 E-Mail: fra...@an... Internet: www.anamica.de Handelsregister: AG Stuttgart HRB 732357 Geschäftsführer: Yvonne Holzwarth, Frank Enderle |
From: Frank E. <fra...@an...> - 2010-03-31 00:54:52
|
> i compiled the f8524daa6eec changeset and till now it runs fine. i will > do more intense tests tomorrow but i also have not that much hope that > it fixes my issues. it just happened again -same issue as with 1.1.18.1 |
From: Frank E. <fra...@an...> - 2010-03-31 13:40:21
|
hi, i tried to pin my problem further down. now i believe that the input plugin can't deliver the data fast enough to fill the audio_out fifo. obviously sometimes fifo_peek() is stuck in pthread_cond_wait() waiting for more data since the fifo seems to be depleted. ince the data arrives from the input side the processing continues, but the time gap can be very big, thus screwing the audio output. i guess this could be compensated by a bigger prebuffering in input_http or weherever.. so my question is: - how can the buffer be adjusted? - is this the metronom prebuffer thingy? frank. Am 31.03.2010 02:24, schrieb Frank Enderle: >> i compiled the f8524daa6eec changeset and till now it runs fine. i will >> do more intense tests tomorrow but i also have not that much hope that >> it fixes my issues. > > it just happened again -same issue as with 1.1.18.1 > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > xine-devel mailing list > xin...@li... > https://lists.sourceforge.net/lists/listinfo/xine-devel -- Dipl.-Ing. (FH) Frank Enderle anamica UG (haftungsbeschränkt) Beinsteinerstr. 6 71334 Waiblingen Telefon: +49 151 14981091 Telefax: +49 7151 1335770 E-Mail: fra...@an... Internet: www.anamica.de Handelsregister: AG Stuttgart HRB 732357 Geschäftsführer: Yvonne Holzwarth, Frank Enderle |
From: VDR U. <use...@gm...> - 2010-03-31 15:16:47
|
On Wed, Mar 31, 2010 at 6:39 AM, Frank Enderle <fra...@an...> wrote: > i tried to pin my problem further down. now i believe that the input > plugin can't deliver the data fast enough to fill the audio_out fifo. > obviously sometimes fifo_peek() is stuck in pthread_cond_wait() waiting > for more data since the fifo seems to be depleted. ince the data arrives > from the input side the processing continues, but the time gap can be > very big, thus screwing the audio output. This sounds similar to what an alsa dev told me about my problem. He said that 'xine is not delivering data fast enough in some cases'. I actually made a bug ticket for it here (to my knowledge nobody has even looked into it yet): http://bugs.xine-project.org/show_bug.cgi?id=332 Here's a snippet of what the alsa dev told me based on logs I sent him: [pid 9629] 1268511516.215224 ioctl(18, 0x400c4150, 0xb43631a4) = 0 ^^^^ here xine feeds new samples to the ALSA driver (0x400c4150 == SNDRV_PCM_IOCTL_WRITEI_FRAMES) [pid 9629] 1268511516.215275 ioctl(18, 0x80044121, 0xb43632cc) = 0 [pid 9627] 1268511520.700109 ioctl(10, 0xc0104652, 0xb5443f00) = 0 [pid 9629] 1268511520.700340 ioctl(18, 0x80044121, 0xb43632cc) = -1 EPIPE (Broken pipe) ^^^^ next iteration (0x80044121 == SNDRV_PCM_IOCTL_DELAY) - see time difference - 4.485 seconds from last WRITEI The ALSA subsystem is not reponsible for this behaviour - the ring buffer in your case is for about 0.372 seconds of samples. This limit must not be crossed for the click-free playback. |
From: VDR U. <use...@gm...> - 2010-03-30 23:41:35
|
On Tue, Mar 30, 2010 at 2:48 PM, Darren Salt <li...@yo...> wrote: >> Here's some more from my xine log, dunno if it's useful. > >> 200 frames delivered, 0 frames skipped, 1 frames discarded > [snip] >> audio_out: inserting 20220 0-frames to fill a gap of 37922 pts >> H264: mmc 1 failed: 383 not existent - curr_pic: 391 > [snip] > > Could you both check current xine-lib-1.2 hg? > > (I don't expect that this'll have any effect on the -EPIPE problem, though. > We need somebody who knows ALSA to help out here...) This happened while using xine-lib-1.2 r11483, which I had installed after Julian's commit to fix one of the freeze problems with h264. Thanks |
From: Darren S. <li...@yo...> - 2010-03-30 21:47:31
|
I demand that Frank Enderle may or may not have written... > i found the root cause for the problem and this problem is now fixed. it > had nothing to do with xine (while the error detection in ao_alsa_delay() > should still be fixed). [snip] > long story short: i added notsc to the kernel parameter and it runs stable > now. I've been finding that the time stamp counter generally isn't being used, mainly because either HPET is available or cpufreq is getting in the way. So I probably wouldn't see this one anyway... [snip] -- | Darren Salt | linux at youmustbejoking | nr. Ashington, | Doon | using Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army | + http://www.youmustbejoking.demon.co.uk/ & http://tartarus.org/ds/ If a string has one end, it has another. |
From: Frank E. <fra...@an...> - 2010-03-30 21:52:13
|
Am 30.03.2010 23:45, schrieb Darren Salt: > I've been finding that the time stamp counter generally isn't being used, > mainly because either HPET is available or cpufreq is getting in the way. So > I probably wouldn't see this one anyway... the kernel (2.6.33.1) selected tsc, though hpet has been available. this is the behaviour i've seen a lot lately (though tsc is known to be unstable). however - the problem still occurs with hpet - maybe not as often as before but it does.. |
From: Frank E. <fra...@an...> - 2010-04-01 16:52:33
Attachments:
xine-lib-1.1.18.1-alsa_delay.patch
|
hi, i solved my problem and it was neither tsc nor xine. the problem was related to the server streaming the data. the server occasionally dropped a packet which - over time - depleted the buffers in xine. however i have some notes which i feel should be addressed: - there's a bug with the network buffering. if i do the following on a stream mrl open() stop() play() the stream plays, but the buffering is disabled due to the (superflous) stop() call. i think this should not happen. if a stream is not playing a call to stop() should not change internal states. furthermore i would expect xine to cancel all samples in the buffer if i stop() a stream. if i laer resume it using play() it should buffer again and start playing, since there's no such thing as a simple pausing of live streams (ok you could buffer to disk, but this should be app dependend via callbacks or whatever). - i think the alsa driver needs some rework :) the delay() function for example does not recover from errors, though it could. find my patch attached to this mail. - is it safe to assume that xine signals playback_finished to the ui if the playback actually fails? i'm not so sure. i had several occasions due to the buggy streaming server where i have seen xine not working properly in signaling the event - it even tells the app that it is playing (via get_status()) though there's really no audio output. i would like to suggest to insert timing checks in some areas which check if the get() on the fifo's return in a specified time. if not the playback should be canceld. however the feature should be optioned through the config file. i tried to implement such checks for the demuxer and the decoders but with not much luck. also if some subcomponent fails (like audio driver) xine should stop the playback or notify the application. i'd really like to contribute a little more code, but actually i think i have not enough knowledge on audio/video processing.. thanks. frank Am 31.03.2010 15:39, schrieb Frank Enderle: > hi, > > i tried to pin my problem further down. now i believe that the input > plugin can't deliver the data fast enough to fill the audio_out fifo. > obviously sometimes fifo_peek() is stuck in pthread_cond_wait() waiting > for more data since the fifo seems to be depleted. ince the data arrives > from the input side the processing continues, but the time gap can be > very big, thus screwing the audio output. > > i guess this could be compensated by a bigger prebuffering in input_http > or weherever.. so my question is: > > - how can the buffer be adjusted? > - is this the metronom prebuffer thingy? > > frank. > > Am 31.03.2010 02:24, schrieb Frank Enderle: >>> i compiled the f8524daa6eec changeset and till now it runs fine. i will >>> do more intense tests tomorrow but i also have not that much hope that >>> it fixes my issues. >> >> it just happened again -same issue as with 1.1.18.1 >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> xine-devel mailing list >> xin...@li... >> https://lists.sourceforge.net/lists/listinfo/xine-devel > > -- Dipl.-Ing. (FH) Frank Enderle anamica UG (haftungsbeschränkt) Beinsteinerstr. 6 71334 Waiblingen Telefon: +49 151 14981091 Telefax: +49 7151 1335770 E-Mail: fra...@an... Internet: www.anamica.de Handelsregister: AG Stuttgart HRB 732357 Geschäftsführer: Yvonne Holzwarth, Frank Enderle |
From: VDR U. <use...@gm...> - 2010-04-01 18:38:47
|
On Thu, Apr 1, 2010 at 9:52 AM, Frank Enderle <fra...@an...> wrote: > i solved my problem and it was neither tsc nor xine. the problem was > related to the server streaming the data. the server occasionally > dropped a packet which - over time - depleted the buffers in xine. > > however i have some notes which i feel should be addressed: > > - there's a bug with the network buffering. if i do the following on a > stream mrl I've been running your patch all morning and it might just be me but it does seem I'm getting a lot less "pcm_hw.c: snd_pcm_hw_delay() SNDRV_PCM_IOCTL_DELAY failed." in my xine log. However, I am still getting them so maybe it's possible another problem exists as well. Is your patch -supposed to- address the broken EPIPE problem though? I definitely appreciate your time & effort trying to fix some of these things and hope you stay active! |
From: Darren S. <li...@yo...> - 2010-04-07 17:29:39
|
I demand that Frank Enderle may or may not have written... > i solved my problem and it was neither tsc nor xine. the problem was > related to the server streaming the data. the server occasionally > dropped a packet which - over time - depleted the buffers in xine. Would you mind providing a suitable one-line summary and, optionally, some more descriptive text for your patch? [snip] -- | Darren Salt | linux at youmustbejoking | nr. Ashington, | Doon | using Debian GNU/Linux | or ds ,demon,co,uk | Northumberland | Army | + http://www.youmustbejoking.demon.co.uk/ & http://tartarus.org/ds/ Support your local church. Worship at the Bank of England. |
From: Frank E. <fra...@an...> - 2010-04-11 11:08:09
Attachments:
xine-lib-1.1.18.1-alsa_delay_fix.patch
|
Am 07.04.2010 19:28, schrieb Darren Salt: > I demand that Frank Enderle may or may not have written... > >> i solved my problem and it was neither tsc nor xine. the problem was >> related to the server streaming the data. the server occasionally >> dropped a packet which - over time - depleted the buffers in xine. > > Would you mind providing a suitable one-line summary and, optionally, some > more descriptive text for your patch? > > [snip] summary: fixes a flaw on recovering from alsa reported errors in delay() of the alsa audio module description: i noticed some alsa dropouts (loosing audio) while hunting a bug which has been related to a broken streaming server. this resulted in buffers running empty and therefore showed some issues in the alsa driver not correctly applying some recovery procedures provided by alsa itself (snd_pcm_recover() and friends). cheers, frank -- Dipl.-Ing. (FH) Frank Enderle anamica UG (haftungsbeschränkt) Beinsteinerstr. 6 71334 Waiblingen Telefon: +49 151 14981091 Telefax: +49 7151 1335770 E-Mail: fra...@an... Internet: www.anamica.de Handelsregister: AG Stuttgart HRB 732357 Geschäftsführer: Yvonne Holzwarth, Frank Enderle |