Corrupted decoded audio data on dsPIC33FJ128GP802

[mdanh2002]

Hi,

I successfully compiled your code on the dsPIC33FJ128GP802. By using snippets from the file mp3lib_test_package/main.c, I was able to get the code to successfully parse my MP3 files. The file header with MPEG layer and sampling rate information can be read properly and returns the correct value. By using the state machine functions to play a test file, the mp3_sm_output function is called correctly for the entire duration of the file, and duration_us also contains the correct value. Although the number of PCM samples returned is correct, the decoded PCM data is corrupted and can't be played back normally.

I sent the resulting PCM data via UART to my PC and noticed the following:

1. If the original MP3 file contains only silence (generated using Goldwave silence function), the decoded PCM data will also contain only zeroes (and therefore silence). This indicates that the MP3 decoder functions must be at least partially working.
2. However, for a normal MP3 file with audio, the decoded PCM data is corrupted. It contains silence (all zeroes) every few milliseconds, although some audio patterns resembling the original MP3 audio data can be discerned. On my sample file, for example, I can tell that the waveform for first few milliseconds of the decoded PCM data resembles that of the original data, and that there is an audio volume shift (change in amplitude) in the middle of the file. Other than that, the decoded audio is corrupted and unusable.

You can download sample data for point (2) here https://drive.google.com/file/d/14Qj36CQhfFA8uOvArntFRi0b4ux0iNQZ/view?usp=sharing
with the original MP3 file, decoded WAV file on my PC, and the decoded PCM data from the library.

If it helps, I have little difficulty compiling your code. The only challenge I have is with the mp3__cs and mp3_ca constant declaration in file mpeg_2__3_tbl.cs. The original code declares both constants to be in MP3_SECTION_CA_CS (.mp3_ca_cs), which causes a compiler error saying that the same section cannot appear at both addresses (0xD000 and 0xD012). I fixed it by declaring different names for each constant. The other thing is the "reserved" section declaration in your sample code at address 0x7FFA, which causes my PIC to crash immediately at main(), and has to be commented out. Otherwise, I did not make any change to the code.

One thing I noticed is that for certain files, the function mp3_sm_error is called more frequently compared with other files. On these files, the sum of duration_us in the mp3_header returned in mp3_sm_output will be significantly less than the actual duration of the file. For the MP3 in the above link, mp3_sm_error is never called and the decoding appears to process smoothly, with mp3_sm_finished called at the end. I also verified that the total number of decoded PCM bytes matches the expected value and observed the decode function in mp3_layer3_decode.c works normally and did not return error.

I am decoding in mono (NCHANNELS =1) due to limited memory. I am using MPLAB 8.92 on C30, using large code model, large data model, constants in code space and large scalar model. Tweaking various compiler/linker options yields no differences.

Thanks in advance for any advice.

[mdanh2002]

Update: I fixed the MP3_SECTION_CA_CS issue by using XC16 which apparently does not require two sections to have different addresses. The "reserved" section address declaration also has to be modified to match the PIC data space (16KB for my case as reflected in MPLAB Memory Usage Gauge) . With this, the code no longer crashes at startup with the reserved section declared. I also set MP3_OVERLAP_IN_EDS to 0 in mpeg_2.inc as my PIC does not have EDS memory. The distorted decoding symptoms still persist, however.

[fdev1]

The purpose of the MP3_SECTION_CA_CS is not to allocate separate sections, it is meant to make sure that both arrays are stored in the same section AND WITHIN THE SAME PSV PAGE. The code is optimized to assume that they are, so if they're not you'll be working with the wrong coefficients.

I suspect the issue there is that since you have a smaller address space your compiler can't allocate both tables in the same page, that may be why the c30 compiler fails and xc16 should at least give you a warning. If that's the case you can either get a chip with more code memory or play around with the code models. IIRC the compiler will dump or can be set to dump the address of all variables at compile time. That should help you see how they're getting arranged. Are they at the right addresses 0xD000 and 0xD0012? Compiler output and some code would be helpful.

As for the reserved memory on main.c, to make the most of the DSP engine prefetch we always prefetch the next elements up to the last iteration of loops, that means that if the compiler happens to put any of those buffers at the very end of your address space we'll try to prefetch beyond it and you'll get a trap and crash, so we reserved the last 3 words. 0x7FFA is the address for the last 3 16-bit words on a 32K chip, you need to adjust that for your chip.

Hope that helps.

[mdanh2002]

Hi,

Thanks for the quick reply.

I have checked and all section addresses are within the memory map of the dspic33FJ128GP802 and MPLAB Memory View shows proper data for these constants, even for the largest array MP3_SECTION_RQ which starts at 0x10000 containing 8207 words. I am compiling with the constants in code space option, same as what is shown in your makefile. The reserved array address declaration in main.c has been changed to 0x3FFA to match my PIC (16KB data memory). Otherwise, no other section addresses have been modified.

One thing I found out, xr_temp in union mp3_buffers_t (mpeg_2.h) is never used, at least with the current preprocessor configurations. Your code also has several #if 0 and #if !(XC16) to exclude unused methods. For example, almost every major function in mpeg_2_synth.c is excluded with #if 0, to be replaced with assembler code in mpeg_2_synth_asm.s. I tried removing the assembler code and modify the preprocessors to use the mp3_synth and mp3_dct32 methods inside the C code, and the result is exactly the same - distorted audio. Are these functions equivalent?

I observed that the main decode process begins with mp3_layer3_decode (file mpeg_2__3.c), followed by mp3_synth (mpeg_2_synth_asm.c). Do you think you can briefly summarize how the input data is passed from mp3_bitstream_buffer (file mpeg_2.h) into mp3_synth for decoding into PCM? Using your mp3_synth() C function as a reference, I only see it performing DCT32 on the SB samples, and then storing the output in mp3_filterbank. But then mp3_filterbank is only used in mp3_synth_mute() function (set all to zero) and not anywhere else. There is no reference to the input data from the MP3 file.

Thanks a lot for your help.