[Michael P. Flaga]

MIDI files can be supported, the original example MP3Shield_Library_Demo.ino is constrained to MP3 files. Whereas, FilePlayer.ino example is more flexible allowing various file formats to be played. including MID. The Arduino’s app is arbitrarily filtering on file extension. Where the VS1053, really does not care about, nor even know the file name or its extension.

Note: I think I recall that VS1053 will only play MIDI type “zero” versus “one” and I had to convert my examples to “0”

[Michael P. Flaga]

There are several challenges to this. The current library only accepts from SdCard. Second one needs a conduit between Raspberry and Arduino.

Serial port would be the most obvious, then SPI, the I2C. Where as throughput is a major concern along with building a layer to transport the stream over the selected interface.

Where there is a fork that I have not yet integrated into the original library that is a Internet Radio Player. It accepts stream over Ethernet. It has the added cost of the Ethernet Shield. https://github.com/gallegojm/Sparkfun-MP3-Player-Shield-Arduino-Library/tree/Due. Where it is originally for an Due. But should work for an UNO.

That all said I would recommend that you look at the following Ada Fruit App Note on Raspberry MP3 player as to not need the Arduino.

 

[Michael P. Flaga]

What happens when you issue the ‘t’ Generate Test Sine wave command?

You symptoms are strange. Please, Confirm you have not modified any of the code? (for these initial tests)

What main Board are you using?

What VS1053 Shield and what SdCard Shield (if not same)?

You have evidence of both the SdCard and VS1053 working and yet failing. As you got past the initial check for and initializing of the VS1053, yet you fail to completely read files from the SdCard (the patch) and lock up playing (not no file found). I suspect there is a some conflicts on the SPI. Likely a Chip Select is floating and intermittently/parasiticly enabling causing the problems.

Nearly all cases that I have encountered with such partial working have sourced from SPI collisions. I might guess that your SdCard’s Chipselect is not properly asserting.

[Michael P. Flaga]

Your return is from ” if(MP3Mode != (SM_LINE1 | SM_SDINEW)) return 4;” which would have expected 4800. where the SM_LINE1 was not set. as detailed in the manual. http://mpflaga.github.io/Sparkfun-MP3-Player-Shield-Arduino-Library/_s_f_e_m_p3_shield_8h.html#ad452717cdf9bf458c30cd20c1e78d719

That all said. this is typical of when the device is not communicating correctly. That in conjunction with your slow observation, suggests your breakout board has a slower clock. Causing the slow play and difficulty in reading back data from the chip. The SFEMP3shield uses a 12.288MgHz crystal. Perhaps your shield is less.

[Michael P. Flaga]

Yes, it can decode a wave file. Please see the FilePlayer.ino example. it is more flexible in allowing file formats to be played.

There are various delays through out the code. First in the examples there are delays in processing serial commands. Then within the library code itself. 100ms to start playing inside playMP3() at line SFEMP3Shield.cpp:836 . It is possible to remove this. But that will then affect the skip’s ability to keep track of where to skip to.  With in the skips themselves there are 50ms inside the skip() SFEMP3Shield.cpp:1063 similar skipto() SFEMP3Shield.cpp:1120 as to mute the begin playing of partial packets. As the skip features are not packet aligned. Where these may be small delays totalling of only 150ms.

Finally, the flush_cancel() experiences a delay. When stopping the play to either cancel or skip the VS1053’s 2K buffer needs to be halted and then flushed. as to prevent unwanted sounds, from finishing or playing at the next play. And depending upon the bit rate it can take a noticeable time to fill and wait for the 2K buffer to empty. Where I see the Stop and Skip’s can have enum flush_m passed into to SFEMP3Shield::flush_cancel(flush_m mode) them as to influence the flush to be one of: post, pre, both or none. You may want to experiment with altering the calls in the SFEMP3Shield::skip(int32_t timecode) line flush_cancel(pre); and simularly SFEMP3Shield::skipto(int32_t timecode) line flush_cancel(pre); Additionally there is a flush when the end of the file is reached.

I would recommend playing with the above parameters passed into the desired flush_cancel calls, to see if you can get a quicker and acceptable behavior.

[Michael P. Flaga]

Congratulations

[Michael P. Flaga]

The SFEMP3Shield Library defines all of its hard resources and configurable options in the SFEMP3Shield.h file. The SdCard’s chipselect is defined with SD_SEL . Notice its how it sets up the sd.begin(SD_SEL, SPI_HALF_SPEED in the example. You can substitute any value you like into or in place of the SD_SEL. Assuming it is actually connected to the SdCards Chip Select.

[Michael P. Flaga]

Could you explain your motive, to provide insight?

Note the SPI pins MISO, MOSI and SCK are hardware wired to these pins on the Arduino/ATmega328. So they are not movable in software or configuration. And are shared on the SFEMP3Shield by both the VS1053 and SdCard. If you want to either of these pins to a different position on the Shield connection, you can use the method displayed in this video; Hot Wire D5 and D7 pins on the SFEMP3Shield it will work just the same.

Where I am stumped as to why you would want to move them on the SdCard, as the Shields are lined up correctly to begin with, unless you are using a break out. Which then should connect directly to original hard SPI pins.

Also note that the on the UNO, Duemilanove pins 10,11 and 12 are tied to the ICS connectors pins. And the Leonardo no longer has the SPI pins on 10-12.

[Michael P. Flaga]

I refer to the Vdsp as the VLSI processor inside the VS1053. There are actually many different flavors of chips with the same DSP core. Which all use the same code base but just different pins and resources.

Yes, the ADA fruit Wave card is not polyphonic as it does not have the DSP power to mix different streams together, it is just the simple ATmega of the Arduino. Where the VS1053 is a coprocessor, with its own DSP just for audio processing, giving it much more abilities. I read in the VS1053’s data sheet section 8.2.9 that

The maximum polyphony is 64, the maximum sustained polyphony is 40.
Actual polyphony depends on the internal clock rate

That said polyphony is about the simultaneous playing of different notes. Where the VS1053 interfaces to the Vdsp is the single SPI interface. This limits it ability to single stream of data. Which this stream typically comes from, but not limited to, the SdCard. Or in other words it can only support one stream at a time.

BUT…

But the VS1053 also has a Command path to the VDSP outside of the Data Stream path. There are two chip selects. XCS (command) and XDCS (data) for the single SPI. As a result there is a way to play PCM (and only PCM) encoded data through the command channel while playing another format through the data channel. Whereas this is not playing two simultaneous MIDI files at the same time. Rather it is possible to play a MID(or MP3, etc…) and PCM at the same time, where the Vdsp will mix these together before the analog output.

And we have not supported this feature in this library. That would require a significant redesign.

Since the VS1053 does not support two simultaneous streams of MIDI encoded files, but the Vdsp will support up to 64 simultaneous notes, it should be possible to read both MID files and send their notes mixed into the single RealTime Midi commands, at their appropriate times. This would require the Arduino to understand the MID file and send the corresponding MIDI command at the corresponding time as noted in the file and move on to the next MIDI command in both files. A lot of work. But I suspect possible.

____

That all said looking at the WaveHC, I see that it only supports WAV and not MIDI…

[Michael P. Flaga]

The Vdsp can take either Real Time MIDI or MID file. The SFEMP3Shield driver does not support RealTime. There is another library that I have used that will do RealTime. I forget its name and have not integrated into this. Where I have played MID files. I recall that the Vdsp can only take one of the flavors of MID files. I needed to convert it. I forget that to, it was 18 months ago.

I am not a music person, so I have no MIDI experience, to know what needs to be done.

What is the Arduino Shield that you state is not polyphonic?

I would review VLSI’s forum to find out what you want to do. It may take some digging, but I suspect it has been asked and answered there. And if not they typically reply with helpful response after a few days. Just need to go back and occasionally check. Once you determine what is needed, then we can possibly help add that to this library.

[Michael P. Flaga]

Yes, when streaming data to the Vdsp there is no need to read back the transfer. However, the Due’s AT91SAM’s SPI_TDR is only double buffered and it appears the UNO ATmega’s SPDR is not even. Effectively this means it is possible to overrun the transmission’s DR (buffer). Hence the need to either wait before or after refilling until finished sending the next byte, as not to drop data.

I recall, the Vdsp with the implemented crystal is specified for a max SPI clock speed of approximately 6MgHz, where the default SdCard is 8MgHz. It was found that this over speed is tolerated for sending stream data, but found to be a problem in getting a response, causing unpredictable bit shifted delayed responses. Hence the need for the Vdsp and the SdCard to play together nicely along with other future devices.

Yes, it would be possible to write one’s own SPI equivalent driver. I believe the SdFat did so. Whereas the objectives were successful, using the standard libraries, we have not bothered to create exotic resources, that need maintaining. I had thought about using the SdFat SPI calls, however, this was avoided as not to create dependencies.

It is always a series of give and take with best practices versus best design aka… “Technical Debt versus Technical Cost along with Minimalistic Funcitonal Requirements“

[Michael P. Flaga]

That is the nature of SPI, being master / slave. To get data from a slave the master must wait for the response.

Where as there are often cases peripherals need only be told and don’t respond. In those case one can blindly send. But then need to ensure that the next send does not stomp on prior sends. So it is simpler just to typically wait until the current is done.

[Michael P. Flaga]

Yes, the hardware is actually controlling the chipselect. If one of the prescribed allowed pins. Where the code builds (aka packs) a 32 bit word that contains the mask of chipselects, LASTXFER bit/flag, and data value to send into the SPI_TDR register. All necessary to transmit the byte, as opposed to the ATmega328 that has different SPDR and SPCR. Where as the code is simply writing the TDR as opposed to writing the digital out directly. So basically the same affect and cycles.

The Big advantage to having hardware queued control of the CS would be in using the DMA, to move data while non blocking. Only need to start the transfer, go and do something else and come back and check if it was done. And this is where hard CS support is useful. Where hear the spi.tranfer blocks for each byte, before until it is ready and after until it is sent.

I just remembered while, looking at it again. I recall and see that only pins D10, D4, D52 and D78 of the Due can be used with this queue controlled method for Chip Selects. Where the SFE MP3 shield uses D6, D7 and D9 as chip selects. So it become academic, without jumper’ing.

[Michael P. Flaga]

YES, what you want to do is actually already built in to this library as a configurable option. As mentioned above the SFEMP3ShieldConfig.h can be configured to implement the refilling method as either a timer or soft poll. This works out well with other implementations that I have done that require non interfering interrupts. Simply setting the USE_MP3_REFILL_MEANS to USE_MP3_Polled allows the use of the MP3player.available(); command in the main loop to fill the buffers, outside of interrupts (aka real-time). And further specifying it to USE_MP3_SimpleTimer along with having the prescribed optional library installed cause the refill only to fill on a scheduled period. The only draw back is the pause and resume commands have issues, in these modes. But will do exactly what you described.

Note that this library depends on SdFAT, not developed here. Where SdFAT caches 500 bytes. This is good and bad. Cache is good until you need to fill it. It is this filling that if done in while in an interrupt causes the lack of real time. So by using not using the USE_MP3_INTx refill realtime is spared.

If you are real concerned about the precision of the Step Motor pulses I would recommend using the OutputCompare functions to pre-program the cycle time of the next transactions and then update it latent before the next toggle. It similar to the Timer, but it toggles the pin at that hard time regardless of any other code and or interrupt, then creates an interrupt for servicing.

As for the efficiency of the ExtendedSPI features, it is purely software no hardware. If you read into the code of the Due’s (aka SAM for ARM) SPI.CPP it is simply keeping track of the CS for you, in code, no hardware DMA. It still has the same overhead. One’s application still has to send the data one byte at a time and still check the DREQ status every 32 bytes. The real potential benefit here would be to make the SPI transfer non-blocking for a FRAME, either soft are DMA. But then one needs to add FINISH interrupts and more complexity. Especially on receiving, as each receive is linked to a specific transmit in the case of the SPI. Unlike the case of Serial UART, where rx and tx are a-coupled. As a result their are trade offs. In this case it becomes more confusing to have the library do the same thing two different ways and no real benefit.

[Michael P. Flaga]

Please see the following GIST HUB examples I have just created MP3random.ino along with MP3PlaySequence.ino.

[Author]

Posts