The results when using "Test mplayer.bat" for standalone tests are not valid because the "bandwidth 100000000" option is used.
The fact that your modem link is above 40kbits/sec seems to confirm my belief that the encoding doesn't change - just the buffering and transmission parameters. I think you should do some standalone test - using mplayer command in a command prompt window. Example URLS to use in test: Radio 1 live http://www.bbc.co.uk/radio1/realaudio/media/r1live.rpm The Archers Listen Again http://www.bbc.co.uk/radio/aod/shows/rpms/radio4/archers.rpm A typical command line to use when testing - you should try different settings for cache, cache-min and bandwidth. Code: -------------------- mplayer -vc null -vo null -bandwidth 48000 -cache 128 -cache-min 50 -af volume=0,resample=44100:0:1,channels=2 -playlist http://www.bbc.co.uk/radio/aod/shows/rpms/radio4/archers.rpm -------------------- The following are the effects of the parameters *cache* - this is essentially buffer size. It gives mplayer time to smooth out data streams if the data does not arrive evenly but in bursts. For BBC streams 128kytes is good enough holding about 25 secs of playing time. If the audio streams from BBC has pauses longer than about 10 secs - then you will need to increase the cache size. You will also need to pay attention to cache-min. *cache-min* - The minimum percentage fullness of the cache before the stream is actually played by mplayer. By default it is about 18%. This means a cache of 128kbytes with a threshold of 18% - really only has buffered about 4.5 seconds of audio. One packet lost on a slow link and the buffer will be depleted. On slow or unreliable link increase this to 50-60% to make sure the cache is really used. *bandwidth* - this tell the BBC servers the effective "datarate" of the link. It essentially implements the RealPlayer "Turboplay". With broadband a large number such as 10Mbps means "listen again" programs are sent to mplayer as fast as possible. However a large number can give problem with RWIN and TCP packet timeout and link reset. Too small a number and data is held back. For the dialup links try values probably around 48000 and 64000. When doing a test - look at the last line of maplyer output Code: -------------------- A: 66.8 (01:06.7) of 901.0 (15:01.0) 1.2% 35% -------------------- The "35%" figure is the fulness of the cache. If it slowly goes down then cache ie bing emptied slowly so data is not being sent to mplayer fast enough for some reason. If the cache fullness drops slowly and then gets replenished - then you have an uneven network feed and so need to increase cache and cache-min to even out the troughs. -- bpa ------------------------------------------------------------------------ bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=41023 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/plugins
