AVR 16bit Stereo Wave Player

Introduction

This project aims to implement a cost-effective wave player based on AVR (ATmega / ATiny Series) with CD-Audio Quality, which can play 8-bit/16-bit Mono/Stereo standard RIFF (Resource Interchange File Format) wave files.  This project can be applied into many applications such as bus / subway auto-annoucing system, elevator voice indication system.
Current solutions to these kinds of “announcing system” are limited by the OTP (One-Time Programmable) voice chip with small capacity (normally use EPROM as storage media), not to mention the relatively expensive price (the price of OTP voice IC is determined by it’s capacity – voice recording time, normally 10s~200s). For instance, the OTP chip AP89010 (manufactured by APlus) is $0.48 (10 seconds OTP), and AP89341 is $2.43 (150 seconds OTP), and one announcing system may use multiple voice chips (2-10pcs) which also results in the complexity of hardware design. On the contrary, the price of standard SD card is going cheaper with the rapid development of storage technology, 512MB SD card (Kingston) only needs $3.65. Compared to OTP chip, 512MB storage can hold as many as 128 songs with MP3 format, can contain 10 lossless songs (WAV format), and the key point it that SD card can be easily formatted, songs or recorded files can be modified at will – as long as you have a PC supports FAT filesystem.
As mentioned above, the announcing system using OTP chip solution has a complicate circuit – different audio announcements need to be played from different chips, the control logic is quite a burden which definitely increase the circuit complexity including the PCB area. Quite the opposite, our system only need 6 main wires (SPI bus: 4 wires, PWM output channel: 2 wires) to play the songs or any recorded wave files. AVR chip can be purchased as cheap as $4 (ATmega328). So the whole system can be very cost-effective.AVR 16bit Stereo Wave Player

High Level Design

Project Idea

There are many MCU-Based MP3 player, however, these kinds of MP3 player solution not only needs extra hardware decoder, but also needs DAC chip, and the circuit is complicate. How to design a chip music player while reserve the audio quality? To substitute the MP3 decoder, we can simply use WAVE file which format is simpler than MP3, and it can be easily decoded by MCU. To substitute the DAC chip, PWM can be used to replace it with simple R-C filter, such as the Cricket Call Generator. Based on this kind of idea, WAVE player based on AVR wais born.

Background Knowledge

Since SD card is used as the storage media, except SDIO, the only way to commuinicate with it is SPI. Generally, SPI has four working modes.

To operate SD card using SPI, the working mode must be specified. In “SD Specifications Part 1 Physical Layer Simplified Specification“, Section 7.2 mentions part of the SPI protocol, but doesn’t specify any details. After several experiments, the suitable SPI working modes for SD card communication is MODE0 and MODE1.
Meanwhile, instead of reading RAW data from SD card, FAT16/32 file system is implented, so that WAVE files can be easily stored into SD card via any PC with SD card reader socket. The FAT file system is open source “Petit FatFs” which is a simpler version of popular “FatFs” developed by ChaN.

With knowledges above, I still needs to get familiar with the format of WAVE file which is actually a subset of “RIFF” format developed by Microsoft. RIFF audio format will be introduced in detail in software section.

Logical Structure

At a high level, the logic structure is much simpler. It contains “Storage Module” and “PWM-DAC Module. With embedded hardware SPI interface and PetitFatFs module, WAVE files stored in SD card can be retrieved. Then ATmega1284 will parse the WAVE file and get the pure audio data which is used as the PWM output (4 channels). Four 8bit PWMs are divided into two groups (corresponding to audio left channel and right channel), and combined separately to two 16bit “PWM-DAC” outputs. These two output channels are finally connected to the loudspeaker.

User Experience (UE), Hardware (HW) and Software (SW) Trade-offs

There always exists trade-offs in UE, HW and SW. This project actually shows how to appropriately handle these trade-offs appropriately.

UE and SW

There exists two methods to retrieve audio data from SD card. We can write RAW audio data into SD card with many 3rd-party software tools. In this way, the software design is pretty easy: all MCU needs to do is just read audio data via SPI interface, and forward the audio data stream to PWM channels. However, it will be very annoying to replace audio data in SD card.
The other method is to use standard file system so that SD card can be operated normally in any PC with FAT support. With this method, it is very convenient to replace / update audio files, the difficulty is that a lightweight File System must be implemented so that MCU is able to retrieve data via standard FAT16/32.

HW and SW

MP3 is a popular audio format with smaller file size and good audio quality. If we use MP3 files as the audio source, then a hardware decoder must be implemented. ATmega1284 or any other low-cost 8-bit MCU is not able to guarantee the playback quality since it needs to parse the complicate compressed MP3 file. On the contrary, the format of WAVE file is easier: it is composed by a simple file header followed by RAW audio data which can be directly output to PWM channels (16-bit audio data needs simple subtraction operation).
Another advantage to use WAVE file is that it is lossless! As long as we can guarantee the playback quality (output audio data in exactly the same frequency as sample rate), theoretically speaking, we can achieve very high audio quality. Even though WAVE file is much bigger than MP3 file, but it would not be a problem: SD card is so cheap these days.

Standards

  • SD Specifications Part 1 Physical Layer Simplified Specification (version 4.10);
  • Microsoft Extensible Firmware Initiative FAT32 File System Specification (version 1.03);
  • Microsoft New Multimedia Data Types and Data Techniques (version 3.0);
  • ANSI-C Specification (ISO / IEC 9899).
  • GCC Manual (version 4.9.2)

Relevant Copyrights

Petit FatFs system is a lightweight Fat File System which supports FAT12/16/32, and it is developed by ChaN. Petit FatFs is specially designed for those MCUs with low RAM capacity.

Hardware Test

The key point of hardware test is the accuracy of 16-bit Combination composed of high-precision resistors. It is pretty difficult to measure its functionality. High-Precision Muti-Meter is required to achieve rigorous validation. To logically verify this test, a test firmware is created to evaluate the hardware. This test firmware will generate PWM in Fast PWM mode, and the PWM value is incremented every 200ms. With Proteus (version 8.1 sp1) and the schematic mentioned in “Hardware: PWM Combination“, the oscilloscope outputs is shown below. Note that, the horizontal scale is adjusted until the “Climbing Steps” can be clearly observed.

From the waveform we can see that 16-bit PWM output has nearly invisible “steps” compared to 8-bit PWM output. However, software simulation is still not a good way for evaluation and it does need improvement.

Software Test

It is also a big problem to test the audio quality since it is very subjective. What’s more, human ear is not as accurate as machine. There actually exists two ways to evaluate audio quality, even though it is not so professional. One way is to record the audio data output (via LINE-IN audio port) and save the audio data to the same wave format as the original wave files. Then, use “Adobe Audition” to compare these two audio files. The other way is to capture the play time and compare it with original wave file.

Software Test: Sample Rate

For each wave file format, choose a different song with same sample rate (44100Hz) to implement this simple test. A simple VC program is created to capture the song start information (a simple “play!” string) output from hardware USART interface. Once the string is captured, a TIMER is started to record elapsing time until the end information (“over!” string) is captured. The result is shown below.

16-bit TIMER1 is used as the sampling TIMER, and the value for output compare register is (16000000/44100 + 0.5 – 1 = 362), “0.5” is an important way to guarantee the precision. Even though, the sample frequency in this way is 44077.135 Hz. That’s why the deviation exists.

From the result we can also see that, as the bytes per sample increase, the deviation value becomes smaller. It is because the audio data is consumed faster with 16-bit stereo audio format. We can imagine that if the sample rate of the wave file goes a bit higher, then it is very possible that current system cannot play it normally because of the limitation of SPI speed (8MHz), and CPU overclock may be essential if we want higher audio quality.

Software Test: Audio Quality Analysis

It is difficult to compare two audio files intuitively even with Adobe Audition. However, we can merge the recorded wave file with original wave file to test Mono Wave Files. For instance, with Adobe Audition, we can put original wave file to left channel and copy the recorded wave file to right channel, then Adobe Audition is able to analyze it.

For 8-bit Stereo wave files, we actually need to extract audio data from each channel and repeat the procedure mentioned above. On the other side, for 16-bit Stereo wave files, we can simply use the high-order byte as the data source for analysis. It is safe because Adobe Audition only accumulate the audio samples at different frequency points, it is not relevant with the amplitude. In this project, I just focused on 16-bit Stereo analysis. However, I was not able to analyze all four kinds of wave files due to time limitation. But this test method can help to do cross-analysis to get more information.

The FFT diagram generated by Adobe Audition is shown below. All the data of FFT analysis can be exported for further analysis.

Then the analysis result is forwarded into excel to calculate the deviation. Part of the result is shown below. From the FFT waveform we can still see some noise which causes the deviation with original data. However, if a good low-pass filter was implemented, the result should be better. Even though, the average deviation is 0.46% which proves that the audio quality is still good.

Safety

This design does not currently have electrical components that are in direct skin contact, nor do we expect high current draw beyond a few microamps. On the contrary, further implementation will add ESD protection circuit to avoid circuit damage caused by electrostatics on human body.

Usability

This system is pretty easy to operate with two simple keys. A further implementation will embedd a display module into the system to improve user experience.

Conclusions

Accomplishments and Further Extensions

The expected design and results for the core functionality went smoothly as planned. The system is reliable and able to process standard wave files with CD Audio Quality (Sample Rate <= 44100Hz). Even though it has no hardware filter, the audio quality is still good even with normal headset.

As mentioned in sections above, for further extensions, following ideas should be worthable to carry out.

  1. UE (User Experience) Enhancements
    A display module together with a simple low-pass filter will be implemented to enhance operability and user experience. Considerring the size of the circuit, a small OLED module maybe used to display essential play information.
  2. Audio Quality Enhancements
    To increase audio quality, a standard 11.2896MHz OSC may be replaced to guarantee the accuracy of sample rate. Also, a well-designed low-pass filter can also help to improve audio quality.
  3. Test Improvements
    As mentioned in Test section, cross-analysis for different wave files is very useful for further research. Meanwhile, use high-precision digital voltage multimeter (FLUKE 8846A) can also stronglly prove the practicability of the PWM combination circuit to substitute 16-bit DAC.

Intellectual Property Considerations

Except the open-source Petit-FatFs developed by ChaN, the rest code is my own.

Ethical Considerations

There are no known ethical considerations regarding the design of this project.

Legal Considerations

There are no known legal considerations regarding the design of this project since it is not implemented for commercial purpose. If this project was to be re-purposed for commercial purpose, then it should still be OK since the author of Petit-FatFs authorizes free usage (See Appendix).


About The Author

Ibrar Ayyub

I am an experienced technical writer with a Master's degree in computer science from BZU Multan University. I have written for various industries, mainly home automation and engineering. My writing style is clear and simple, and I am skilled in using infographics and diagrams. I am a great researcher and am able to present information in a well-organized and logical manner.

Follow Us:
LinkedinTwitter
Scroll to Top