[xine-bugs] [ xine-Bugs-842244 ] choppy real audio playback

[SourceForge.net <no...@so...>]

Bugs item #842244, was opened at 2003-11-14 09:03
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109655&aid=842244&group_id=9655

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: xine
Group: v1-rc2
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Oliver (mavit)
Assigned to: James Stembridge (jstembridge)
Summary: choppy real audio playback

Initial Comment:
When listening to
"http://www.bbc.co.uk/6music/ram/dsatg2.ram", the audio
sometimes becomes "jerky".  I shall attept to describe
what I hear.  It's still possible to tell that, say,
the same person is speaking, or the same record is
playing, but it's covered with skipping sounds, and you
can't tell what is being said.  It sounds as if,
perhaps, a buffer is only getting part-filled and some
of its old contents is getting played back interspersed
with the new.

Stopping playback and restarting it will often fix the
problem, although often it will soon come back.

Realplayer doesn't suffer the problem, although its
quality light tends to be red at the times when xine
suffers.

This happens with both the xine UI and totem.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2005-11-16 04:03

Message:
Logged In: NO 

I experience the same problem when listening to BBC streams with the cook codec.
For example http://www.bbc.co.uk/6music/ram/dsatg2.rpm



Mplayer has exactly the same problem on the same streams, but Real player does not (using the same codec)

There is a thread on the problem here
http://forums.slimdevices.com/showthread.php?t=14543 and 
http://forums.slimdevices.com/showthread.php?t=16917&page=9

the guys at slimdevices have worked out a patch that fixes mplayer in the attachment at
http://forums.slimdevices.com/showthread.php?t=16917&page=10


The problem with mplayer was described as
"The problem was a coding error where not enough packets were inserted when timegaps were multiples of block size such as 3712, 5568, 7424"

Hopefully that will give a clue to the problem with Xine


----------------------------------------------------------------------

Comment By: Dave Stark (ilikejam)
Date: 2005-10-16 17:15

Message:
Logged In: YES 
user_id=1024685

This bug also surfaces with the 'Radio 1' stream at:
http://www.bbc.co.uk/radio1/realaudio/media/r1live.ram
with xine-lib from CVS.

MPlayer also suffers from this (also from CVS).

----------------------------------------------------------------------

Comment By: James Stembridge (jstembridge)
Date: 2004-05-27 15:43

Message:
Logged In: YES 
user_id=537148

No, this bug will only manifest itself when packets are 
dropped, which causes the decoder state to get corrupted. 
To fix we need to keep track of the packet sequence and 
wait for the next keyframe if a packet is dropped. I do know 
roughly how to do this btw. 

----------------------------------------------------------------------

Comment By: Miguel Freitas (miguelfreitas)
Date: 2004-05-27 14:44

Message:
Logged In: YES 
user_id=148691

seems to be working fine here (xine cvs)
may i close this bug?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109655&aid=842244&group_id=9655