Playing FLAC Music Files

I’m trying to play 44100khz FLAC files from an SD card on a Panda II with the FEZ Music Shield. I’ve loaded the FLAC patch plugin, and the file “plays”, but it is VERY choppy. I’m thinking that it may be the rate at which I’m reading data from the SD card?? Here’s my code (slightly modified version of GHI driver):

private void PlayStreamThread()
	this.spiPort.Config = this.spiDataConfig;

	while (this.playState == PlayState.Playing && this.playBackStream.Position < this.playBackStream.Length)
		while (this.dataReq.Read() == false)
			;  // wait till done

		if (this.playBackStream.Length - this.playBackStream.Position <= 32)
			this.playBackStream.Read(this.blockBuffer, 0, (int)(this.playBackStream.Length - this.playBackStream.Position));
			this.playBackStream.Read(this.blockBuffer, 0, 32);


	while (this.playState == PlayState.Playing)


	if (this.playBackStream != null)
		this.playBackStream = null;

No way to do it without RLP/RLPlite. .NET MF is too slow for that.

@ Hyperlisk - @ jasdev
Hi, where is the bottleneck? Which codecs can be used with managed code on our NETMF mainboards? What are the datarates that can be reached with reading from SD-card?

@ andre.m -
thank you. I think, the decoding is done by the FEZ Music Shield, which is nothing else (I think) as the GHI Music module. The issue is to bring the data of the encoded (compressed) music file fast enough to this decoding device.
Btw: Where is WouterH, so many valuable posts an last online Jan. 14, 2013

@ jasdev - Try feeding more then 32 bytes at a time. It has been awhile since I have messed with that module.

It’s not the SD card, it’s the SPI. Managed SPI is like 10 times slower than RLP SPI.

Thanks for your replies.

@ Hyperlisk - I remember seeing something about an RLP driver for use with the music shield. I’ll try to find it.

@ RoSchmi - Yes, the issue is not the music shield. It uses the VS1053b chip to do the decoding, and it plays mp3 files from SD just fine. The data sheet for the FLAC plugin indicates that it is capable of playing 44khz files. The bottleneck must be in the SPI interface or in the SD interface.

@ andre.m - I remember seeing something from Whouter. I’ll try to find it.

@ Architect - thanks I didn’t know you could send larger chunks of data to the device. I’ll re-read the manual, and try it tonight.

@ Architect -
I read in the manual that only for chunks of 32 byte it is guaranteed that the buffer of the VS1053b chip has enough free space to hold the sent data. How did you manage to avoid buffer overflow?

That was just a suggestion to try. As I said it has been awhile. Thank you for clearing the meaning behind 32.

I tried several things last night.

  • larger buffer when creating the FileStream
  • larger buffer when reading data from the stream
  • larger buffer when passing data to the VS1053b

The first two changes seemed to have little or no affect.
The third change did help a lot, but did not eliminate the problem, and if I made that buffer too large, I would end up with the overflow condition that RoSchmi mentioned.

I’m marking Architect’s answer since his suggestion helped the most.

Next I’m going to try to port godFather89’s code to the Panda II:

@ jasdev - Have you tried to give the thread “PlayStreamThread” the higest priority?

@ RobvanSchelven - Just tried that, but it didn’t help.

I’m going to try to use @ godFather89’s RLP driver for the VS1053b.

See this topic: