Unless you have the visualisation plugin enabled, none of the threads involved in audio playback will be going anywhere near X.  Even if you do, the video sink will be in its own thread, and there should be large enough buffers elsewhere in the pipeline to accommodate any delays caused by X call blockage.

Since I can't decipher much of the scheduler terminology in that thread, maybe you could provide a simple repeatable way of triggering this problem that does not involve compiz?  I saw some mentions of 'x11perf -repeat 100 -scroll500' in the thread, but that doesn't cause rhythmbox to misbehave here.

The test case in http://bhhdoa.org.au/pipermail/ck/2007-June/007806.html makes Rhythmbox skip for me too: Start Firefox, open http://phoenity.com/newtedge/, scroll rapidly up and down with the mouse wheel.

Still no problems here.

Does the same happen for you in totem?

No it does not happen in Totem. I disable visual effects in Totem (with xine back-end), start playing an Ogg Vorbis song, and open the mentioned page in Firefox and start scrolling: no problem. I close Totem, start Rhythmbox, start playing the same file and put Rhythmbox in minimal mode: when rapidly scrolling that page Rhythmbox starts to skip.

I meant totem-gstreamer, as it uses largely the same playback code as rhythmbox (with crossfading disabled, at least).  Comparisons with totem-xine aren't so useful.

I installed totem-gstreamer (gstreamer 0.10.14), and it works fine too with this version.

I don't know what fixed it, but I'm now running ManDdriva 2008.0 final and the skipping does not happen anymore at all, no matter how quick I turn around the Compiz Fusion cube!