Re: Opus codec developments

>The part taking the most cycles in celt is the fft/imdct at the moment. I have been contributing some patches with optimizations in this area upstream and hope that soon we will be able to merge in the upstream codec to rockbox. It also has some other optimizations and other improvements that migh

Re: Opus codec developments

Hi again >> Gcc doesn't handle the coldfire EMAC at all so you can only use the >> special regs in asm, not bind them to c vars. Take a look at how this >> is done in other functions, there are lots of them, an example is >> MULT16_32_Q15 in the fixed_generic.h file you were editing. > I've seen t

Re: Opus codec developments

Hi Nils, On 02.01.2013 10:19, Nils Wallménius wrote: > I have been contributing some patches with > optimizations in this area upstream and hope that soon we will be able > to merge in the upstream codec to rockbox. It also has some other > optimizations and other improvements that might help us.

Re: Opus codec developments

On Tue, Jan 1, 2013 at 11:42 AM, Jonas Wielicki wrote: > On 01.01.2013 08:52, Mike Giacomelli wrote: >> >>> Okay. A quick grep for iram_ showed that this is not used at all yet. >> >> The actual defines are ICODE, ICONST, IBSS, and IDATA. > I see -- I more thought about dynamic allocations as they

Re: Opus codec developments

On 01.01.2013 08:52, Mike Giacomelli wrote: > >> Okay. A quick grep for iram_ showed that this is not used at all yet. > > The actual defines are ICODE, ICONST, IBSS, and IDATA. I see -- I more thought about dynamic allocations as they are used in the vorbis codec, where iram_alloc is used if I r

RE: Opus codec developments

> Okay. A quick grep for iram_ showed that this is not used at all yet. The actual defines are ICODE, ICONST, IBSS, and IDATA. Maybe someone else can help you with your ASM problems (I don't know coldfire).

Re: Opus codec developments

On 31.12.2012 14:37, Magnus Holmgren wrote: > 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 proba

Re: Opus codec developments

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-D

Re: Opus codec developments

This goes to the kind people who integrated opus into rockbox. Please see my questions below, this isn't a rant. On 16.08.2012 17:00, Dave Hooper wrote: > What's the performance of the current implementation like (compared to > other codecs on rockbox today)? I tested opus on my iriver H320 yeste

Re: Opus codec developments

On 11.10.2012 16:42, Mike Giacomelli wrote: > Its in, its works, although high bitrate files won't decode on older hardware > yet. What specific resources are you looking for? > > Something like an entry at , just

RE: Opus codec developments

> Just want to ask back what the current status of Opus codec in rockbox > is? Are there any official resources? Its in, its works, although high bitrate files won't decode on older hardware yet. What specific resources are you looking for?

Re: Opus codec developments

Just want to ask back what the current status of Opus codec in rockbox is? Are there any official resources? Now that opus is finally specified it would be nice to have. cheers, Jonas

RE: Opus codec developments

>Is the existing codeclib mdct being used now (which is already heavily >optimised)? Or is optimisation lower down the priority list and/or mdct not >the bottleneck? We can't use the codeclib MDCT as Opus does not use power of 2 transforms. It uses its own FFT based on KISSFFT. Algorithmic

Re: Opus codec developments

Is the existing codeclib mdct being used now (which is already heavily optimised)? Or is optimisation lower down the priority list and/or mdct not the bottleneck?

Re: Opus codec developments

What's the performance of the current implementation like (compared to other codecs on rockbox today)? (Apologies for the double-post if you received this message once already - from my end it looks like it was blocked by the list server when I first sent this a couple weeks ago)

Re: Opus codec developments

Doesn't tremor (which is the vorbis codec used by rockbox) incorporate the non-memcpy version of libogg?

Re: Opus codec developments

Just an update ... The bleeding edge of opus development can now be found at: https://github.com/freqmod/rockbox-opus I synced this to recent rockbox at: http://gerrit.rockbox.org/r/#/c/300 (this also shows the current issues) Currently, the main issues are: * Still needs too much stack for our

Re: Opus codec developments

On 2012-07-27 18:00, Rafaël Carré wrote: A call to codec_set_replaygain() when starting a new track should be enough. It looks like the existing tag parsing code is used; if so Replaygain tags are already handled. I think the tags are not read at all from the file: http://git.videolan.org/?p=

Re: Opus codec developments

Le 2012-07-27 15:24, Bertrik Sikken a écrit : > On 26-7-2012 8:25, Rafaël Carré wrote: >> Le 2012-07-26 14:08, Bertrik Sikken a écrit : >> Ideally we should go and replace malloc() by static buffers using worst >> case possibilities when possible. > > The mallocs still being done, are done only a

Re: Opus codec developments

Le 2012-07-27 15:32, Magnus Holmgren a écrit : > On 2012-07-27 15:24, Bertrik Sikken wrote: > * Applying global gain from the opus audio file is not implemented (not sure if replaygain is working) >>> >>> Fixed (it's part of the codec, not related to replaygain although we >>> might w

Re: Opus codec developments

On 2012-07-27 15:24, Bertrik Sikken wrote: * Applying global gain from the opus audio file is not implemented (not sure if replaygain is working) Fixed (it's part of the codec, not related to replaygain although we might want to implement replaygain for e.g. vorbis too). Thanks. (Replayg

Re: Opus codec developments

On 26-7-2012 8:25, Rafaël Carré wrote: > Le 2012-07-26 14:08, Bertrik Sikken a écrit : >> Stuff that still needs work: >> * Memory allocation in the codec main is not fully consistent yet (probably >> leaking some memory), so playing several files in sequence may not work > > What do you mean by

Re: Opus codec developments

Le 2012-07-26 14:08, Bertrik Sikken a écrit : > Hi all, > > Me (bertrik) and freqmod (Frederik M.J. Vestre) have been working on porting > a new codec to rockbox, the opus codec, see also http://www.opus-codec.org/ > This codec is backed by an IETF draft and I consider it as the next > evolution b