[MPlayer-users] Re: BUG - Garbled output playing realaudio

[Bryan Alton]

The garbled audio problem is caused by packets being dropped.  However after
more testing both in time and by more users, the nature of the problem is
clearer and below are my impressions:

1. Frequently one or two packets dropped, sometimes 5 or 6. This behaviour
   occurs throughout the day.
2. Occasionally blocks of packets of around 30-40 packets are dropped - this
   happens at peak hours.
3  Very occasionally long gaps of 250-300 packets this seems to be network
   related and occur less than once a day.

My first patch assumed that if packets were dropped that it would be less
than 16 at a time. If more than 16 packets were dropped my patch ignored it
and this resulted in garbled audio as if the patch didn't work.

I suggest the following behaviour for a new patch.

For type 1. (typical duration 100-500 msec) my patch will replace the
missing packets with past sound samples - this will minimise glitches.

For type 2. (typical duration 4-5 secs) my patch will replace missing
packets with silence.  There will be some garbling at start and end. 
Alternative is to replace with a sound sample - this gives a reverb sounds
which could be annoying but listeners will know the connections is still
live.

For type 3. (typical duration 10-40 secs) my patch will replace missing
packets with silence.  However it is likely that cache will be exhausted 
before stream restarts and if so then Mplayer will never recover resulting
in choppy audio alternating sound and silence.  My patch will shut Mplayer
down if cache fill Percentage goes to zero.

Will this behaviour be reasonable especially for those applications where
Mplayer feeds into another streaming application such as AlienBBC.

Bryan