Dsp Can Play Mp3, What About Flac/ogg?

[hessiess]

There has been allot of discussion on the dsp being able to play mp3 in some lo power mode. but what about a format that actually sounds good like FLAC? for me mp3, no matter what bit rate, always sounds very 'tinny' in the high frequancys.

 

[icurafu]

lol - signature.

I had a good look and cant find anything on the interweb about it. TI list a few codecs and says "and more" after.

Maybe a TI rep should provide a full list. It's no marketing a product and not fully disclosing the capabilities.

 

[Exophase]

The DSP is programmable so it can support anything that someone writes for it. But I expect that FLAC will have a low enough CPU decode already that just a simple port of a FLAC player will suffice. Whether or not it'll have this at launch I don't know.

 

[Megamixman]

I believe TI provides libraries for DSP Mp3 decoding. For formats they don't provide, it is simply a matter of someone coding a DSP algorithm for it.

 

[icurafu]

I saw 3rd party libs for c54 for FLAC, but nothing on IVA2+

 

[Exophase]

I saw 3rd party libs for c54 for FLAC, but nothing on IVA2+

I would think porting from one to the other wouldn't be that hard for someone who knows what they're doing.

 

[danboid]

+1 to seeing DSP decoding of ogg and FLAC on Pandora

I would imagine that if this can be handled by the DSP it would be more power efficient than having the CPU do it and so we'd be able to squeeze some truly impressive music playback uptime out of andora1:

 

[Megamixman]

The thing to remember with codecs like FLAC is they are far more bus intensive then they are cpu intensive. So moving MP3 to the DSP makes sense, because that is where most of the power likely going to be drawn. For FLAC, it will be the memory and memory bus, so making a DSP codec for FLAC might not make sense.

 

[hessiess]

QUOTE
The thing to remember with codecs like FLAC is they are far more bus intensive then they are cpu intensive. So moving MP3 to the DSP makes sense, because that is where most of the power likely going to be drawn. For FLAC, it will be the memory and memory bus, so making a DSP codec for FLAC might not make sense.


what about OGG/vorbis on the DSP?

 

[Megamixman]

OGG/Vorbis reduce the size of files down to the same realm as Mp3, so they are likely to benefit from a DSP codec.

 

[sam fisher]

OGG/Vorbis reduce the size of files down to the same realm as Mp3, so they are likely to benefit from a DSP codec.

I believe that on the GP2x Dzz implemented Tremor on the 940t co-processor. So I guess it may be possible for someone to just do something similar but with the DSP instead.

 

[Exophase]

OGG/Vorbis reduce the size of files down to the same realm as Mp3, so they are likely to benefit from a DSP codec.

I believe that on the GP2x Dzz implemented Tremor on the 940t co-processor. So I guess it may be possible for someone to just do something similar but with the DSP instead.


That's a port of C (and perhaps some ARM) code. Trying to port C code to the DSP might work, but with the compilers that'll be publicly available I think the result is going to be terrible. So unless someone has the official tools then porting it so that it runs well for the DSP would be a major rewrite and not very trivial to do.

 

[Megamixman]

Correct, porting direct code is useless when you're talking about a DSP. You need to rewrite the code with the DSP in mind. This means going back to the basic mathematical algorithm and working from there. Thankfully, most major parts of audio codecs can be broken down into Algorithms that are common to DSPs. There are plentiful sources of DSP optimized code for these common algorithms, which should provide a very good starting point for anyone looking to rewrite a codec.

 

[ldesnogu]

That's a port of C (and perhaps some ARM) code. Trying to port C code to the DSP might work, but with the compilers that'll be publicly available I think the result is going to be terrible. So unless someone has the official tools then porting it so that it runs well for the DSP would be a major rewrite and not very trivial to do.

I have posted the link to the free DSP tools weeks ago Look at the wiki.
TI has released full featured DSP compiler for free software usage (see the license).

 

[Exophase]

I have posted the link to the free DSP tools weeks ago Look at the wiki.
TI has released full featured DSP compiler for free software usage (see the license).

Okay, that's good then.

But it's still far from just a simple port to make use of the tools.

 

[ldesnogu]

But it's still far from just a simple port to make use of the tools.

Yes, if you want optimised code, but that's no harder than writing ARM NEON code.
TI C compiler is ANSI compliant, so for portable fixed-point code, that shouldn't be hard (as soon as TI provides the definitive DSP/MPU "communication" library).
As usual, making the code go fast will be the hardest and most time consuming part, but isn't that true for any software and platform?

 

[pupnik]

But it's still far from just a simple port to make use of the tools.

Yes, if you want optimised code, but that's no harder than writing ARM NEON code.
TI C compiler is ANSI compliant, so for portable fixed-point code, that shouldn't be hard (as soon as TI provides the definitive DSP/MPU "communication" library).
As usual, making the code go fast will be the hardest and most time consuming part, but isn't that true for any software and platform?

simon pickering has a semi-working OGG playback on OMAP2420

 

[lardman]

It's not really working though, I'm suffering from a buffer corruption and it's a real pita to debug (using dspgateway, so my only way of getting data out is with dbg() which is effectively a printf() ).

Anyway, I'll get back to it eventually. Does the C64xx support 8bit types? (I thought I read this somewhere). If so, that'll make porting things much easier.

 

[ldesnogu]

Anyway, I'll get back to it eventually. Does the C64xx support 8bit types? (I thought I read this somewhere). If so, that'll make porting things much easier.

Yes it does, it should be much funnier than the c55
More info here: http://www.ti.com/litv/pdf/spru732g

 

[lardman]

Great, well that will remove the major problem in porting code, those pesky 8-to-16bit conversions one always misses

Optimisation and writing code which can be optimised is still going to be needed, but it's much easier once you've got at least something running!