You want to use "true" for the second parameter for loadSound.

With "false" the sound is downloaded in its entirety before playing, which could exhaust the RAM.

By using "true" it should stream the sound.

Try that and let us know if it works.

MP3 streaming is a *very* recent addition to Flash Lite - however, we've had some success using it to stream audio in a widget. A couple of other developers (cbreeze in particular) have done the same.

However, it's very sensitive to the format of the MP3 and other factors.

Do a search on the forum for "loadSound" and you might find some helpful information.

"pls" files are simply playlists - they're text files that contain a list of URLs to the actual streams themselves.

This file smoked my chumby!

It looks like it was something funny with the encoding (which seems to be the problem most often in these situations).

I "re-encoded" the file via iTunes (quick, easy, and clean).  Renamed it to get rid of the "%20's" and ran it with the following code on the main timeline:

stop();

var s:Sound = new Sound(_root);
s.loadSound("http://www.pathtoserver.com/your.mp3", true);

From what I have read, you are not required to call s.start() when flagging a sound for streaming.  Not sure if it causes an issue by having it included.

Also, though I am sure it's obvious, make sure you set the widget play time to something greater than the song length.

Cheers.

First try the reencoding - that might be enough to fix it.  It's possible that your server is OK but that the encoding bothered the streamer more than playing locally.

I used curl on a Mac, though curl on a chumby will work too:

# curl "http://doxuanhuyvn.freevnn.com/Ave%20Maria-Schubert.mp3" > avemaria.mp3

The directory containing the files is visible here, so I'd expect any browser to be able to download them.

From my location, the server appears to be accessed through a web proxy cache called "lusca" (apparently based on squid 2) - not sure if that's interfering somehow.

I have had to overcome quite a few challenges while trying to get my streaming MP3 sound working properly on my flash/widget.

Below are some of the lessons learned in the process, that someone may find useful:

- The MP3 encoding format (bit rates & frequency) is quite touch and go with the chumbyflashplayer and getting those wrong may get your sound to play like Donald Duck on caffeine. Experiment with the most standard combinations first. Another place you might be able to tweak this is through the chumbyflashplayer command line parameter '-p' (type 'chumbyflashplayer.x --help' on the SSH prompt to find out more)

- Make sure to set the streaming parameter as 'true' in the loadsound() function. Setting this 'false' should technically allow the sound to play in non-streaming mode, but in my experience the sound has been extremely jumpy and broken even on a wired LAN connection. I would highly not recommend using this mode.

- The most annoying problem I have had so far was a sound overlap issue, particularly prominent when running the flash movie directly (not as a widget). This occurs when you stop a sound mid-way and then load another sound into the same or a different sound object. When the new sound is accessed, it would play about 3 seconds of the old sound from some buffer and would loose the first 3 seconds or so from the beginning of the new sound. To resolve this, use the '-n' command line parameter to configure the sound buffer, when starting the movie with the chumbyflashplayer.x command. The default value for '-n' is 16, with recommended values being between 4 and 32, but in my experience setting the value to 2 has almost eliminated the overlap.

UNRESOLVED PROBLEM (please help if any one has faced a similar issue):
All sound functions on the Flash application consistently stop working after about 6-7 hours of leaving the application/widget running continuously on the Chumby, thus making it quite un-reliable for real world use. The application itself is still fully responsive. Sounds can still be played fine by using btplay through an SSH session. The only way to fix the sound in the application/widget is to reload/restart the app. The exact same flash application works fine for days together on a PC or through a web-browser without a problem? The application makes use of the loadsound() function to stream and play the MP3. The MP3 file itself is still accessible through the SSH session.

I have really hit a blank wall with the above issue and any help would be greatly appreciated!!

Thanks for your response cbreeze.

Yes, I do intend to run my app as a private stand-along app (non-widget mode), although my tests even through the widget mode have yielded me the same results (sound still stops functioning afer 6-7 hours).

So far I have only been utilizing the Flash decoder (loadsound() function) to play the sound file through my app. The only time I used btplay was from the ssh session to test whether the actual speaker-hardware was still functional when the flash app-sound stopped working, which resulted in a positive.

Based on your idea, I am now thinking of modifying my program to use btplay to run the sound instead of the flash decoder, but am not aware of the power or limitations of btplay access through flash. At the very least I would need:
- options to start/stop the sound from within flash
- an option to play an MP3 from the web in streaming mode
- possibly indicate the sound-progress back to the flash app (good to have but not critical for my purpose)
- an onSoundComplete sort of flag to prompt the flash app when done (critical)

The only reference I have found so far for implementing btplay is here. I'm researching it right now with my fingers crossed.. . My major concern is that there doesn't seem to be a ready trigger to indicate that the sound has finished playing, so I guess I'll need to query the 'player state' every second or so to find out, which does seem a bit tacky. Lets see if it works without crashing after my critical 6th hour!

If you have implemented btplay through a flash app before, any tips you may wish to share would be more than welcome.

Thanks once again.