Thought I'd sum up the evidence regarding track transition glitch based
on the log I've attached to bug
http://bugs.slimdevices.com/show_bug.cgi?id=9003

The role of decode and output buffers is explained in this excellent
article 
http://logitech-en-amr.custhelp.com/cgi-bin/logitech_en_amr.cfg/php/enduser/std_adp.php?p_faqid=6060

Normal track transitions end with a trackStartEvent which indicates the
new track has started playing.

[08-08-02 18:48:58.2184] Slim::Player::Source::trackStartEvent (1649)
Song queue is now 8

A track transition begins with a decoderUnderrun event which signifies
the end of the track, meaning no new data from network.

[08-08-02 18:51:59.6771] Slim::Player::Source::decoderUnderrun (607)
00:04:20:12:1a:99: Decoder underrun while this mode: playout-play

An abnormal track transition ends with a trackStartEvent

[08-08-02 18:52:09.6442] Slim::Player::Source::trackStartEvent (1649)
Song queue is now 9

But is then immediately followed by an abnormal output buffer underrun,
meaning no audio data available to play.

[08-08-02 18:52:10.0302] Slim::Player::Source::outputUnderrun (800)
00:04:20:12:1a:99: Output buffer underrun (decoder: 88209 / output: 0)

Notice however that the decoder buffer at this stage has 88209 bytes
already available from network, which suggests that the audio decoding
process is in trouble.

The output buffer underrun triggers a pause

[08-08-02 18:52:10.0306] Slim::Player::Source::playmode (309)
00:04:20:12:1a:99: Switching to mode pause from playout-play
[08-08-02 18:52:10.0316] Slim::Player::Source::playmode (412)
00:04:20:12:1a:99 New play mode: pause
[08-08-02 18:52:10.0328] Slim::Player::Source::playmode (581)
00:04:20:12:1a:99: Current playmode: pause

The pause is followed by an attempt to refill the decoder buffer from
scratch

[08-08-02 18:52:11.0736] Slim::Player::Source::rebuffer (900)
Rebuffering: 65873 / 120000
[08-08-02 18:52:12.1164] Slim::Player::Source::rebuffer (900)
Rebuffering: 71681 / 120000
[08-08-02 18:52:13.1291] Slim::Player::Source::rebuffer (900)
Rebuffering: 100721 / 120000
[08-08-02 18:52:14.1425] Slim::Player::Source::rebuffer (900)
Rebuffering: 150089 / 120000

When the decoder buffer is deemed sufficiently full, the player
attempts to resume

[08-08-02 18:52:14.1499] Slim::Player::Source::playmode (309)
00:04:20:12:1a:99: Switching to mode play from pause
[08-08-02 18:52:14.1510] Slim::Player::Source::playmode (412)
00:04:20:12:1a:99 New play mode: resume
[08-08-02 18:52:14.1522] Slim::Player::Source::playmode (430)
00:04:20:12:1a:99: Resume, resetting mode: playout-play
[08-08-02 18:52:14.1551] Slim::Player::Source::playmode (581)
00:04:20:12:1a:99: Current playmode: resume

Only to encounter output buffer underrun again:

[08-08-02 18:52:16.1253] Slim::Player::Source::outputUnderrun (800)
00:04:20:12:1a:99: Output buffer underrun (decoder: 79297 / output: 0)

It should be noted that the decoder buffer has gone from 150089 to
79297 when the output buffer underrun occurs.
***This suggests that the audio decoding has consumed some bytes out of
the decoder buffer but failed to produce audio data into the output
buffer.***

This outputUnderrun/Pause/Rebuffering/Resume continues in a loop for
approx 2 minutes every 1 to 15 seconds, depending how long it takes to
refill the decoder buffer with 120000 bytes.

Finally the decode buffer is cleared spontaneously:

[08-08-02 18:54:28.3968] Slim::Player::Source::playmode (461)
00:04:20:12:1a:99: Stopping and clearing out old chunks

Loud consecutive popping sounds start at the first output buffer
underrun at 18:52:10 and end at 18:54:28, while the display alternates
between "rebuffering" messages and "now playing".

The player resumed normally to next track on its own.


-- 
y360
------------------------------------------------------------------------
y360's Profile: http://forums.slimdevices.com/member.php?userid=10150
View this thread: http://forums.slimdevices.com/showthread.php?t=50509

_______________________________________________
squeezenetwork mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/squeezenetwork

Reply via email to