timer updates use too much CPU

[Daniel Holbach]

Coming from https://answers.launchpad.net/jokosher/+ticket/3205 moving to http://bugzilla.gnome.org/show_bug.cgi?id=411520 I figured out that my problems recording problems turned out to be gstreamer not being able to cope with incoming data.

Upstream comment: http://bugzilla.gnome.org/show_bug.cgi?id=411520#c3
"The .ogg file sounds a lot like the vorbis encoder is flushing/resetting itself
constantly (which it would do on stream discontinuities, e.g. if alsasrc can't
capture fast enough and there are gaps in the captured input)."

Looking at top, I figured out the following: http://bugzilla.gnome.org/show_bug.cgi?id=411520#c4
"I just noticed that when doing the recording jokosher+metacity+X use 100% CPU.
Could it be the time counter which updates every n+1 ms?"

http://bugzilla.gnome.org/show_bug.cgi?id=411520#c5
"Yes, that could well cause it. The fact that X is also chewing a lot of cpu
definitely points toward redrawing being expensive."

[Jono Bacon (jonobacon)]

I think we need more testing to determine if this performance issue is still present.

[Daniel Holbach (dholbach)]

It is still present in 0.10-0ubuntu2 (backported to hardy). Still ~100% CPU usage, still garbled output (even in a 1 minute recording),

If you need hardware specifications, gstreamer properties or anything else, please let me know.

[Daniel Holbach (dholbach)]

For my mixtape, I still use the
  gst-launch-0.10 alsasrc ! queue ! audioconvert ! vorbisenc ! oggmux ! filesink location=myfile.ogg
pipeline provided by the heroes in Gstreamer land.

If you're into Drum'n'Bass: http://daniel.holba.ch/blog/?cat=12 :-)

[Laszlo Pandy (laszlok)]

I've linked a personal branch to this bug. Please check it out and see if you can confirm this bug after running a local copy of Jokosher with the command Jokosher/Jokosher in the branch directory.

All this branch does right now is disable some of the redraws when playing. The red line will not move so if you want to see where you are move the mouse over some audio -- the mouse move event will trigger a redraw. If this does solve the problem, great we can start optimizing. Otherwise i will disable more things which may cause bad performance.

[Daniel Holbach (dholbach)]

I didn't get around to it yet... I know, I suck.

[Daniel Holbach (dholbach)]

A short recording seems to have worked out fine. I'll try a longer recording now.

Not sure, if it is related, but I get this in the command line a lot (with the regular version)

Traceback (most recent call last):
  File "/home/daniel/jokosher/Jokosher/EventViewer.py", line 205, in OnDraw
    self.DrawWaveform(event.area)
  File "/home/daniel/jokosher/Jokosher/EventViewer.py", line 391, in DrawWaveform
    context.line_to(x, rect.height)

[Laszlo Pandy (laszlok)]

Thanks Daniel, but your traceback is missing the last line, and the last line is the most important. :)

Since I just fixed a bug like that i'm pretty sure this is the one you meant:
Traceback (most recent call last):
  File "/var/lib/python-support/python2.5/Jokosher/EventViewer.py", line 205, in OnDraw
    self.DrawWaveform(event.area)
  File "/var/lib/python-support/python2.5/Jokosher/EventViewer.py", line 391, in DrawWaveform
    context.line_to(x, rect.height)
UnboundLocalError: local variable 'x' referenced before assignment

It is fixed in trunk (bug 261858), and I will be releasing 0.10.1 later tonight so you can upload the fix to Intrepid before the beta freeze.

[Daniel Holbach (dholbach)]

The crash I mentioned is indeed fixed in 0.10.1. Unfortunately my other problem still remains.

I get this a lot (when stopping the recording).
(jokosher:8057): GStreamer-CRITICAL **: gst_clock_set_calibration: assertion `internal <= gst_clock_get_internal_time (clock)' failed

Not sure if the error message is useful to you though.

[Daniel Holbach (dholbach)]

This shouldn't block the upload though.

[Laszlo Pandy (laszlok)]

Yeah i don't know about that error, but i will keep my eyes open when testing.