Rémi Denis-Courmont wrote:
tags 665732 = moreinfo help unreproducible
thanks
Hello,
Le mardi 26 février 2013 17:33:21, Johann Klammer a écrit :
Adding a usleep(10000) after the last aout_unlock() in aout_DecPlay() in
src/audio_output/dec.c solves the problem for me.
Unfortunately that does not really help pinpoint the problem. It is likely a
race, but it could be anywhere. Without a stack trace of the freeze or a way
to reproduce the problem, there is nothing I, as a VLC developer, can do about
this bug report.
Could only find those two points where the audio output lock was taken...
Changing volume (with ALSA) exhibits a noticeable delay of a few tenth of a
second, due to buffering in the ALSA driver. That is neither new and nor
fixable. Several seconds of delay is abnormal.
it's more than just seconds(perhaps because it's single core box)...
Lockup can be broken by doing stuff to shake up the scheduling...
switching console<->xorg, disk activity etc..
While a kernel bug cannot be completely ruled out, a bug in libpthread seems
more probable. With that in mind, it would be good to know if the bug
reproduces with *unoptimized* libpthread builds (on i386, this can be achieved
by removing the libc6-i686 package).
I am using the i386 versions of everything...
Starting the gdb while it's locked up shows that
it blocks in ___lll_lock_wait in eglibc's lowlevellock.S...
the i486 variant...(there's no i386 because of xchg insn)
...also it's the same for i686(which just includes the 486 version)...
And there's a __GI_poll done somewhere inside libasound.
...it sleeps there...
Yes, the sched_yield() does the trick, too.
_______________________________________________
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
