Home Forums Sparkfun MP3 Shield Library Support Forum 2 ideas – getTrackInfo and http/other stream sources

This topic contains 1 reply, has 2 voices, and was last updated by  Michael P. Flaga 6 years, 3 months ago.

Viewing 2 posts - 1 through 2 (of 2 total)
  • Author
    Posts
  • #1823

    jbarth
    Member

    I have been following this library for awhile.  I appreciate the effort guys.

    I am mostly just tinkering and learning but have a few ideas for practical applications.  I believe that there are two very common features that should be integrated into the library.

    First, the ability to use the getTrackInfo method on a file other than the currently playing track.  I really would like to discuss this or hear input from others, and throw around ideas.  Awhile ago I had made minor adjustments to the library to pass a separate file handle, to reuse the getTrackInfo code.  The library has changed a significant bit with Micheal Flaga’s recent efforts and I’m not sure what the best way would be to integrate this ability.  The purpose would be to create a “table of contents” more informative than just a directory listing when requested.  OR would a better idea be to iterate through a filtered directory listing and pass each file to playMP3, and then getTrackInfo?  …that seems like a lot of excess work and would I not hear 32 bytes of each song?

    Also, I know there has been minimal discussion on the forum regarding network streaming.  Just last night I merged the Webduino hello world example with the SFEMP3Shield library on a Mega.  The sketch ran I was able to ls the SD, and http worked but, I have yet to test audio and verify concurrent http access and playing audio.  This made me want to see what it would take to source an http stream.  I believe I have an example of what is required referenced below.   It appears there is a transferStream method added to this version of the library however, I’m not sure how the recent changes of the library impact this.  I do know that using the library the way it is in the Arduradio project wastes resources because it still instantiates all the SD related handles, and this is required because of the way the library depends on SD.

    https://github.com/jmgjmg/ArduRadio

    I hope these two ideas promote healthy discussion, this is a really useful library and these ideas might make the shield more flexible.

    Thanks.

    #1827

    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.

Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.