Electronics > Projects, Designs, and Technical Stuff
Anyone know of a low cost hardware MP3 decoder??
coppice:
--- Quote from: amyk on May 09, 2020, 03:04:41 am ---You don't even need a 32-bit MCU, the countless cheap Chinese players around at the height of the MP3/"MP4" era were based around a Z80 or 8051 and a bit of hardware assistance (multiplier/MAC).
--- End quote ---
Those players had an 8051 controlling the user interface, and a single chip MP3 decoder. The 8051 was not involved in the decoding at all.
boz:
WT2003S used to be a good bet but the supply seems to have dried up :-(
I bought qty 10 for $3 a few years back for a car audio project and they were dead easy to work with, 16 pin SOIC, can interface to SD card and USB and requires only a few external caps and resistors and a micro on the serial port to control it. Sparkfun have the english datasheets and built some projects with them and lots of other projects on the interweb
VS1053 would be my port of call today, bit more complex but lots of info out there.
nali:
Thanks all, the answers in this thread have thrown up a few things to think about (which was the point of the post really), probably the most interesting is using a STM32 as it could do other things as a slave MCU.
Just to clarify, I was kind of hoping to find a bolt-on single chip device for a few cents that I could just stream some data to.. this is the tail end of an ongoing design which is using a Nordic nRF52832 BLE MCU.
@Siwastaja - I was originally using a 12bit DAC which worked OK, but I wasn't too happy with the audio, as the tail end of some sibilants was sounding a bit raspy, so I changed to 16bit. I suppose using a 2nd MCU I'd have plenty of GPIO to play with so could easily implement a R-2R DAC.
Siwastaja:
--- Quote from: nali on May 10, 2020, 09:03:04 am ---Thanks all, the answers in this thread have thrown up a few things to think about (which was the point of the post really), probably the most interesting is using a STM32 as it could do other things as a slave MCU.
--- End quote ---
No no, not "slave MCU"; there are legitimate cases for a multi-mcu system, but I'm 99% sure this isn't one of them. Just do everything with one MCU/CPU, get rid of moving all that data around!
--- Quote ---this is the tail end of an ongoing design which is using a Nordic nRF52832 BLE MCU.
--- End quote ---
"built around an Arm® Cortex™-M4 CPU with floating point unit running at 64 MHz"
While I can't guarantee this 100%, I think it should be able to software decode just fine. Have you tried?
Is there an option to upgrade to a more capable Nordic MCU, compatible with the existing code with minor changes?
https://www.helixcommunity.org/projects/datatype/Mp3dec is one option (just googled it), the performance numbers look like it should be able to do it. RAM seems a bit tight resource with this particular implementation, though.
--- Quote ---@Siwastaja - I was originally using a 12bit DAC which worked OK, but I wasn't too happy with the audio, as the tail end of some sibilants was sounding a bit raspy, so I changed to 16bit. I suppose using a 2nd MCU I'd have plenty of GPIO to play with so could easily implement a R-2R DAC.
--- End quote ---
No, R2R DAC is definitely much worse than an MCU-integrated 12-bit DAC. If the integrated 12-bitter isn't enough, use a proper audio DAC.
12-bit audio has been succesfully used in recording and distribution, a classic C cassette is around equivalent 6-7 bits and just fine for speech, just a bit noisy.
I'm 99% sure the raspiness of the sibilants was caused by something else than lack of bits.
Did you have any filtration after the DAC? They can settle quite quickly, causing steps. A basic RC could do wonders.
Unless the purpose of the speech is to be listened using audiophile gear, in well sound-insulated room, or high-quality headphones, for delivering "ear orgasms" of sorts, I bet an integrated 12-bit DAC is enough once you figure out what's degrading the result.
nali:
--- Quote from: Siwastaja on May 10, 2020, 09:16:12 am ---No, R2R DAC is definitely much worse than an MCU-integrated 12-bit DAC. If the integrated 12-bitter isn't enough, use a proper audio DAC.
12-bit audio has been succesfully used in recording and distribution, a classic C cassette is around equivalent 6-7 bits and just fine for speech, just a bit noisy.
I'm 99% sure the raspiness of the sibilants was caused by something else than lack of bits.
Did you have any filtration after the DAC? They can settle quite quickly, causing steps. A basic RC could do wonders.
Unless the purpose of the speech is to be listened using audiophile gear, in well sound-insulated room, or high-quality headphones, for delivering "ear orgasms" of sorts, I bet an integrated 12-bit DAC is enough once you figure out what's degrading the result.
--- End quote ---
Yea you're probably right regarding the bits (my gut feeling agrees with you), I'll bear it in mind when I get to doing the audio. I can't recall if I had any filtering when I originally tried the audio, maybe just a simple RC. But as the audio data is 16 bit anyway I just decided to use a 16bit DAC.
Out of interest, why is R2R so bad? I've no experience of them other than at college which was <ahem> years ago...
The end application isn't audiophool, it's an aid for blind or visually impaired. So although I don't need HiFi I do need to maintain a reasonable clarity of audio.
Edit: I'm not sure if the nRF will have the horsepower to decode audio as it's also running the BLE SoftDevice, also they don't have a huge amount of RAM to play with.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version