Skip to main content
Topic: openHiFi - high grade home music player (Read 47749 times) previous topic - next topic

Re: openHiFi - high grade home music player

Reply #75
I have gotten back to this project. Some info and a video are here:

Re: openHiFi - high grade home music player

Reply #76
I read through the last few pages on processor discussion.  Given the dates on this thread a lot has changed in product offerings since.  I would check out the STM32F4 series.  It has an ARM Cortex-M4F at 168 MHz.  A M4F is basically an M3 with a single cycle multiply accumulate instruction, some arithmetic SIMD, and a single precision FPU.  It would be perfect for any codec algorithm.  And as a nice bonus, the F4 series also has 2 I2S interfaces, high speed USB host, 8-bit eMMC or 4-bit SDIO @ 50MHz, Ethernet MII/RMII, 1MB on-die flash, 196KB on-die SRAM, and comes in a LQFP-64 with most of those features!  LQFP-100 if you want external memory and/or Ethernet.  LQFP-144 if you need both.  I've been searching for a MCU with that feature set (plus CAN) for a while.  I call it my 'holy grail' MCU. :)

Re: openHiFi - high grade home music player

Reply #77
i have the st32f4 discovery board, an have not had a good chance to start playing with it yet, but its impressive feature set has pushed it to the top of a list for a future product.

i need to look into finding opensource libraries for the adc/dac and usb.

if there is a eagle library available for it that will save me some time.

Re: openHiFi - high grade home music player

Reply #78
The ST standard peripheral library compiles with gcc and supports both.  They even provide many many USB class drivers for both host access and peripheral emulation.  They also provide a DSP library that includes many common functions - IIR & FIR filters, sliding dot products, a few transforms.

Another nice point is that nearly all of the STM32 line share common or at least compatible pin-outs/muxes.  So if you need a larger or smaller part than what you have selected, you can use the same boards.

ST really has a winner in the STM32 F1, F2, and F4 series.

Re: openHiFi - high grade home music player

Reply #79

I am well aware of Ti, FreeScales and STM's Cortex M4 chips. There is no reason to writing a project that works over from scratch because something else was released. STM32F4 lacks a dynamic memory controller, and does not have an internal PHY for Ethernet compared to the chip selected. This lowers the cost of the chip selected verse STM32F4. While the larger 192 Kb SRAM may allow most decompression schemes to run with buffers that just fit in the SRAM, most media players if you take them apart use large SDRAM/DDR buffers. There would be nothing wrong with selecting STM32F4 if you wanted to, but as for me I like LM3S chips much more than STM32 chips and have written code for both. My productivity writing code for LM3S is about 2-4 times the rate it was writing code for STM32F103.

Re: openHiFi - high grade home music player

Reply #80
[quote author="alanh"]The ST standard peripheral library compiles with gcc and supports both.  ...[/quote]

My memories of the ST Std Peripheral library are that it was more painful to use than just writing code from scratch. I really did not like use of pointer indirection for everything. It made the examples a lot less clear and readable. I just checked that they haven't improved the code base by downloading the latest version and it is still written in the same way.

I remember there was an open source project to writing the library (here it is: ... ontrollers) It was just started last time I used STM32.

If you think the STM32 libraries are great, I would recommend you download StellarisWare (Ti) and just look at the board examples. There isn't really any comparison IMHO, not in terms of topics or usability. Most everything compiles on GCC because codesourcery and crossworks are both gcc based FWIW.

Re: openHiFi - high grade home music player

Reply #81
I never said the std peripheral library was great, just that it exists.

STM32F2/F4's have a 16-bit data/26-bit address parallel bus that can be used to interface SRAM. I wasn't aware Stellaris had a family member with an on-board SDR/DDR DRAM controller.  My mistake.  I also wasn't aware of any audio codec that required several megabytes of RAM for frame level decode; and I've written most.  Again my mistake.

You are correct.  A new product offering is no reason to change an existing design. However an existing design is also no reason to ignore a new product offering.  I was just pointing out it's existence and it's feature set since it was barely announced when the discussion of processor choice a couple pages back was progressing.  Just trying to help not offend.  High speed USB was mentioned.  The eMMC port on the STM32F2/F4 could also be used for an SD card in more than just SPI mode.  M3/M4 code itself is portable as is the toolchain.  The only thing that would need to change is an abstraction layer basically around storage, I2S, and basic UART/GPIOs and you could easily switch to the next great M3/M4 from TI, NXP, or ST that is just around the corner.  Seemed logical to me.

Re: openHiFi - high grade home music player

Reply #82
Sorry Alan. I think the STM32F4 chips would indeed be a reasonable choice today. Certainly one of the main target applications of Cortex M4 is multimedia. I think I overall like the Freescale chips a bit more than ST's but that's based on reading the white papers.

All I was trying to curtail was a protracted discussion on what chips to use. The firmware I will write is going to be for LM3S9xxx chips. It will be open source in the end so people are welcome to port it to something else though like M4 although the DSP stuff wouldn't be directly used. As far as size of buffers, it largely would depend on the CODEC and blocksize. I think FLAC to support the full largest block size may be something like 2 MB though don't quote me on that. The reference encoder for red book audio though uses only 10s of KB blocks (which is still quite big) in a minimal implementation. I am pretty pleased I am able to do the core functions at only 50 MHz, with lots of CPU cycles free.

Re: openHiFi - high grade home music player

Reply #83
I'm currently doing h.264 HD decode (BP) on a 50 MHz M3 with PLD accelerated iDCT.  Next to that, audio is easy :)

The really nice thing about C-M3/M4 is the simplicity of everything.  ISRs with auto-push, initial stack from the reset vector, unified address space, etc.  If you target M3 or M4 and pay attention to separating out MCU specific features, it would be trivial to port the code to the thousands of variants.  I look forward to seeing a finished project.  Sounds like a good idea.  If the DAC module interface is organized well, I'm tempted to make an HDMI transmitter board for it.

Re: openHiFi - high grade home music player

Reply #84
iDCT is the heavy lifting, still that is pretty awesome! I wonder how much CPU Ogg will take (Tremor port probably) as it has DCT in it as I recall.

Re: openHiFi - high grade home music player

Reply #85
My memories of the ST Std Peripheral library are that it was more painful to use than just writing code from scratch.
Almost for the last two years the original library was replace with the ARM standard for ALL ARM products CMSIS. Using this library you can compile your program in any ARM controller only changing few headers. Its a big improvement over other processors, it´s easy of implement and have standard librarys for all the devices inside the controller. You need to remember that M3 it´s a microcontroller, not a microprocessor and it´s optimized for this task.
I really did not like use of pointer indirection for everything.

Why??? It´s the key for power on several languages and it´s the must for efficient class implementation. Pointer indirection it´s fast, optimist and the compiler do the stuff for you to produce great and compact code.

At this point, use the microcontroller that you like and fill comfortable, program in the language that you prefer and without doubt you can finish in less time than if you use a new fancy controller that not like to you. I move everything to ARM because exist a lot of devices that are compatible and I can select the best price performance ratio.

Re: openHiFi - high grade home music player

Reply #86
I love pointers, but I don't like CMSIS. The intermediate structured fields make it very hard at times to just read code and know what registers are being changed. Which in turn makes understanding the chip on the datasheet harder. Nor is creating structures to simply set registers efficient. CMSIS is indeed designed for portability. All major vendors offer libraries for it but I find it clunky to use compared with programming directly in ARM, AVR, MSP430, etc.

The idea that CMSIS makes it trivial to port core across any micro (even any CM3) is absurd though. Every chip has different peripheral limitations. Even if they both have SPI ports one chip can run them at 25 MHz another at 50 MHz, if your code needed the later a port isn't just changing a header (of course you might not select such a chip, but there are other clock tree nuances that can be different between chips etc). Portability without an OS is very hard on the hardware level. Embedded coding for me is about squeezing the most out of a given chip, which is quite fun but typically require very hardware specific code.

I would rather not debate ARM, my coding preferences or my chip selection in this thread at length though. OpenHiFi is on LM3S9xxx currently based on my Procyon dev board. It uses the very powerful StellarisWare libraries to make the code clean and easy to learn. I have done most of the code cleanup and it will be published soon, in a very early alpha form.

Re: openHiFi - high grade home music player

Reply #87
As promised, I have published cleaned up source files for openHiFi:

It takes "ls" and "p <filepath>" as commands only at this time and only plays 16-bit 44.1 KHz audio files to I2S at with a 256x MCLK from the internal PLL.

Also I have published the pretty minor port of ffmpeg's FLAC decoder as required by LGPL:

I don't remember changing any code in it actually just getting to compile/run on Cortex M3.

My code is MIT licensed, StellarisWare has the Ti no-GPL license, ffmpeg is linked to has LGPL, and Chan's software is MIT-like licensed.