Suggestions for audio player microcontroller

I'm looking for suggestions for a microcontroller for use in an audio player. This is going to be for a high-end player, not a mass-produced portable, so I'm not bothered about size or power consumption, nor am I worried about getting the lowest possible cost.

It needs to have Ethernet for connecting to the outside world. Some support for wireless networking would be good too, if possible, but that can always be handled by external chips.

It needs I2S outputs at 96 kHz or 192 kHz, 24-bit. It will be stereo only at the moment, but multi channel support is always interesting.

It needs to support a range of formats - probably at least MP3, OGG Vorbis, FLAC, ALE/ALAC, AAC, WMA. This means codec-specific acceleration is of little use, and it will need a fair amount of processing power.

My initial thoughts are the AVR32 and Cortex-M4 devices. I get the feeling that it would be too demanding for Cortex-M3 chips - it's the sort of application where the DSP instructions can be very useful.

I'd rather avoid a DSP chip - I dislike dealing with massive, specialised, closed-source and expensive toolchains that are often required, and I dislike dealing with awkward DSP architectures that are optimised for very fast tight MAC loops but are poor at more general code. I prefer an "ordinary" processor with DSP instructions.

Any thoughts, experiences or suggestions are welcome.

Reply to
David Brown
Loading thread data ...

If you wanted video as well, I would suggest Sigma Designs parts.

formatting link

For example. this part

formatting link
has the sort of I/O you'd want on a SoC (Ethernet, USB, SATA, I2C, etc.), as well as I2S.

It's MIPS though, not ARM.

Disclaimer: I've never used it in a design, but I have noticed that it (and its close relatives) are used in several popular media streamer devices.

Regards, Allan

Reply to
Allan Herriman

Yes, I know about the Sigma parts (we are involved in another design using them - which will do video as well). The parts are good, but it's not very easy to work with them or the company. Mind you, nothing is easy to work with when you are dealing with parts aimed at DVD, Bluray and other "protected" formats - it's not Sigma's fault that there are absurd rules for licensing, encryption, signing, etc.

I'm hoping to use something a bit smaller and simpler for just audio.

Other than that, MIPS is fine - as is ColdFire, and I'll consider other cores too if the tools are right and the chips are good.

Reply to
David Brown

Small form-factor Intel Atom Linux PC with PCIe based I2C interface?

Petter

--
.sig removed by request.
Reply to
Petter Gustad

It's always possible to go that route - or using an embedded Linux with another processor type (MIPS, ARM, etc.). But I think that would be overkill. I don't believe it should be /that/ hard to do the audio decoding I am planning. There are plenty of references to MP3 decoding on Coldfire, Cortex M3 or AVR32 devices using around 10 - 20 MHz for the decoding. Even assuming the other codecs are harder, and higher quality means a bit more decoding time, I believe it should be possible to use a processor in the region of 100 MHz, especially if it has a few DSP enhancements.

After looking around, I think perhaps NXP's new M4+M0 devices might be the ideal device. The M0 can handle the control stuff, such as the network connection, and let the M4 do the decoding.

Of course, it may turn out that using an x86 compatible Linux system is the fastest and cheapest way to get the software running - I'm still looking into that aspect of the system.

Reply to
David Brown

If external flash and RAM are acceptable, take a look at the MPC5200B. It will likely be overkill but then it costs about $25 for 1 chip. You can connect up to 3 AC97 or I2S (the codec modes are countless and really flexible), with FIFOs, smart DMA for which one can do microcode etc. I have DPS running on it for quite some time, I will be glad to help somehow if needed.

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

formatting link

------------------------------------------------------

formatting link

Reply to
Didi

AD: BF-527 TI: TMS C5010

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

The MPC devices are a possibility I hadn't thought of. I'm using an MPC5554 on another project, so I'm familiar with the architecture. I'll look closer at this family - thanks for the tip.

mvh.,

David

Reply to
David Brown

I dislike TI's DSP's, for a whole range of reasons, so I want to avoid them unless there is an overwhelming reason to use them.

The Blackfin's are okay - they are DSP's that look enough like microcontrollers to be interesting. Is the gcc toolchain for the Blackfin good at generating tight code for DSP-style code? I don't want to have to use Visual DSP.

But other than that, Blackfin's should definitely be on my list for further investigation.

mvh.,

David

Reply to
David Brown

ced

I

at

o
e
l

I know you are familiar with the architecture hence my suggestion. The PSC ports - notice that only 1 to 3 are "all capable", 4 and 5 are practically UART only, 6 I always use as an UART but is more capable if not all (forgot). Getting the picture of how many GPIOs etc. you can have depending on configuration can take days before you get really familiar with the device. There is a free monitor for it on my website (under "downloads") which may be handy during initial tests. I will likely make the whole DPS available as well (not for free for production but free for development), I just need to be able to take my breath from the project I am finishing. And finally, my recent experience can confirm 64*64 bit FP MAC can be done at somewhat below 6 nS/MAC (from a DDRAM buffer ->

DDRAM buffer), but this is not as trivial and straight-forward as in a conventional DSP (doing it "conventionally" yields something like 20 to 25 nS per MAC on the same 400 MHz machine).

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

formatting link

------------------------------------------------------

formatting link

Reply to
Didi

I use VDSP; can't comment on Blackfin GCC. VDSP optimizer does fair job; but if you need a really fast DSP code, you have to write it by hand.

VLV

Reply to
Vladimir Vassilevsky

That's what I am afraid of, based on past experience with a couple of DSPs. It can certainly be fun doing that sort of work, but it is time-consuming to learn the architecture in such detail, and to write code that really takes advantage of the DSP engine. I've seem many cases where the manufacturer of the chip and/or tools claim that you can program the DSP algorithms in C - what they often mean is you can use C intrinsic functions that are basically the assembly functions wrapped up to look like a C function.

Learning a DSP at this level, as I say, can be fun - but unless you are going to use the chip a lot, it is too time consuming.

Using a processor with a more microcontroller style but with MAC-type instructions, along with a good compiler, is far more efficient for the developer even though it will need more clock cycles on the chip.

Reply to
David Brown

Looks like you have an idea to take some available reference code of the multimedia codecs and compile it. That might even work, although is going to be very inefficient both as the algoritm and as the code.

There is no good way to utilize eficiently the low level DSP features of a chip from C. Unless you call a hand written library functions. Vendors supply libraries with basic algorithms such as filtering and FFTs. Also, AD and TI provide the entire codecs such as jpeg, mpeg, mp3, wma, wmv, etc.

VLV

Reply to
Vladimir Vassilevsky

Yes, that's about right - though I'm hoping more for "somewhat inefficient" rather than "very inefficient". It's a matter of balance - if I can find a processor and reference code that gives me a result that is reasonably efficient, then it probably makes more sense to use a faster processor than to spend the time getting the code to run optimally (and therefore on a slower processor). It would be a different matter if the production quantities were higher - it all boils down to the total cost of the project, development and production combined.

That's also true. And it may be that the availability of codecs like these will make me choose something like a Blackfin if it leads to less time and cost overall. My concern with that path, however, is that the chip will work well for the system-optimised codecs provided by the manufacturer, but poorly for everything else. It can also be very difficult to modify code like this (whether it is in assembly, or highly system optimised C code), if that becomes necessary.

One other advantage of the Blackfins over the Cortex M4 that I have been thinking about is that the Blackfins are actually available...

But I'm still collecting ideas at the moment, and I thank you (and others here) for giving me more points to think about.

mvh.,

David

Reply to
David Brown

dio

am

id

ob;

e
-

d.

f
s
,

etc.

When I saw the thread title I was going to recommend the Green Arrays GA144 as being pretty good for your app. But if you want to compile C code for it you aren't likely to get far with this part. Otherwise it is perfect for a portable audio app.

Rick

Reply to
rickman

The web site leaves me with the feeling that those devices are made to work with Forth. Is that right?

Mel.

Reply to
Mel

That's an interesting device! It isn't going to work for us - any code we get hold of will be in C, and my Forth is a bit rusty (about 20+ years rusty...). But it is interesting nonetheless.

I am also looking at the xmos devices - there is a certain similarity in the design concepts but it is a better match for our needs.

mvh.,

David

Reply to
David Brown

I wonder why is that? What would be reason(s) to avoid TIs? I'm not trying to challenge you, just hoping you will share your knowledge with us.

--
--
StoneThrower
 Click to see the full signature
Reply to
StoneThrower

The reference code is developed with clarity and portability in mind. It could be ridiculously inefficient. Like, for example, they could move data in arrays instead of making cyclic buffers. However, several hundred MIPS should be plenty enough for one channel of stereo audio even in this case.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

There is one good thing about TI DSPs: TI is mainstream, there are many customers, therefore the hardware and the tools are relatively clean from bugs.

There are several not-so-good things about TI DSPs:

  1. TI assembler is difficult and inconvenient.
  2. TI documentation is tough to comprehend.
  3. TI hardware is insanely complicated and illogical.
  4. TI support don't even bother with the people that they don't know.
  5. Doing things in "TI way" means incredible amount of bloat.

However, TI is a mainstream, and I have to deal with that.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.