Bug 603496 - gstreamer-plugins-good-0.10.23-1 : phonon-backend-gstreamer jittery playback
Summary: gstreamer-plugins-good-0.10.23-1 : phonon-backend-gstreamer jittery playback
Alias: None
Product: Fedora
Classification: Fedora
Component: gstreamer-plugins-good
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Benjamin Otte
QA Contact: Fedora Extras Quality Assurance
: 609225 (view as bug list)
Depends On:
Blocks: 622776
TreeView+ depends on / blocked
Reported: 2010-06-13 14:30 UTC by Rex Dieter
Modified: 2010-08-10 11:59 UTC (History)
12 users (show)

Fixed In Version: gstreamer-0.10.30-1.fc13
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 622776 (view as bug list)
Last Closed: 2010-07-23 02:41:47 UTC
Type: ---

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 621566 0 None None None Never

Description Rex Dieter 2010-06-13 14:30:30 UTC
Per my comment on

This update seems to sometimes induce jittery playback in kde when using phonon-backend-gstreamer.  I've now received a couple of independent confirmations.

My best guess is that this has something to do with the pulseaudio gstreamer output plugin (that's the main or only thing that get's used by phonon-backend-gstreamer as far as I can tell).

Downgrading back to gstreamer-plugins-0.10.22-2.fc13 restores reliable playback.

After conversing a bit on irc/#phonon with coling (pulseaudio and phonon developer), we suspected to pa-related commits to g-p-g that are likely suspects.  When/if I find time, I'll try reverting each to try to see if we can narrow this down.

Comment 1 Rex Dieter 2010-06-13 14:31:40 UTC
s/suspected to/suspected two/

Comment 2 Benjamin Otte 2010-06-14 20:15:59 UTC
Filed upstream as https://bugzilla.gnome.org/show_bug.cgi?id=621566

Comment 3 Rex Dieter 2010-06-14 20:31:55 UTC

Comment 4 Benjamin Otte 2010-06-28 12:13:31 UTC
Could someone try if it's still a problem in rawhide when using the prerelease?
(If noone is on rawhide, you could also try copying its libgstpulse.so - though I haven't tested if that works)

Comment 5 Rex Dieter 2010-06-28 15:18:08 UTC
Initial tests using gstreamer-plugins-good- are promising, I'll do something more rigorous here in a bit.

Comment 6 Rex Dieter 2010-06-28 15:40:36 UTC
alright, looks like a winner here, I cannot make it misbehave at all.

Comment 7 Rex Dieter 2010-06-29 18:02:20 UTC
confirmed fix coming in gst-plugins-good , reassigning there.

Comment 8 Rex Dieter 2010-06-29 18:02:32 UTC
*** Bug 609225 has been marked as a duplicate of this bug. ***

Comment 9 J. Randall Owens 2010-07-16 00:16:27 UTC
I mocked a copy of for fc13 (along with the gstreamer & gstreamer-plugins-base), and it fixed this right up for me on both desktops which had this problem.  Will we be seeing this in fc13 updates-testing anytime soon?

Comment 10 Rex Dieter 2010-07-16 01:19:20 UTC
looks like 0.10.30 is on the way.

Comment 11 Fedora Update System 2010-07-16 17:14:30 UTC
gstreamer-0.10.30-1.fc13,gstreamer-plugins-base-0.10.30-1.fc13,gstreamer-plugins-good-0.10.24-1.fc13 has been submitted as an update for Fedora 13.

Comment 12 Fedora Update System 2010-07-23 02:41:30 UTC
gstreamer-0.10.30-1.fc13, gstreamer-plugins-base-0.10.30-1.fc13, gstreamer-plugins-good-0.10.24-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 13 Michael Carney 2010-07-24 16:58:13 UTC
Looks like gstreamer 0.10.30 + orc is actually worse than the earlier version. Now, rather than produce jittery playback after I play two tracks successfully, I get a seg fault in liborc after successfully playing one track. gstreamer's use of orc is new for 0.10.30.

(gdb) run --sync --nocrashhandler --nofork
Starting program: /usr/bin/juk --sync --nocrashhandler --nofork
[Thread debugging using libthread_db enabled]
[New Thread 0xb27f2b70 (LWP 13796)]
[Thread 0xb27f2b70 (LWP 13796) exited]
[New Thread 0xb27f2b70 (LWP 13797)]
[Thread 0xb27f2b70 (LWP 13797) exited]
[New Thread 0xb27f2b70 (LWP 13798)]
[New Thread 0xadbfeb70 (LWP 13799)]
[Thread 0xadbfeb70 (LWP 13799) exited]
[New Thread 0xadbfeb70 (LWP 13800)]
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
[New Thread 0xa8ffeb70 (LWP 13802)]
[New Thread 0xa83ffb70 (LWP 13803)]
[New Thread 0xa77ffb70 (LWP 13804)]
[New Thread 0xa6bffb70 (LWP 13805)]
[Thread 0xb27f2b70 (LWP 13798) exited]
[New Thread 0xb27f2b70 (LWP 13806)]
[New Thread 0xa5cffb70 (LWP 13807)]
[Thread 0xa5cffb70 (LWP 13807) exited]
[New Thread 0xa5cffb70 (LWP 13852)]
[New Thread 0xa52feb70 (LWP 13853)]
[New Thread 0xa48fdb70 (LWP 13854)]
[New Thread 0xa3efcb70 (LWP 13855)]
[Thread 0xadbfeb70 (LWP 13800) exited]
[New Thread 0xadbfeb70 (LWP 13856)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xa77ffb70 (LWP 13804)]
0x010e5967 in orc_x86_emit_push (compiler=0xa6c09380, size=4, reg=37)
    at orcx86.c:120
120         *compiler->codeptr++ = 0x50 + orc_x86_get_regnum(reg);
(gdb) bt
#0  0x010e5967 in orc_x86_emit_push (compiler=0xa6c09380, size=4, reg=37)
    at orcx86.c:120
#1  0x010e5c40 in orc_x86_emit_prologue (compiler=0xa6c09380) at orcx86.c:866
#2  0x010e21ba in orc_compiler_sse_assemble (compiler=0xa6c09380)
    at orcprogram-sse.c:566
#3  0x010cfbdc in orc_program_compile_full (program=0xa6c072b8, target=
    0x1127660, flags=1) at orccompiler.c:215
#4  0x010cfcc1 in orc_program_compile_for_target (program=0xa6c072b8, target=
    0x1127660) at orccompiler.c:127
#5  0x010cfcf7 in orc_program_compile (program=0xa6c072b8) at orccompiler.c:108
#6  0x0112c00b in orc_process_int16 (d1=0xa84e1318, p1=7535, n=2304)
    at tmp-orc.c:135
#7  0x0112a984 in volume_process_int16 (self=0x84e6278 [GstVolume], bytes=
    0xa84e1318, n_bytes=4608) at gstvolume.c:729
#8  0x0112ae36 in volume_transform_ip (base=0x84e6278 [GstVolume], outbuf=
    0xa84c55e0 [GstBuffer]) at gstvolume.c:1015
#9  0x070f1237 in gst_base_transform_handle_buffer (
    trans=<value optimized out>, inbuf=0xa84c55e0 [GstBuffer], outbuf=
    0xa77fee0c) at gstbasetransform.c:2050
#10 0x070f19c8 in gst_base_transform_chain (pad=0x84f9cb8 [GstPad], buffer=
    0xa84c55e0 [GstBuffer]) at gstbasetransform.c:2169
#11 0x0703997d in gst_pad_chain_data_unchecked (pad=0x84f9cb8 [GstPad], 
    is_buffer=1, data=0xa84c55e0) at gstpad.c:4176
#12 0x0703a397 in gst_pad_push_data (pad=0x84e09a0 [GstPad], is_buffer=1, data=
    0xa84c55e0) at gstpad.c:4405
#13 0x070f1a1f in gst_base_transform_chain (pad=0x84e08d8 [GstPad], buffer=
    0xa84c55e0 [GstBuffer]) at gstbasetransform.c:2190
#14 0x0703997d in gst_pad_chain_data_unchecked (pad=0x84e08d8 [GstPad], 
    is_buffer=1, data=0xa84c55e0) at gstpad.c:4176
#15 0x0703a397 in gst_pad_push_data (pad=0x84e0810 [GstPad], is_buffer=1, data=
    0xa84c55e0) at gstpad.c:4405
#16 0x01170935 in gst_queue_push_one (pad=0x84e0810 [GstPad])
    at gstqueue.c:1083
#17 gst_queue_loop (pad=0x84e0810 [GstPad]) at gstqueue.c:1185
#18 0x070670b1 in gst_task_func (task=0x86c3148 [GstTask]) at gsttask.c:271
#19 0x07068718 in default_func (tdata=0x868ab38, pool=0x843f008 [GstTaskPool])
    at gsttaskpool.c:68
#20 0x00438214 in g_thread_pool_thread_proxy (data=0x843c7b0)
    at gthreadpool.c:315
#21 0x00436210 in g_thread_create_proxy (data=0xa84046d8) at gthread.c:1893
#22 0x00334919 in start_thread () from /lib/libpthread.so.0
#23 0x00276cbe in clone () from /lib/libc.so.6
(gdb) list
115         ORC_ASM_CODE(compiler,"  pushw %%%s\n", orc_x86_get_regname_16(reg));
116         *compiler->codeptr++ = 0x66;
117         *compiler->codeptr++ = 0x50 + orc_x86_get_regnum(reg);
118       } else {
119         ORC_ASM_CODE(compiler,"  pushl %%%s\n", orc_x86_get_regname(reg));
120         *compiler->codeptr++ = 0x50 + orc_x86_get_regnum(reg);
121       }
122     }
124     void
(gdb) print compiler
$3 = (OrcCompiler *) 0xa6c09380
(gdb) print *compiler->codeptr
Cannot access memory at address 0x0

Comment 14 Rex Dieter 2010-07-24 17:09:58 UTC
Sounds like a separate issue, which deserves opening a new bug (though I've not experienced it myself yet, listening to amarok playlists a bunch since the update).

Comment 15 Kevin Kofler 2010-07-24 17:15:32 UTC
Looks like yet another JIT causing yet another memory protection issue (see also our eternal struggle with the WebKit JavaScript JIT), this time it's ORC which replaces the previously used canned optimized inner loops from liboil.

Comment 16 Michael Carney 2010-07-30 05:14:02 UTC
This problem (orc + gstreamer 10.30) is either gstreamer generating bad oil code that orc is choking on, or orc is choking on valid oil code generated by gstreamer. It's 100% reproducible. Any suggestions as to what category I should use to submit a bug for this problem? Thanks.

Note You need to log in before you can comment on or make changes to this bug.