[Michael P. Flaga]

FYI –

During my QA of the changes related to this I found the resumeDataStream() function was broken. The current release of 1.02.00 has this fixed. By simply swapping the order of enableRefill(); and playing_state = playback; as with the others previously mentioned.

Have fun.

[Michael P. Flaga]

No need. I have pushed the changes into the work-in-progress release of 1.0.1 on my github. Let me know if there are issues. I will need to QA it a little more. But expect it will be fine.

I plan on merging the latest SdFatLib in to and then releasing it on the main github.

Thanks for the feed back and assistance.

[Michael P. Flaga]

Very well thought out and investigated.

Not sure why your interrupts are firing like you stated. but none the less it draws out an issue. Where the added playing_state is reasonable.

I would suggest try moving the check into the void SFEMP3Shield::enableRefill() itself.

void SFEMP3Shield::enableRefill() {
 if(playing_state == playback) {
 #if defined(USE_MP3_REFILL_MEANS) && USE_MP3_REFILL_MEANS == USE_MP3_Timer1
 Timer1.attachInterrupt( refill );
 #elif defined(USE_MP3_REFILL_MEANS) && USE_MP3_REFILL_MEANS == USE_MP3_SimpleTimer
 timer.enable(timerId_mp3);
 #elif !defined(USE_MP3_REFILL_MEANS) || USE_MP3_REFILL_MEANS == USE_MP3_INTx
 attachInterrupt(MP3_DREQINT, refill, RISING);
 #endif
 }
}

This may be more comprehensive, as there are other locations of enableRefill(). Which are typically paired with a preceding refill(). Subsequently  ::skip()’s and “”skipTo()’s ; enableRefill() and playing_state=playback, need to be swapped.

The state-fullness of the playing brings out a whole lot of problems, such as this.

[Michael P. Flaga]

Are you running the MP3 library as INT or polled?

I interpret your above to say spinning the dial works when playing back. But when idle (not playing back) and you spin the dial it locks up. Not sure how that relates to the MP3 and its interrupt.

Is it that you are spinning it (this works as expected) and while it is spinning the track finishes and then it locks up.

Need to add prints to debug where it was last as it locked up.

It sounds like it should be the same as sending from the Serial Monitor “1+++++++++++++++++++”…

Which all get queued up so it plays 1 and then processes the +’s.

The getState and its under the hood resources  was added to help prevent refills from occurring when not playing after each of the commands, such as setVolume. It may be somehow the refill is still being enabled when there is no file open. Or the interrupt of the dial is interrupting the refill or sending of the command to the MP3.

Not sure this is a very specific issue. Not sure if it is the MP3 library at fault.

[Michael P. Flaga]

The problem that I have with suppliers like the “Shifty VU Shield” is that they don’t share their design files, not even the schematic. So you don’t know what you are buying. Where the best I can find is a flicker picture of the blank PCB.

That said I see from it and the example code the only thing needed are the analogread()’s of pin A2 and A3 for the left and right channels. If you invoke any of the other PIN commands or WriteLEDArray(); functions in the example such as will interfere with SFEMP3Shield library.

float adc1avg = 0;
float adc2avg = 0;

 void loop() {

  adc1avg = adc1avg * 0.95 + analogRead(2) * 0.05;
  adc2avg = adc2avg * 0.95 + analogRead(3) * 0.05;

[Michael P. Flaga]

Your above symptoms of all Sd init failures and MP3 0’s indicate something fundamentally is wrong. It could be the chip selects for the two chips depending on the Shields used. I am not clear if you are stating you have altered the SD library or trying to use it. Where SdFat is used.

I recommend starting from a fresh known good position 1.0.2, from Bill’s GITHUB with no changes, as it is known to work out of the box. Following the manuals install guide corresponding to 1.0.2, taking note of the comment to restart the IDE after adding libraries. The IDE caches the list of available at start, so any added after it start will not be recognized.

The trouble shooting guide has support for common causes of failure to connect. Note the problem is before the SPI is connecting to the MP3 shield, as the SD card Init’s are failing, so the problem is not with this driver, but something before it. Removing the fail safes and proceeding are not sufficient, rather the source problem needs to be addressed.

You can/should also try to get SdFatLib’s QuickStart.ino example working. Using chip select 9 assuming your using the SFE’s mp3 shield.

Also I believe you should be using IDE 1.0.0 or higher for current SdFatLib to work properly. 1.0.3 is now out.

[Michael P. Flaga]

jonny  says:

January 19, 2013 at 8:06 am  (Edit)

Hi..
Thank you for your reply…i changed that in native SD library now i am getting in my serialmonitor is
MP3 Testing
Error: Card init
Error: Volume ini
Error: Opening root
SCI_Mode (0×4800) = 0×0
SCI_Status (0×48) = 0×0
VS Version (VS1053 is 4) = 0
SCI_ClockF = 0×0
SCI_ClockF = 0×0
Failed to open track001.mp3
Failed to open track002.mp3
.. same thing repeated up to 100..
Failed to open track100.mp3
Whoa there cowboy!
I am trying with the Sparkfun MP3 samples with name track001.mp3 and track002.mp3
Thanking you in anticipation

[Michael P. Flaga]

The pre-release version  version has getState() to query if paused, etc… It is how pause is now toggled in the example.

enum state_m {
  uninitialized,
  initialized,
  deactivated,
  loading,
  ready, // aka IDLE!
  playback,
  paused_playback,
  testing_memory,
  testing_sinewave,
  }; //enum state_m

if( MP3player.getState() == paused_playback) {
  MP3player.resumeMusic();
  Serial.println(F("Resuming"));
}

I would think the below would accomplish the same goal.

if (MP3player.getState() == paused_playback) volumeChange();

[Michael P. Flaga]

Thanks. definitely an oversight.

I recall I was distracted by the formula in the data sheet as it is not actually straight up freq either.

[Michael P. Flaga]

I believe it is due to the sd.begin() missing the chipselect. Where it will default to something else (non SFE). I have seen such SPI chipselects work at first and then not later. The omission of the test and initiErrorHalt as shown below may be allowing the bad init of the SD card through and some incompleteness having problems later in that object when replayed. Either way I have this very example below working fine, on my UNO-R3/SFE.

Note: the sd.begin() is moved to outside the library on the current per-release version, as to allow the main sketch more direct and simpler access to the files. I have some examples in the works. As a result it is needed. And the setDiffertialOutput() indicates you are using the pre release.

As to the setDiffertialOutput question refer to setDiffertialOutput() and getDiffertialOutput() of the manual. which quotes the datasheet; “Left channel output is the invert of the right channel.” and “For stereo playback streams this creates a virtual sound“. Not to sure what virtual sound is though. This mode is meant to have the + and – of the speaker connected to L and R, omitting GBUFF. And used with a mono stream or setMono if you have a stereo stream. This will double the peak to peak output. But if you leave the wiring as typical with stereo headsets, then there will not be much of a difference. Just L will be inverted. And the common signals such as base may be subtracted from between your ears.

As mentioned in another thread, I expect the volume to be so muted while inside the plush toy that a boost is needed. And setting differential and mono gets the most out of the VS1053 chip. Before needing an audio amp. (FYI looks like i typo’ed the function names and will be correcting that before release.)

Hope this helps.

#include <SPI.h>
#include <SdFat.h>
#include <SdFatUtil.h>
#include <SFEMP3Shield.h>

SdFat sd;
SFEMP3Shield MP3player;

void setup() {
    Serial.begin(115200);
    if(!sd.begin(SD_SEL, SPI_HALF_SPEED))    sd.initErrorHalt();
    uint8_t result = MP3player.begin();
      Serial.print(F("Error    code:    "));
      Serial.println(result);
    MP3player.setDiffertialOutput(1);
    MP3player.setVolume(5, 5);    //-2.5dB
}

void loop() {
  int errorCode = MP3player.playTrack(8);
    Serial.print("error    Code :");
    Serial.println(errorCode);
  delay(5000);
  MP3player.stopTrack();
  delay(1000);
}

[Michael P. Flaga]

I have been out of town.

Yes, the restart from volume became obvious from another thread. A pre-release version has that fixed. This version’s example works. But has some new features and different file handling that I am still evaluating.

Also note there is no need to pause the music as to change the volume. There is a mechanism under the hood to avoid collision for that process.

Yes, I saw the pause was originally intended for quick SPI access. Where as I was not able to get the internal pause of the chip to work. Due to refill(). And this works reasonably. Note that stopTrack actually flushes the VS1053 buffer and pauseDataStream simply pause the refill.

In that pauseDataStream and playMP3 are coupled to the VS1053 buffer, the MP3Play makes an initial fill of the buffer, and the VS1053 will play that regardless. as the pauseDataStream  simply stops filling it. hence your initial blast.

The pre-release version may with its state fullness may handle this better. But may need tweak to the skip for it to work better.

Where your above examples issue is not in the pause but the fact that the playMP3 makes the initial fill of the buffer.

I am not sure why

MP3player.pauseDataStream();
delay(5000);
MP3player.resumeDataStream();

does not do the job in place of your above snippet. where you could set the volume either before or after the pause. And in the pre-release in between.

An overload of resumeDataStream(uint32_t timecode) that does the skip to, may be the solution. Likewise a an overload of the playMP3(char* fileName, uint32_t timecode). Where as I note that uint32_t timecode is somewhat limited as to the maximum time it can skip to).

[Michael P. Flaga]

Yes, the “L”,  “R” and “-“, is the 3 SIP 0.1” connector mentioned.  Where the LR are obviously left and right. And “-” is GBUF, NOT GROUND.

Where the newer software supports the “M” (mono) and “D” (differential) speaker modes and commands. As to get loader. I suspect when you put the speaker inside the plush toy it will need the boost in volume.

Note the above mentioned link of the fork, no longer exists, it has been merged into my github master fork

[Michael P. Flaga]

No lower baud rate will not affect the playback of files. We are not using the software serial here. So the UART is hardware peripheral and the speed won’t affect the CPU.

Yes the Bit Rate can vary somewhat for each experience. SFE’s original demonstration was not interrupt driven and likely used on a 8MgHz PRO versus the UNO’s 16MgHz CPU and this driver is Interrupt based. Using less real time.

The speaker LEFT, RIGHT, GBUF pins  do not route the Arduino Headers. Rather they go to TWO connections; JP3 and U5. Where U5 is the typical 3.5mm stereo jack connector. JP3 is a Single In-Line Pin 0.1″ header, that is convient for soldering a connector to other speakers.

I typically use 115200 as to get a lot of debug, back and forth. Most examples use 9600 as it is very reliable. But I admit I am lazy in publishing, going back and forth. Where 115200 works fine on my UNO R3’s. That said doing the math shows 115200 is close to the 10% allowed error, so there may be some variances, between users and boards. Where I am glad you figured it out and got it working.

[Michael P. Flaga]

You have some great ideas. I would like to see others use the library, to few follow through in posting their projects, they ask for help and then disappear. So I appreciate the call out links. At the moment I am tied up on day job issues. But I won’t be able to resist to look at the links and posts to this forums.

I have on my unofficial todo list, similar ideas. So the ArduRadio and Webduino are good places to put the missing puzzle of sourcing the TCP stream, as the VS1053 should just suck it in and play it out. Once it gets going. I envisioned issues with internet radio websites starting their streams with play lists. Not sure.

Yes, there have been advances in the library, mostly all of them transparent, new functions or bug fixes. With the only exception of how SdFat is handled. Looking at the ArduRadio it may only have an issue with where the SdCard objects are instanced, easy to work around. That said a recent prelease of the SFEMP3Shield library changes the SdCard again to make it more consistent with current technics. (again easy to fix) And in doing so makes the file handles more accessible for doing such listing of files and nextOpen commands, etc… This will help in limiting out the SdCard and its unused resources.

Where it is my opinion that the SFEMP3shield driver tries to separate itself as much as possible from the sourcing of the stream. Minimal Functional Coding. That cannot be fully realized as it gets the stream from SdFat and its tight relationship to the Interrupt. However any such add’s are probably best left to either another library file, possibly in this project’s repo or to the main sketch of other examples. Currently there is only ONE, that details many techniques of employing the library’s commands. But not putting them in the library itself, as these are examples of which others should read and employ themselves in there sketches.

The existing getTrackInfo I believe was an artifact of getting the Bit Rate, which is now gotten from the VSdsp. Noting the VS1053 supports many file formats, to many all to be supported in the SFEMP3Shield library. Making it extensive to develop to get Tag Info for other formats. Another Sister library would be a good place for that, so it grow independent of each other. I would really like to see others make github projects that have sub modules of the SFEMP3Shield repository. Same for the SdFat, but that is not in Git. I use symbolic links (or windows “hard junctions”) to get the GIT repo’s sub-directories into the Arduino Libraries. Nice and neat.

On my mentioned TODO list, in addition to the ideas you mentioned, I would like to create example sketches for Internet WebServer Juke Box, and a OpenNext File Juke Box. I have the code pieces for the later, just need to do it. Where this would examples how to do a table of contents, other than the simplified (and useless) ls command, as in your request. I have prototyped the WebServer Juke Box by merging with Ada’s SDWebBrowse, with the only glitch of HTTP traffic causing glitches in the sound as it reads the SdCard of the WGET files. So maybe there is something in the ArduRadio that will help with that. Not sure which is better.

And that points out the Arduino and SdFat are only small systems. Opening other files simultaneously can cause issues. As the SdFatLib pre-reads 500 bytes at a time. Big chunk of resource. And getting other files while streaming causes the buffer to be dumped for the new file. And this can go back and forth causing issues. Not sure if this is just a limitation to be lived with.

Looking forward to helping and any contributions from others.

[Michael P. Flaga]

You could use a 3.3V Arduino. On my design’s I have a Mega2650 running 3.3V. I have used the 3.3V pro’s, also. The one watch point is that either the FTDI or ICSP programmer may go 5V, just need to set appropiately. And if the system is native 3.3V then the Shields 3.3V regulator can be shorted out, as its LDO would interfere.

I have accidentally powered all my boards that were supposed to be 3.3V only (systems) at 5V, and got no damage. From the brief exposure. Where as I suspect you may have had the IO at 5 and the VCC at 3.3V which would be more dramatic to the chip.

Where as I would expect basically nothing from the fried IO. not -1 or 15. While you wait. You may want to Oscilloscope or logic analyzer it. to see if the clocking is messed up.

[Author]

Posts