I've done a bit of experimenting to understand this issues and the following is a summary of what I have found out. This is a long winded post but I feel it is better to explain as best I can as others may be able to offer suggestions.
1. WHAT DOES THE MPLAYER BANDWIDTH OPTION DO The bandwidth option is Mplayer's implementation of RealPlayer's Turboplay. It is designed to minimise the delay at startup of audio/video. Normally (i.e. no bandwidth option) data is sent to Mplayer at real time speed so there is a delay at the start while Mplayer waits for its cache buffer to fill before starting to play. This delay with Mplayer for "Listen Again" and 128K cache is about 10-15 secs. When the player tells the BBC server that it wishes to use a specific "bandwidth" value - then the BBC server will send data down in a burst to fill the player's buffers quickly and not at the real time rate. It seems that only the TCP connections limits the transfer of data when the Receive window becomes full. I don't know how the BBC server interprets/uses the value of the bandwidth option 2. WHY IS THERE STUTTERING / JERKY VISUALISATIONS AND SB BUFFER IS NOT FULL WHEN BANDWIDTH OPTION IS NOT SPECIFIED. I think the jerkiness is a bug associated with Flac format - I have seen this bug and changed format to WAV and the problem went away. The following is what I think happens. When bandwidth option is not specified, data is sent in real time from the BBC server and so only about 128kbytes are cached by Mplayer - this will effectively be transferred in Flac format to the SB so this will be the small amount of data in SB buffer while playing. As music is played the BBC server will top up in real time and so the level never changes. When bandwidth is specified, then the BBC server sends as much data as possible so a large burst of data will be sent to the SB until the SB's buffer is full - again as music is played BBC server will top it up. I've seen the BBC send at least at least a 1Mbyte of RealAudio - I don't what that is in Flac which is what will be stored in SB. The stuttering and jerky visualisation seems to be associated to when FLAC data is being received by the SB. When bandwidth is not specified - data in sent in small burst about once per second and so the display with stop/start about once per sec. Whereas when bandwidth is specified, a large amount of data is sent at once and SB buffer is filled - so display will be steady for long periods of time as data will not be sent until SB buffer get empty. 3. WHAT IS HAPPENING WHEN \"LISTEN AGAIN\" FAILS. The symptom is non-live RealAudio streams (e.g. BBC Listen Again, NPR programs) stop when playing for no reason typically sometime between 2min and 20 mins after starting. It is reproducible and can be reproduced with standalone Mplayer. On Windows the log will show Mplayer error messages something like rdt chunk not recognized: got 0x53 rdt chunk not recognized: got 0x4d The trigger is the combination of the use of the Mplayer Bandwidth option and tweaking TCP Receive Window to optimise internet connections. In Windows this can be done by an explicit change to the Registry or more often through some sort of utility (e.g. TCPoptimiser). In Linux it is through a change to parameters in /proc/sys/net/core. The Bandwidth option on started being used by AlienBBC since implementation in Mplayer in Jan 2006 and so from AlienBBC 1.02 onwards (I think). So Windows user who tweaked their TCP setting before Jan 2006 would not have seen this problem with AlienBBC. Without the bandwidth option, data is sent in real time so about 16-50k/sec depending on the stream. With bandwidth option specified, it looks like the data is mainly limited by TCP Receive Window. With one test I managed to get 1Mbytes of the PM program in less than 5 secs. Once the TCP receive window is full no more data will be sent until it is ACKed. In TCP, data will not be acknowledge until read by the application. In file transfer 1Mbyte will be acked as soon as saved onto disk but since this data is being played back as Audio this delay can be minutes. As a result TCP server polls Mplayer to see if it is ok with a TCP ZeroWindowPoll and PC acks the ZeroWindow polls and all is OK. This happens a number of times, and as data is processed, more burst of data are sent and ZeroWindows polls are sent. However at some point after a number of these pauses, data seems seems to be "lost" although it is not clear how this happens. Mplayer detects the loss as the RDT protocol error and closes the link to BBC server. Since this problem has been seen on Windows and Linux - it looks like an Mplayer issue. I think Mplayer implementation of Turboplay may be faulty (e.g. it doesn't throttle back after startup). To fix it would require time to investigate and compare against RealPlayer behaviour. As I can get it to happen standalone after 3 mins of operation, I may report the bug to Mplayer team but they are slow on RealAudio bugs (see "Garbled Audio") especially as this involves non-standard Windows/Linux config settings and doesn't affect many users. So the solution at the moment is either remove the Bandwidth option from Slimserver-convert.conf or change back to standard TCP settings. -- bpa ------------------------------------------------------------------------ bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=25553 _______________________________________________ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/plugins
