[Michael P. Flaga]

just to let you know I have updated my github fork with the above mentioned code “SendSingleMIDInote()”. The examples now have a ‘b’ command that will send the beep and if a stream is playing it will pause that beep and inject the beep and then resume the stream.

P.S. I beta release versions on my personal fork of https://github.com/mpflaga/Sparkfun-MP3-Player-Shield-Arduino-Library and after a period of due diligence I push to Bill’s original repo.

[Michael P. Flaga]

I will need to look into updating the examples compatibility. I see that https://github.com/lp0/arduino/tree/master/libraries/Bounce appears to be the same as the one used. Try that one.

[Michael P. Flaga]

As the original SFE shield does not have an audio input this library does not yet have this feature. However, Miguel Moreto’s fork https://github.com/miguelmoreto/Sparkfun-MP3-Player-Shield-Arduino-Library added a feature for recording OGG. Also you can use AdaFruit’s library which as a such. Until we integrate recording into this library’s root fork.

[Michael P. Flaga]

I believe the problem code that needs editing are in the vs_init() there are some Mp3ReadRegister() that check the initial status of the Vdsp. Which can be commented out. Additionally I see the flush_cancel() also reads. This is called at a STOP or End of File. comment it out in the refill(). However, you can then only play the same type of files. As it won’t start new file type hunting.(but likely not an issue)

Where the rest of the Mp3ReadRegister are in functions that can simply not be called. This will be most all of the GET… and SET… along with the RESUME and SKIP functions.

Where playing or simply sending a stream as you earlier observe will work disregarding the MISO.

Alternately, one chip select to both 74HC595 and 74hc164 will provide you some INPUT and OUTPUT. a good cost ratio of one pin for 2*8

Also there are GPIO on the VS1053. I have not added calls to these. And would be simple enough to add. I saw AdaFruit’s recent VS1053 library have such for there breakout.

[Michael P. Flaga]

The short answer is – Do not use PIN12. (unless it is your last resort.)

The SPI’s Tx and Rx and Clock pins are dedicated together as a resource. (MISO must be an input) Unless you have a custom wired breakout or shield the MISO is hardwired from the Vdsp to the AVR.

While what you say is possible with a few cuts and jumps and edit to this library. This library does support other commands to the Vdsp that are equally receiving and would need to be omitted.

I highly recommend using another GPIO. Please note that A0-A5 are also available as GPIO.

[Michael P. Flaga]

Yes,  See example FilePlayer.ino Which supports the following feature in addition to the original

… A list of index’s and corresponding files in the root can be listed out using the ‘l’ (little L) command. This sketch allows the various file formats to be played: mp3, aac, wma, wav, fla & mid.

Take note the actual command to play the file is

MP3player.playMP3(filename);

Where you can assign filename to any valid 8.3 path/filename. So from that point there is no limit as to the number of files this library can play.

• This reply was modified 11 years, 9 months ago by Michael P. Flaga. Reason: removed garbage hypertext

[Michael P. Flaga]

hmm.

Does not sound good, as the DREQ is sourced from the VS1053. I suspect voltmeter indicates it is always low.

What is the measured state of the:

MP3_RESET

3.3V and 1.8V

Is the crystal at 12.288MgHz

Inspect all the solder joints. You may want to reflow them with an iron, one by one.

If you comment out the

if(result != 0) {…

That is stopping the code from continuing, can you “d” out the directory. Sounds like the SdCard is working.

Perhaps comment out the sd.initErrorHalt(); and remove the SdCard and then see if the VS1053 then starts talking.

Check to make sure that one of the VS1053 GPIO’s is not causing it to be in master mode.

Does the MP3_Shield_RealtimeMIDI.ino example work on it? Note this sketch can be configured by default not to use the SPI interface that is being blocked by the lack of DREQ. Rather it can use a SoftSerial port to send MIDI notes. and should sound like a sequence of notes starting of very low. if GPIO0 is high it will be in the wrong mode of master. If GPIO1 is high it will be in RT-MIDI mode.

The later GPIO1 is on D4 so it can not be initially used. The above MIDI sketch uses it appropriately.

If these fail. I am not sure expect to try another shield.

[Michael P. Flaga]

Not the most recent version I just posted on to My GitHub has improvement to the Interrupt handler.

Where you can not use the same INTx pin for the DREQ of the VS10xx chip and your other task. However you should be able to use another INTy without problem. I have successfully done so. Assuming the INTy service routine is not blocking for too long, before releasing the Interrupt mask.

Additionally, re-sampling the audio file to lower Bit rates significantly reduce the overhead or increasing the idle time. As stated in documentation Performance Section.

[Michael P. Flaga]

change the

#define USE_MP3_REFILL_MEANS USE_MP3_INTx

to

#define USE_MP3_REFILL_MEANS USE_MP3_Polled

in SFEMP3ShieldConfig.h

as per the instructions

Did you get the VS1063 going?

I was interested in adding this to the library. Got a chip and just never replaced the one my Shield.

 

• This reply was modified 11 years, 9 months ago by Michael P. Flaga.
• This reply was modified 11 years, 9 months ago by Michael P. Flaga.

[Michael P. Flaga]

The ET library is Asynchronous, In other words it only sends data when it needs to. Hence your sending application will need to generate periodic heartbeats and your receiver will need to expect them. Where if it misses too many of them then it will need to perform a graceful shutdown.

On the receiver this similar to the Arduino Debounce example http://arduino.cc/en/Tutorial/Debounce. Same concept of timing and function. Actually more like a WatchDog, in that it expects a serial receive message to update the timeout before it times out.

[Michael P. Flaga]

The library has functionality when the file is ended or stopped it will flush the VS1053 buffers and update the state. There is manual flush function that can be called with options in the various ways of flushing before or after the STOP is issued.

Are you saying that occasionally the file will end but the state still indicates playing.

FYI.

Note that every byte has to be read from the SdCard and then written back to the VS1053, at 4M bits per sec. Hence 2M and then it needs overhead. So max is theoretically 200KB per second. but there is a lot of overhead.

Also the file public position pointer in the SdFatLib is only 16bit. So it works only as relative. Along with its cache buffer being only 500 Bytes. So if any other file access is attempted its dumped and re-read. and will likely cause a mess.

I believe I recall I changed the currentPosition to read the second position from the VS1053 rather than the file position, because of the prior limits and Variable Bit Rate can mess with it. The thing to note here is that the currentPosition is suspending and reading the VS1053 and resuming. Which works fine until real time become limited. Just FYI.

I believe I recall having such problems at these Bit Rates, and simply re-sample.

[Michael P. Flaga]

two items;

1. I am concerned that evey 192K bit rate may be too high. I have all my quite slower. I know I did limited testing and think I recall problems at 192K and over. Can you re-sample the file to a slower bit rate. I use SOX it is a command line that is easily made into a script.
2. Not sure if your DisplayTrackName is actually attempting to read the track file. If so the SdFatLib may have problems with bouncing back and forth positions in the current file.

I have no idea what your statement about the sticky plaster and lock up working is about.

[Michael P. Flaga]

Its been a while. Whereas using the demo code I have been able to play track’s that are over 45 minutes long without issue.

My first guess; which is similar symptoms, is that the bit rate of the track is too fast. Where the ATmega is not able to keep up with reading the SdCard and then sending it to the VS1053.

Is indeterminate? a few seconds, minutes or 10’s of minutes?

[Michael P. Flaga]

I have unfortunately the past few months been swamped with my day job. I never quite finished the above. Curiously I am not a musician and don’t know much about Midi and such. I got stopped on getting the MIDI file. Note that the VS1053 will read in the stream and auto decode it. So while decoding a MP3 or wav stream from file, One can simply stop the current file position and then optionally flush the current VS1053 buffer as to stop immediately. And then send it any other stream. My idea is that MIDI files of a single note for the bell instrument will be short. and go into the VS1053 buffer. It a single not would be short enough that it can be stored as an array in flash with only few dozen bytes. This relieves the need of opening another SdFile or changing the file pointer, etc….

So just need a MIDI type 0(zero) file of a single key board beep or alike. Use the Pause command with the flush Pre or Post (which ever is quicker) send the MIDI array and then resume the file. The VS1053 buffer will simply queue up the stream and play what it decodes.

[Michael P. Flaga]

Bit Rate has been problematic, where it was working on the last release of my MP3 example files. getBitRateFromMP3File attempts to read the file for the CBR or constant bit rate. Note actual bitrate may get updated later by getAudioInfo(). As the file may be using Variable Bit Rate and not constant.

The skip(milliseconds) function advances the file position by the mulitple of the actual read back byte rate, not the CBR initially read from the file:

if(!track.seekCur((uint32_t(timecode/1000 * Mp3ReadWRAM(para_byteRate))))) // skip next X ms.

[Author]

Posts