From: Magnus Holmgren <magnushol_at_gmail.com>
Date: Mon, 31 Dec 2012 14:37:42 +0100

On 2012-12-31 13:54, Jonas Wielicki wrote:

> Well yeah. I just started to dig into the opus code, as I really feel it
> should be possible to make this perform better. With vorbis, I get
> fluent playback without any hassles in the UI and no CPU overclocking at
> all (except while reading from the non-DMA HDD).

As I recall it, Vorbis wasn't realtime in the early versions, so quite a bit of
optimization has been done since then.

> I am totally unfamiliar on how opus works (reading the RFC right now),
> also I have no knowledge about the rockbox codec framework. Can you give
> me some pointers on where to start if I were to optimize this? Are there
> any known bottlenecks inside or at the interface from rockbox to opus?
> Or do I have to look for opportunities in the libopus code? Is there any
> hope at all for such an ancient target as the H320? Is there any
> extensive documentation on how to integrate new codecs into rockbox
> (which would give me some pointers on how codecs and rockbox interact,
> which will be valuable)? If I have to modify the libopus code, how
> would I make sure that this (a) won't break on an upstream update and
> (b) might go back to upstream in case it's valuable for them too?

Based on my experience with the H140, I'd say start looking at what data is put
in IRAM. The external memory bus is pretty slow in comparison to IRAM, so
putting "hot" buffers and tables in IRAM can make a big difference. The next
step would probably be some assembler code, e.g. to exploit the
multiply-and-accumulate unit. If you can get the profiling code working, that
could help locating hotspots.

Note that I haven't looked at the Opus code, so I don't know how much of this
has been done.

-- 
   Magnus

Received on 2012-12-31