#37 ogg playback causes system freezes

[Noam Sturmwind]

Since upgrading to iTunes 4.7 and QuickTime 6.5.2 on Oct. 28, I
have been experiencing intermittent system freezes while playing
ogg files through iTunes. The system freezes -- the mouse pointer
still moves, but nothing can be clicked on or typed -- and the
music immediately stops playing. Several seconds later, everything
unfreezes and the music skips and catches up. It usually seems to
happen when I'm doing something else on the computer while
listening to music, but it's not easily reproducible on demand.

I am running OS X 10.3.5 with OggVorbis.component 1.0d8.

Nothing appears in $(dmesg) when it freezes.

I'm happy to help try to debug this, but I'm not sure where to start.

[Noam Sturmwind]

Logged In: YES
user_id=638114

Some additional info. If I leave $(top -u) running in a Terminal window,
when the system unfreezes iTunes shows as ~90% CPU usage. It quickly
drops back to the normal values of 5-20%.

[Noam Sturmwind]

Logged In: YES
user_id=638114

And a ktrace run on iTunes shows something interesting. $(kdump -m -1
-R) (that's show no bytes of I/O data, and display timestamps relative to
the last entry) shows this happened at the moment of the freeze:

25602 iTunes 0.034642 CALL
pread(0x13,0x1369311,0x4000,0,0x388000)
25602 iTunes 0.000902 GIO fd 19 read 16384 bytes
""
25602 iTunes 0.000215 RET pread 16384/0x4000
25602 iTunes 8.219087 CALL gettimeofday(0xf03869d0,0)
25602 iTunes 0.000082 RET gettimeofday 1101066028/0x41a0ef2c

Note that 8 seconds elapsed between when pread returned and when
gettimeofday was called. This is the only long delay in the whole log file
(over the course of playing several ogg songs, during which it only froze
once).

[Noam Sturmwind]

Logged In: YES
user_id=638114

The latest time this happened, $(dmesg) showed:

IOAudioStream[0x18e1500]::clipIfNecessary() - Error: attempting to clip
to a position more than one buffer ahead of last clip position (0,254b)-
>(1,3b6a).
IOAudioStream[0x18e1500]::clipIfNecessary() - adjusting clipped position
to (1,254b)
IOAudioStream[0x18e1500]::clipIfNecessary() - Error: attempting to clip
to a position more than one buffer ahead of last clip position (b,3ce2)-
>(c,3f46).
IOAudioStream[0x18e1500]::clipIfNecessary() - adjusting clipped position
to (c,3ce2)

This does not happen every time it freezes, and may be merely a
symptom of iTunes trying to catch up.

[Noam Sturmwind]

Logged In: YES
user_id=638114

And now I've even experienced the playback halting for a second, but the
system DIDN'T freeze.

It seems to be all over the place... But the most common is still a full
system freeze with nothing in $(dmesg).

[Craig Blake]

Logged In: YES
user_id=814224

This occurs for me as well in iTunes 4.7 fairly consistently. Very annoying.
Also manifests as a full system freeze every few minutes while playing
Oggs regardless of other activity, even when not doing anything else.

[Damien Uern]

Logged In: YES
user_id=897091

Yes I experience this problem also, as do many others. Makes using
itunes pretty much impossible as most of my music is in ogg vorbis
format. I converted one album to AAC and played that, and experienced
no problems. Unfortunate really. I wish Apple would incorporate vorbis
support in natively to itunes so it would work as well as aac and mp3.

Thanks for the plugin though guys, I would have to convert/re-rip my
entire collection without it.

[Noam Sturmwind]

Logged In: YES
user_id=638114

Have any of you experience with debugging, or experience with
QuickTime components?

I'd like to start a group debugging effort on this. (See https://
sourceforge.net/forum/forum.php?
thread_id=1194671&forum_id=135637) I haven't had a chance to poke at
it yet, but I expect to in the next week or so.

[Jeremy]

Logged In: YES
user_id=1187515

This Bug seems solved with the patch found here:

http://sourceforge.net/forum/forum.php?
thread_id=1012726&forum_id=135636

explanation of what the patch does is in the discussion.. I think that this
patch should be formally submitted and that the component be updated to
a new version to reflect it. this really does fix the speed problem and the
freeze problem.

[Jeremy]

Logged In: YES
user_id=1187515

well, playback and system freezes still occur with the new patch, but no
where near what they were.

I am ripping a CD and playing OGG files and typing fast in a webbrowser
plus have a number of other applications open and have only had one
freeze up. there is certainly still some optimizations to be done.

[Noam Sturmwind]

Logged In: YES
user_id=638114

jpetzold, that patch is a year old and appears to have been incorporated
in some form into the CVS tree. (At least, there are no BeginMediaEdit
calls in the latest code.)

So that's not much help, unfortunately. I still don't know how to track this
down. I added a bunch of syslog() calls in the entry point of the
component (OggVDecompressor.C "OggVDecompComponentDispatch") to
track how long it was spending in various functions called from the
dispatcher, but I found that during a freeze nothing was logged. Either
the freeze is happening in QuickTime, outside the component, or the
system is hung to the extent that syslogd loses log messages. Either
way, I don't know where to go from here.

Unfortunately, it appears impossible to attach gdb or another debugger to
the component while playing in iTunes (presumably they don't want
debuggers attached to iTunes because of protected content).

I haven't been able to reproduce the bug by playing single files in
QuickTime Player (which can be debugged). I really need to queue up a
list of ogg files and let it run for a while, which QuickTime Player can't
do.

[Noam Sturmwind]

Logged In: YES
user_id=638114

I've been able to reproduce the freezes in QuickTime Player now,
meaning that I can attach gdb (which iTunes won't allow) and start doing
some debugging... if only I knew what I was doing!

Can someone advise me on how I should be debugging this with gdb? Or
should I be using some sort of profiling tool, and if so, what?