Networked music player using the mini - Page 3 - Project Showcase - Netduino Forums
   
Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Networked music player using the mini


  • Please log in to reply
71 replies to this topic

#41 piwi

piwi

    Advanced Member

  • Members
  • PipPipPip
  • 114 posts
  • LocationGermany

Posted 28 January 2013 - 10:05 PM

Hi Hanzibal,

 

thank you very much for sharing this code. I got it instantly working on the N+1 with 4.2.2, after some mods of course but first try and playing like a dream ...

 

After hearing the music from John Miles coming out of the speakers using a couple of wires and just the sparkfun bob you mentioned was quite .... let's say .... wow .... give that man a cigar ....

 

... but all of a sudden when the music gets louder and more intense (if you know the music, you know what I mean) it get's well distorted like getting not to much of data and the music starts to sound as if it is clipping (like playing to loud).

 

Would be nice if you could give a couple of tips or so ... or anybody else out there ....

 

... hold a minute ... if i start playing David Guetta it sound it's juggling with the music just way toooo slow and missing a lot of samples ... plus if kind of loops ... plays first song of SD and then kind of stops ... changed the vs1053 class at appx stmt 250 (the underlined part), seems to work, at least this is, the musax still plays not so as know from ther origional ....

 

if (offset + read > sb_len) read = sb_len - offset;

aread = s.Read(sb_buff, offset, read);

head += aread;

canread -= aread;

if (aread != 0) goto more;

 

// Soft mute

WriteRegister(0x0B, 0xfefe);

Flush();


 

Cheers,

 

Peter..



#42 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 29 January 2013 - 05:30 AM

Hi piwi!

 

Glad you got your player running and great to hear that my code has come to good use. There has been quite a few code downloads but you're the first to tell me that you're using the code.

 

As music become more vivid at times, i.e. when the standard deviation of the data increases, the bitrate increases and depening on the audio format, you may experience underflow. That is, the Netduino can't deliver data at the speed required in order to keep the VS1053 buffer satisfied.

 

What audio file format are you using and what bitrate?

 

My tests show that mp3 files @ 320bps CBR (constant bitrate) works well but I haven't tried any higher than that. Also, really high quality Ogg Vorbis are likely to cause underflow at times, not to mention WAV files @ 44.1 kHz that will cause underflow for sure simply because data throughput is insufficient.

 

When looking through my code, I found that the player routine (from which you took the snippet above) seem never to return. Maybe this is what you fixed by modifying the code slightly? If so, it surprises me that this also helped overcome the underflow issues but could be.

 

Does music play correctly after the modification?

 

Could you please upload (or email) one or more choppy songs (non-copyrighted naturally ;-)) to somewhere for me to download it?

 

I could then try playing them on my rigg and see if it behaves the same.



#43 piwi

piwi

    Advanced Member

  • Members
  • PipPipPip
  • 114 posts
  • LocationGermany

Posted 29 January 2013 - 08:08 AM

Hi Hansibal,

 

can't reach out to my music right now and look at the MP3 props. but the song from "Somewhere Over the Rainbow" by Israel Kamakawiwo'ole plays really well, i.e. without any chopping, at least as far as I can hear. Than again the song from David Guet­ta feat. Kel­ly Row­land When Love Takes Over chops like crazy .... when I get to my music I will make some samples of the latter. If I am able to record the chopped music on some other PC I have I will make some available as well ...

 

For the code correction, I only made the change with the if line underlined above causing the system to move on to the next song. The chop behavior stayed, I increased the SPI clock to 10000, causing the music to play a little longer without chopping but chopping it did. I did notice however, that everytime I started deployment with a break point on playing the next song, and waiting for some time the chopping stayed away I bit longer but not consistently. The next time around for playing the same song it chopped somewhere else but always in the intense part of the music .... 

 

Since I have a N+, so network available, I will try to stream from the network and see how that works, just to rule out any SD sharing the SPI device. I read something in the datasheet about some SPI sharing to be set on the VS1053 ... to be continued ...

 

Cheers,

 

Peter.

 



#44 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 29 January 2013 - 08:53 AM

I see. You don't have to do any sound recordings of the chopping. I know pretty much what you mean but I do want a song to find out what really happens in code when the problems occur.

 

Meantime, you could try re-flashing your N+ without networking - it could very well be that networking does some stuff in the background.

 

I'm quite certain SPI speed is not the issue, 10Mhz is well over the requirement.

Also, the so called "shared mode" of the vs1053b is a kind of "legacy mode" for backwards compatibilty with older vs10xx chips and so that will probably only make things worse.



#45 piwi

piwi

    Advanced Member

  • Members
  • PipPipPip
  • 114 posts
  • LocationGermany

Posted 29 January 2013 - 07:33 PM

Hi Hanzibal,

 

read your mail please ....

 

I am curious about your findings ....

 

TIA

 

Peter.

 

Addendum: Convert all to 192 and later to 128 and they do play without a glitch, I was probably a little over enthousiastic ....



#46 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 29 January 2013 - 11:10 PM

Both your example songs play beautifully smooth on my rig. Naturally the MIDI does but also the mp3 which is 320kbps according to Windows, don't know if it is VBR or CBR though.

 

In the mp3, I might be able to hear a slight tendency of bass clipping but that's probably due to a little bass overdrive in the recording itself.

 

According to your email, it seems you got a data throughput bottleneck somewhere between 204kbps and 233kbps while I don't. Hopefully, I'll have time to look more into this over the weekend.

 

As said, it could be something is going on in the background. I use a mini with nothing else on it. Got any separate threads running along with the play loop? Did you try re-flashing without networking?

 

Sent you an email as well.



#47 piwi

piwi

    Advanced Member

  • Members
  • PipPipPip
  • 114 posts
  • LocationGermany

Posted 29 January 2013 - 11:17 PM

No seperate threads, just plain and simple:

 

... some init code and then the below nothing ...

 

// play all the songs on the sd card repeatedly

for (int i = 0; true; i = (i + 1) % sd.Files.Length)

{

  lcdPosition(1, 1);

  lcdWrite("Playing: ");

 

  lcdPosition(3, 3);

  if (sd.Files[i].Length <= 18)

  { lcdWrite(sd.Files[i]); }

  else

  { lcdWrite(sd.Files[i].Substring(0, 18)); }

 

  using (var s = sd.GetStream(i))

  {

bob.PlayStream(s);

s.Close();

}

}

 



#48 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 30 January 2013 - 09:43 PM

It just occurred to me it could be you read to small chunks of data from the SD card - what size is your stream buffer?

 

I use a 4kB buffer when creating the FileStream to feed the player:

_stream = new FileStream(_filename, FileMode.Open, FileAccess.Read, FileShare.None, 4096);

 

If I remember correctly, a smaller buffer than that will cause problems. If you use a smaller buffer, increase it. However, as said earlier, the N+ is a bit low on memory when flashed with networking so you might actually run out. If you do, either try using a mini, a regular N if you have any of those or re-flash you N+ without networking.

 

You need to keep the chunk size small enough to achieve "smooth" buffering while at the same time large enough in order to keep the CPU processing (in between reads) fairly insignificant. It's a matter of finding the balance between these two and its not always too logical.



#49 piwi

piwi

    Advanced Member

  • Members
  • PipPipPip
  • 114 posts
  • LocationGermany

Posted 30 January 2013 - 09:52 PM

used that size and even doubled it, both did run. Only the latter one was having a slightly better sound and stayed ok a bit longer, but after a while the chopping came back ...

 

will keep on trying, looking ... otherwise I'll have to get a mini .... and an sd card reader ... we'll see



#50 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 31 January 2013 - 07:59 AM

Ok, well then I don't think a mini would help (even though they're very nice to have). I think there's something in the play loop slowing down things, its very sensitive and I've experienced that even small changes that might look insignificant can cause problems. As I mentioned earilier, the code I uploaded here is different from the one I use since I've removed irrelevant stuff. I will try set aside time to look into this over this weekend.



#51 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 02 February 2013 - 11:18 AM

Hmm...I downloaded my own code from previous post (v1.0.0.1) and it worked perfectly straight away. Even so, I fixed the endless loop issue and uploaded an upgraded v1.0.0.2 to the original post:

 

http://forums.netdui...ge-2#entry35811

 

@Piwi: I made this modification in the end of the play loop:

        offset = head & sb_mod;        read = canread;        if (offset + read > sb_len) read = sb_len - offset;        if ((aread = s.Read(sb_buff, offset, read)) == 0) goto quit;        head += aread;        canread -= aread;        goto more;quit:        // Soft mute        WriteRegister(0x0B, 0xfefe);        Flush();

 

This will probably not remedy the "chopping sound" issue that you're experiencing but could be worth a try. Meantime, I'll try running the code on an N+ and report back shortly.



#52 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 02 February 2013 - 09:28 PM

Tried the code on an N+ (fw 4.2.0.1) and attempted to play a 320kbps mp3 and it chopped like crazy (every 10th of a second or so).

 

The play loop never becomes idle . I put a breakpoint in that code section and never come there. It's clearly a case of buffer underflow. Dunno, if the default SPI speed of the N+ is too low or what.

 

I'll try a few other tricks and get back.



#53 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 03 February 2013 - 12:43 AM

In  order to disable networking, I re-flashed the N+ so that it became a regular N. Since the N does not have an internal uSD card socket, I fitted an external SD card reader (just like I do on the mini). That bought me some more RAM allowing me to experiment with larger buffers but sadly, that didn't help.

 

It seems the N+ (and the N?) has a lower throughput on SD card transfers. If I remember correctly, the mini uses a 10Mhz SPI clock for SD card transfer and it would surprise me if the clock is different for the N+ and N uses. Does anyone know?

 

@Piwi: You mentioned using an interrupt on vs1053b DREQ pin. I've though of that before but since the mini's only got a single SPI interface. that would make little sense. On the N+ however, SD card transfers are handled separately (internal SPI?) so it might be worth a try.



#54 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 03 February 2013 - 04:34 AM

Chris said the N+ runs SD card transfers at 10Mbps and if I remember correctly, that's the same as the mini. I can't understand why the performance of the N+ is so much slower than the mini.

#55 piwi

piwi

    Advanced Member

  • Members
  • PipPipPip
  • 114 posts
  • LocationGermany

Posted 03 February 2013 - 12:38 PM

Hi Hanziball,

 

thank you for your tryouts and efforts in this. Got a little sideway effort going for my big five-o so I didn't spent that much of a time on this... 

 

On the one hand I'm glad you got to the same result so I'm not that crazy after all, on the other hand a little bit less glad as well since I now (and maybe more) do have a challenge to go for ....

 

.... I'm going to try some other stuff concerning this matter as well and let you know my findings ....

 

Maybe Chris can bring some ideas into this matter as well why the small netduino mini outperforms the N+



#56 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 03 February 2013 - 08:32 PM

I thought some more over the interrupt thing and I don't think it will work since dreq may go up and down during data transfer. Maybe two threads working together as a syncronized producer/consumer pair would work. I doubt it since context switching probably introduces an overhead that would eat up the benefits of reading and writing in parallell. I'm not even that sure you would benefit much from this as I recall someone saying the Netduino does not use DMA för SPI transfers. Could still be worth a try though.

#57 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 05 February 2013 - 02:25 PM

@Piwi: Have you figured out any clever way to achieve smooth playback on the N+?



#58 piwi

piwi

    Advanced Member

  • Members
  • PipPipPip
  • 114 posts
  • LocationGermany

Posted 05 February 2013 - 08:57 PM

Hi Hanzibal,

 

well kind of halfways, tried to make my own loop using double buffering principle, does play but got the same issue as before. It tries to load to the second (or first whatever is active) only at the end of a playbuffer (32 bytes, etc) and it is there where the chopping kicks in. It choppes even at 192 kbps but plays 128 kbps without any chopping, need to tweak on that Double buffering logic, I think it's not that perfect as I want it to be ....

 

As an alternative, hunting for some success I got your files @320kbps just playing perfectly ....... on a panda 2 with a spi clock at just 1000 kHz but that system is running @ 72 not as the N+ @ 48.... no change needed for your vs1053 class only some on the sd card class .... poc ...

 

So I exchanged a temp monitor I have for my palms (running @ 1 minute intervals) where I used the panda for with the N+ so the temp is ok and the mp3-playing as well .... up to the next level ... get this working with network streaming .... shouldn't be that hard ....

 

Thanks for all the help .... I own you a nice cool beer .... I'll let you know when the humbug kicks in ....

 

Cheers,

 

Peter.

 

Addendum: Tried some WMA Lossless with according to W7 file props 800+ kbps or even more than 1000 kbps, but that won't play but so far so good all mp3s I could dig up played .... good 4u !!!!



#59 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 06 February 2013 - 07:58 AM

Got temp, got mp3 - you're done! :-)

 

It seems getting the N+ to play high bitrate songs is a real challange. An idea would be to connect SO from SD card directly to SI of the VS1053b via some external circuitry. Then you would have to run a really tight loop (interrupt would probably not cope) on your N+, constantly monitoring DREQ. Plus you could only safely transfer 32 bytes each time DREQ goes high and you'd have very little (if any) time to perform anything else.

 

I don't think a network stream would help much, especially since networking would require some processing power of its own plus you'd have to deal with network delays due to collisions and such. This would require a substantial buffer which is not possible given the small amount of available RAM on the N+. I believe SD card to be much faster anyway.

 

Have you tried playing WAV (as ripped from an audio CD) on the Panda?



#60 hanzibal

hanzibal

    Advanced Member

  • Members
  • PipPipPip
  • 1287 posts
  • LocationSweden

Posted 09 February 2013 - 03:26 PM

I made a comparison measuring SD card read speed on the N+ och mini respectively. I was quite surprised of the results:

N+     : 489 kbpsmini   : 261 kbps 

The tests where conducted 3 times on each of the two boards reading an 11MB file (from a 2GB uSD card) in 8kB chunks.

 

The N+ was flashed with the 4.2.0.1 firmware while the mini has the older v4.1.1.0 a7 firmware. Both boards use a 10Mhz SPI clock.

 

According to the results, the mini could never play a 320kbps CBR mp3 file. I suspect that the mp3 files I've been playing are not CBR and they never go above 261 kbps, probably averaging a lot less.

 

We can at least conclude that SD read speed is not bottleneck of the N+.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.