Jan 20, 2015 at 7:56 PM
Edited Jan 20, 2015 at 7: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.
'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
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
'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
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
, so the parameters are never used outside of the methods implemented in
To keep things more interesting, the operating system also does some buffering.