Cerb40 + Music Module Artifacts

Archive
#1

So I’ve got my Cerb40 breadboarded with a Music Module and Micro SD Module via extender sockets. I tried to keep the wire lengths within about a mm of eachother. As you can see in the picture it’s a bit of a rats nest. You can see a Wifly in the picture too… but I tried with that disconnected and commented out so it’s not a factor.

Everything is implemented in pure NETMF and not Gadgeteer. I modified the Music Module driver constructor for the pin assignments for the Cerb. SD is mounted with GHI.OSHW.Hardware.StorageDev.MountSD();

It plays back a 128Kbps MP3 file, but there are pops and artifacts every second or so. I’m guessing it wouldn’t be far fetched to assume that the shady connections to the breadboard are causing the problem… but I just wanted to collect any opinions from those who might have tried this before I route and order PCBs.

And if I’m to assume that getting everything soldered/socketed on a PCB will improve it… can anyone comment on how critical the trace lengths are for SD and SPI?

Thanks.

#2

could. also be an issue with buffering of the music off the sd.

1 Like
#3

Unfortunately you need to ensure an almost flawless stream of data to the MP3 module. If you have any bottlenecks it will cause stuttering etc.

Bottlenecks can be caused in many ways but with Mp3 playback its most common ones are…

  1. Streaming from a file without bufferring, you will need to buffer data in memory to reduce the number of calls to get data from the file. You will need to experiment to find the best amount.

  2. Drawing or loading Bitmaps causes all threads to stop (I believe it uses RLP so all C# threads are paused until it is complete). On slow processors and larger screens this can cause the buffer on the Mp3 module to run empty causing the stutter.

  3. RLP, remember RLP causes all C# threads to pause so if you are using your own calls ensure they dont take too long to execute.

1 Like
#4

Good points guys… I see that there is essentially a 32 byte buffer array apparently limited by the internal memory of the decoder, but I hadn’t considered buffering my filestream yet. I’ll give that a shot this evening.

#5

Well, it seems BufferedStream isn’t implemented in .NETMF 4.2… I tried the TinyFileSystem implementation from CodeShare, and it stuttered like mad. I’m not sure I was using it right though.

Anyways, I decided to move on to other tasks in the migration I’m doing to the Cerb40. I assigned quite a few other pins, and added a bunch of stuff to my breadboard. I don’t know exactly what I did, but I have perfect playback now.

Soooo maybe I jiggled a wire just right, but at any rate I’ve got my proof of concept so I’ll lay out my PCB. I went ahead and gave Bodwad a tip of the hat for a detailed response :slight_smile:

Thanks for reading, gents.

#6

Yeah you need to do the buffering yourself by saving it to an array in memory. Sounds like you dont need it now though so its all good :slight_smile:

Good luck :smiley: