This project has moved and is read-only. For the latest updates, please go here.

Can't play this M3U8 Stream

Jan 20, 2015 at 9:16 AM
Hi again!

Sorry about this - I can't get this M3U8 stream to work using BackgroundAudioPlayer (though it works in the Sample MediaPlayer demo):

Any help would be great, thanks! :)
Jan 20, 2015 at 9:57 AM
I'm using the latest phonesm-1.4.5-alpha by the way :)
Jan 20, 2015 at 8:56 PM
Edited Jan 20, 2015 at 8:56 PM
How is it misbehaving? Are you using the WP8 or WP8.1 background audio ("BackgroundAudioPlayer" suggests the former?

I tried with both the WP8 and WP8.1 background audio sample players. It worked in both, but sometimes it takes a while to start. The default buffering policy has a few parameters that control how the system buffers. AudioTrackStreamer's contstructor sets the startup buffering size to 24k (that is, it will not start playing until it has 24k buffered) and the re-buffering threshold to 64k (so if the system runs out of data, it will not start playing again until it has 64k buffered). There are constraints on the duration in the buffer as well. These values should probably be recomputed based on the actual stream bandwidth, but unfortunately there is no mechanism to get the bandwidth (or an estimate of the bandwidth) to the buffering manager. As a result, if the bandwidth is very low it can take a while to start playing. If the bandwidth is really high, then playback starts before enough data is buffered and the debug output log fills up with messages related to buffering state changes.

For example, if you have a 22kBit stream and want to start playing after the first three seconds are buffered and wait for seven seconds of data after the buffer runs empty:
   DurationStartingDone = TimeSpan.FromSeconds(3)
   BytesMinimumStarting = 22000 / 8 * 3 = 8250
   DurationBufferingDone =  TimeSpan.FromSeconds(7)
   BytesMinimum = 22000 / 8 * 7 = 19250
Note that AudioTrackStreamer's constructor sets,
   BytesMinimumStarting = 24 * 1024 = 24576
   BytesMinimum = 64 * 1024 = 65536
which is about 3x more than the above.

It would probably be a good idea to look at all the values in DefaultBufferingPolicy and make sure that if some parameter "A" is less than "B" before you make changes, then "A" is still less than "B" afterwards. The rest of the system only uses IBufferingPolicy, so the parameters are never used outside of the methods implemented in DefaultBufferingPolicy.

To keep things more interesting, the operating system also does some buffering.
Jan 21, 2015 at 2:50 AM
Omg I'm so sorry, it appears the station went down yesterday when I was trying to access it so I couldn't connect. Couldn't work better right now, thanks for everything!
Jan 21, 2015 at 9:25 AM
No worries. You might still want to look at updating the buffering policy parameters as described above for the low-bandwidth streams. Otherwise, it could take over ten seconds to start playing (when the connection just barely fast enough to play the stream).
Jan 25, 2015 at 2:10 PM
Thanks again! Another question: Is it possible to make the stream keep trying to reconnect if the network goes bad? Say the app is playing a stream and the user enters a tunnel or lift with no reception, when they come out and reconnect to the network can the stream automatically start the connection again?
Jan 25, 2015 at 11:58 PM
There are retries for short glitches handled by IRetryManager, but it didn't seem appropriate to blindly keep retrying for too long. One would generally want to give the higher level code a chance to do things like try another URL or tell the user that something is wrong. The client code could check for errors and restart a given stream if it sees a TsMediaManager.MediaState.Error (e.g., take a look at HlsView's TsMediaManagerOnStateChange).
Jan 27, 2015 at 1:00 AM
Alright, thanks :)