Teensy 4.0 and mp3 and FrankB's audio library

W

WA2MZG

Member
I am using the Teensy 4.0 with the audio shield and FrankBs Arduino-Teensy-Codec-lib.
I successfully compiled and ran the example program Mp3FilePlayer.
It plays the sample mp3 files from the library and mp3 files I download, but it will not play mp3 files I create from my CDs.
I am using NCH Software, Switch Plus to convert my CD's to mp3s.
I can play the files created with this program in my car stereo and with my iPad.
Where should I look or what needs to be adjusted?
Thank You
 
Make sure the sample rate of the ripped mp3 files is at 44100 rate. I ran into this when converting wav files to mp3 files. I am not sure if @FrankB's library supports the 480000 sample rate. Other members might have more input here.
 
Thank You for the quick reply.
I believe I have set the sample rate to 44100 and the bit rate to 192k.
Still no success.
It appears that I get this error from the software "ERR_MP3_FREE_BITRATE_SYNC"
It comes from the file "mp2dec.h"
What conversion software are you using?
Thank You
 
Hi,
according to 'mp3dec.cpp' this error occurs when the bitrate in a frame header is set to zero - which means a free bitrate.
Maybe you can check your bitrates by parsing the headers.
I have done that to calculate the full playing time since the bitrate can change from frame to frame.
I always buy my mp3 ... so I have no hint for a nice converter :(
 
Thank you for all your suggestions
I took the easy way out and downloaded another file conversion program, VLC media player.
First try - it worked - so now I can begin converting all my WMAs to MP3s - again.
Both my CD players have "passed on" so I am attempting to build an MP3 player for all my CD's

Again - THANK YOU for your suggestions.
 
Everything seems to be coming together nicely now that I have a better WMA to MP3 conversion program.

Follow up questions
1 - rarely, a song will seem to "studder" for a few seconds
2 - changing the volume has an issue - using sgtl5000_1.volume() - increasing the volume works very smoothly but decreasing the volume mutes the audio for about 1 second - maybe a little longer - the program seems to pause for that duration.
3 - playMp31.lengthMillis() returns the value of .positionMillis() - not the length.

Any ideas to share?
Thank You
 
1. I had similar issues with a SD card which listed same speed but was cheaper ... I exchanged against an expensive one from SanDisk.
That made the difference ... I think the access time is a major issue not the speed itself.
2. I can not remember that I observed that ...
3. Yes .. some issues there ... see my post https://forum.pjrc.com/index.php?threads/frankbs-arduino-teensy-codec-lib-playing-mp3.73819/

Good luck ... my MP3 player is working fine ... currently working on implementing access via MTP ... next will be FTP via network ... :D
 
Thanks for the quick responses
1 - I will try a new SD card
3 - I have too many albums / songs to create and maintain a table - so I will forgo that feature
2 - I was just writing an explanation of the slider code and found a bug!!! I forgot to add an "else" in the code.
Thank You Again for your help
Forest
 
The table just lists the total song time ... if you dont need it ... it is ok for you. I just want to show it like in other MP3 players.
It will be created automatically ... once you copy a new songs to your SD card and it is not within the table this will be detected once running through the setup() and it will be added the first time you want to play it.
It will parse the single frames then before starting the song and add that new entry to the table only this single time ... it is a delay of max. 2s or similar only before starting to play the song.
This way sliding forward and backward should also be easily within a song during playing it ... maybe I will add that later.

Btw. : On both my cards is written up to 100MB/s but the one from Kingston is 32GB V1 ... the working one is SanDisk 32GB V3
 
Last edited:
When you are trying new cards, note that cards that are equal to or more than 64GB use the ExFat file system, compared to the traditional FAT32 filesystem (with VFAT overlaid). Perhaps, ExFat cards are read faster than FAT32. Perhaps not. If you can, you might want to try both a 32GB card and 64GB card.
 
The mp3 player is working very nicely - thanks to all your ideas.

I do have a new problem - There is a very low / short ticking sound.
It is on both the headphone and line out.
On "high" volume songs - it is extremely hard to hear the tick.
On soft songs it is obvious.
The ticking is so soft - it may be at regular intervals but it is hard to determine.

My guess is it comes from reading the SD card.
I have tried 2 different uSD cards - the best one is a SanDisk Extreme PRO, 128GB, V30, U3, A2.

You may recall that in an earlier post I indicated that the songs seem to "studder" and changing to a better / faster SD card solved that.
Everything sounds very good in my headphones, on my stereo or even my desktop speakers.
This morning, I just happened to select a soft guitar solo and I thought I was listening to the clicking on a scratched vinyl record.

Well - any thoughts - as always - are appreciated.

Thank You
Forest
 
I think I saw h4n0nnym0u5e in another thread talk about their/her/his media player starting to copy the SD file into memory, and play the file from there. I could be wrong about it.
 
Whoops, that sent before I was ready…

I did find on the Audio Guestbook thread that the current pulses from SD write were getting into the recorded audio. It went away if the SD card was in the Teensy 4.1 on-board slot, and could be reduced (in my experience, not everyone’s) by improving the power connections to the card. Detail at https://forum.pjrc.com/index.php?threads/teensy-4-0-based-audio-guestbook.70553/post-325182

I’d think that SD reads would be lower current and thus less prone to this effect, but maybe not.
 
When you are trying new cards, note that cards that are equal to or more than 64GB use the ExFat file system, compared to the traditional FAT32 filesystem (with VFAT overlaid). Perhaps, ExFat cards are read faster than FAT32. Perhaps not. If you can, you might want to try both a 32GB card and 64GB card.
Click to expand...
I recently found that a new 16GB card had come formatted FAT32 and I'd declared it on the T4.1 as exFAT. It wasn't recognized by the T4.1 until I initiallized it as exFAT on my Mac. It is probably still inherently slower (UHS 1 vs UHS 3) but I think the SD command to read an entire file into memory at once is exFAT specific.
 
@WA2MZG - At one point I was having the same problem when I was adding the use of USB host drives. I started experimenting with different buffer sizes in the mp3 player code:
Code: 
#define MP3_SD_BUF_SIZE    2048
This is found in FrankB's "Arduino-Teensy-Codec-lib/play_sd_mp3.cpp" file at about line #46. I changed it from 2048 to 4096 and that helped with most but not all storage devices including SD cards. So as an experiment you might try changing it to multiples of 2048 and see if it makes a difference.
 
‘It’s always the last place you look!”

I improved the power filtering, grounding, different SD cards, changed the buffer size to 4096 and 8192.
No improvement.
I removed the last software feature I added - displaying the run time of the song - FIXED!

My first thought was that because I was reading the run time from a library routine (Frank B’s ……) - that was the problem - but NO.
I replaced the time with a simple counter and the problem still existed.
Turns out, it is simply writing to the display while a song is playing.
Up to the point of adding the run time, I only wrote to the display when a song was not playing.

Thanks for all your ideas.
Without working through your ideas I would not have come to the conclusion that it was “software” (sorta).

Forest
 
I located the “software” issue.
See the time in the lower left of the picture.
I was blanking the old time by filling a square with the background color (black) and then writing the new time.

tft.fillRect(0, 420, 250, 22, ILI9488_BLACK);

Now I write the old time in black, over the displayed time that is in white.
Then write the new time in white and magically the clicking is gone.

Note: the red bar is a volume slider.

Forest
IMG_1635.jpeg
 
Ah ... yes .. that is what I observed as well ...
And I solved it the same way like you ... minimizing the pixels I have to repaint.
I dont know what exactely is the reason ... I assume somehow the display functionality steals too much time to get the music playing fluently.
I am astonished because I thought the audio interrupt is running on a higher priority and will interrupt a lower one like the display ...
So .. maybe a different point is the reason ... I dont know ...
 
You must log in or register to reply here.
Back
Top