GNOME Bugzilla – Bug 116882
Thread extracting progress for speed
Last modified: 2005-07-14 11:09:22 UTC
I've run a few speed tests on suspicion that Grip was much faster than SJ at extracting audio, and have discovered that I wasn't just paranoid. For example, when ripping Smashing Pumpkins "Pisces Iscariot", I get the following results: Grip: 6 minutes 30 seconds to rip and encode Sound Juicer: 10 minutes 10 seconds to rip and encode Ogg settings in both programs should be identical (-q 6) and I'm using full paranoia for both Grip and SJ. This might be a Gstreamer problem, but I wasn't sure, so I filed it against SJ.
This must be a gstreamer bug. How can it be a SJ bug ?
I'm not a coder - I wasn't sure if it was gstreamer or the way in which SJ was <em>implementing</em> SJ. Since I'm unqualified to answer the question, I just left it up to Ross, who would know the answer for sure...
Err... that's "the way in which SJ was implementing *gstremer*" not "SJ implementing SJ". Ahem.
Ross, Can you confirm/deny that the bug here is with gstreamer and not s-j? I'd really like to at least get this bug filed correctly so that this bug can get some love...
I'm not entirely sure if SJ or GStreamer is to blame here. I could possibly be Sound Juicer's fault -- I'm running the gstreamer pipeline in the GTK+ event loop which could be resulting in slower processing than would be possible if I ran GStreamer inside a thread. I'm avoiding a thread at the moment as it introduces another source of crashes :)
*** Bug 126467 has been marked as a duplicate of this bug. ***
CVS versions of SJ (to be 0.5.13) call gst_bin_iterate() more often which should result in a better speed. Another speed comparison would be good if Jens can still do them.
Eek. Well, I'm no longer using the same computer, and I'm not sure where that Smashing Pumpkins CD is at the moment, but I've done another test regardless. This PC is a good deal faster, and is running Fedora Core 3 test 2; I think this bug was filed running Fedora Core 1. Let me know if you'd really like to see numbers run with the original PC, etc - if it's important I might be able to get access to the PC I ran the original benchmark on. As for this benchmark's settings - Grip has 4 different rip "quality vs speed" checkboxes - I used 3 configurations of these, figuring (hoping?) they might be the most common use cases. Since Sound Juicer doesn't store its paranoia settings in GConf anymore, I'm not sure which is the best apples-to-apples comparison... Anyway, here's what I came up with: CD: Low - Long Division Length: 49:09 All encoding was done at Vorbis q6 SJ: total time: 11:24 speed: 4.3x Grip: settings: [ ] Disable paranoia [ ] Disable extra paranoia [ ] Disable scratch detection [ ] Disable scratch repair total time: 10:00 speed: 4.9x settings: [ ] Disable paranoia [x] Disable extra paranoia [ ] Disable scratch detection [ ] Disable scratch repair total time: 9:03 speed: 5.4x settings: [x] Disable paranoia [x] Disable extra paranoia [x] Disable scratch detection [x] Disable scratch repair total time: 6:20 speed: 7.7x
OK, times are getting closer. SJ still does store the paranoia setting in GConf, /apps/sound-juicer/paranoia. 4 by default (overlay checking), set to 255 for full paranoia.
You're not going to get any better results unless you call gst_bin_iterate even more often (and hog the UI), or switch to using threads...
I've got more important things to work on, but I'll accept (tested) patches to use threads. Anyone?
Hi. If you go to gconf-editor and set paranoia to 0, you obtain extra speed. This is equal to disable paranoia in grip.
*** Bug 166771 has been marked as a duplicate of this bug. ***
I've been told that a good pipeline to use is: cdparanoia ! queue ! { encoder ! sink }
I'd be very happy to test and benchmark a patch that used the "cdparanoia ! queue ! { encoder ! sink }" pipeline - I can't write such a thing though, as I don't speak C yet. Getting this nailed would rock. =)
Committed a threaded pipeline.