Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Deprecated: Function create_function() is deprecated in /sites/ on line 104 Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /sites/ on line 845 Deprecated: Function create_function() is deprecated in /sites/ on line 111 FS#6848 : Optimizations to Vorbis codec



FS#6848 - Optimizations to Vorbis codec

Attached to Project: Rockbox
Opened by Tomasz Malesinski (tmal) - Sunday, 18 March 2007, 14:05 GMT
Last edited by Tomasz Malesinski (tmal) - Tuesday, 25 September 2007, 21:02 GMT
Task Type Patches
Category Codecs
Status Closed
Assigned To No-one
Operating System SW-codec
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


I made some optimizations to the Vorbis codec. vector.patch is only for ARM (it shouldn't change anything for Coldfire), others should make the codec slightly faster on all targets. I would like someone to check how these patches affect CPU boost ratio on Ipod and Coldfire based targets.

Please note bug  FS#6847  when testing this (make sometimes needs to be run twice to relink the codec).
This task depends upon

Closed by  Tomasz Malesinski (tmal)
Tuesday, 25 September 2007, 21:02 GMT
Reason for closing:  Accepted
Additional comments about closing:  Two of the patches were committed. I'll take a look at coupling.patch and possibly resubmit it later. Meanwhile I have some new patches.
Comment by Dominik Riebeling (bluebrother) - Sunday, 18 March 2007, 15:21 GMT
I just did a short comparison on my mini. I looked at the boost ratio in the audio thread debug screen, and after a while it settled at around 46% with patch as well as without the path. File is -q 5 and I waited for the buffer to get filled completely before I looked at the screen. Playback was running for about 5 minutes.
Comment by Dominik Riebeling (bluebrother) - Sunday, 18 March 2007, 15:32 GMT
D'oh! I got the rebuild issue of  FS#6847  and didn't notice it :(
Ok, ran the test again and boost ration now drops to 36%. Nice improvement!
Comment by Nils Wallménius (nls) - Sunday, 18 March 2007, 22:29 GMT
I tested the coupling and codebook patches on my h300, the coupling patch did not affect boost ratio at all (i think i saw a slight decrease but it could just as easily have been my imagination) i verified that the patch had taken by diffing the vorbis.codec files between testing and did reboot my player.
The codebook patch had a problem, all music had turned into horrible noise, but the boost dropped about 10% on one test track with both patches :-)

edit: it works fine in the sim, maybe an endian issue?
Comment by Thom Johansen (preglow) - Friday, 23 March 2007, 00:13 GMT
Adding endian swap to both reads from ptr[] seems to fix it. Gains also for Coldfire, but not so much as for ARM.
Comment by Sylvain Fourmanoit (syfou) - Friday, 23 March 2007, 05:38 GMT
coupling.patch seems to have an adverse effect on decoding of very low quality (-q -1) vorbis encoded with both libvorbis or libvorbis + aotuv; once applied, output is more choppy, and channel discontinuity more noticeable (at least on the Sansa E200 target).
Comment by Nils Wallménius (nls) - Friday, 23 March 2007, 15:00 GMT
Here is an updated version of the codebook patch that works on coldfire, I used
the letoh32() macro when ptr[] is accessed like preglow suggested so it should
still work fine on little endian devices too.

I did a little testing on my h300.
The firs number is boost ratio with a current svn build and the second is with the codebook patch.
Jewel of the summertime (q4) 16% 11%
Sabbath bloody sabbath (q6) 21% 12%
Ölstugan som inte finns (q4) 10% 6%
Comment by Tomasz Malesinski (tmal) - Saturday, 24 March 2007, 15:16 GMT
Thanks for catching and correcting endianess issue. I commited codebook and vector patches.

Sylvain, did you notice the difference with only the coupling patch applied? I looked at the patch and could not find any bug, I also checked the output with and without the patch and could not see the difference. Could you provide me with a file that exposes the problem?
Comment by Sylvain Fourmanoit (syfou) - Sunday, 25 March 2007, 08:23 GMT

applying only codebook.patch and vector.patch does not seem to affect the audio output quality; applying coupling.patch, alone or at the same time than the two others had a significant impact in my case. Here are a few clips for you to listen to:

I am not sure how much of the real hardware rockboxui emulates or simulates (I am pretty new to Rockbox), but the audiodump it generates is flawless, unlike what I hear on the real thing unfortunately, so I am not sure any of your code is even wrong... I should probably point out that the decoding of a vorbis stream encoded at higher quality (-q 3 for instance) is not affected by your patch from an audio standpoint... I wish I could help you more.
Comment by Dave Hooper (stripwax) - Monday, 02 April 2007, 23:12 GMT
What happens if mag>0 and ang= -2^31? Won't d=-d result in overflow? It looks like the original code would not overflow in this case. Maybe Sylvain's bug report results from the different ways the target and the sim behave in this situation.

I wonder if using ARM's conditional instructions could result in smaller/faster coupling code. (I haven't seen the output of gcc for the coupling code though)
Comment by Dominik Riebeling (bluebrother) - Wednesday, 01 August 2007, 15:19 GMT
afaict this has been submitted to svn except the coupling stuff. Does that still apply or can this task be closed?
Comment by Sylvain Fourmanoit (syfou) - Wednesday, 01 August 2007, 15:52 GMT
I just applied coupling.patch against rockbox trunk rev. 14120: on my sansa e280, the chopiness it initially caused (audible, vinyl-like scratches) is gone, but channel loss still occurs a few times per song on low quality (-q -1) libvorbis+aotuv.