View Full Version : AlienBBC very choppy
I'm having problems with AlienBBC streams sounding very choppy. Going fine for some minutes then a period of breakup then ok again, and so on.
I never used to have this problem, but there have been many changes in my sytem (new computer better than the old one, newer version of Mac OS X, newer AlienBBC, newer SlimServer) so that doesn't mean much. I'm using SlimServer 6.1.1.
It doesn't seem to be the problem reported about streams being garbled, there's no garbling, just playing for a second or two, stopping for a second or two, playing for a second or two, stopping, and so on until it recovers.
It's not surprising that this happens, as the buffer fullness drops to 0% or 1% and continues like that until it climbs to a sensible figure again (around 50% to 60% seems the best it can do).
Any idea where the problem can lie, and on what useful debugging I can do or further information I can give. Obviously when I have a bit of time I will run mplayer from the command line and see if there are still problems.
Could you post the output of --d_source when playing a stream?
Also the output of --d_http when playing would be useful.
I'll see what I get with those debugging switches.
But I've just realised a possible cause. I hadn't realised that I had the Web access open. I think that sometimes causes problems, with regular refreshing of pages taking priority over other things. Will see what happens when I turn it off.
I've run SlimServer in the normal way (not from the command line) with d_source and d_http turned on.
Here's a part of the log. I could give you the whole log if you want. It shows something wrong, but doesn't indicate why it is going wrong. Maybe some more debug switches need to be turned on.
2005-09-11 07:55:34.7128 sendstreaming response begun...
2005-09-11 07:55:34.7149 (audio: 4096 bytes)
2005-09-11 07:55:34.7156 sent incomplete chunk, requeuing 232 bytes
2005-09-11 07:55:34.7159 Streamed 3864 to 192.168.1.11
2005-09-11 07:55:34.7280 sendstreaming response begun...
2005-09-11 07:55:34.7290 Streamed 232 to 192.168.1.11
2005-09-11 07:55:34.7299 sendstreaming response begun...
2005-09-11 07:55:34.7325 (audio: 4096 bytes)
2005-09-11 07:55:34.7332 sent incomplete chunk, requeuing 1408 bytes
2005-09-11 07:55:34.7336 Streamed 2688 to 192.168.1.11
2005-09-11 07:55:34.7524 sendstreaming response begun...
2005-09-11 07:55:34.7532 Streamed 1408 to 192.168.1.11
2005-09-11 07:55:34.7595 sendstreaming response begun...
2005-09-11 07:55:34.7614 (audio: 4096 bytes)
2005-09-11 07:55:34.7622 Streamed 4096 to 192.168.1.11
2005-09-11 07:55:34.7716 sendstreaming response begun...
2005-09-11 07:55:34.7785 (audio: 4096 bytes)
2005-09-11 07:55:34.7793 Streamed 4096 to 192.168.1.11
2005-09-11 07:55:34.7804 sendstreaming response begun...
2005-09-11 07:55:34.7823 (audio: 4096 bytes)
2005-09-11 07:55:34.7830 sent incomplete chunk, requeuing 2016 bytes
2005-09-11 07:55:34.7833 Streamed 2080 to 192.168.1.11
2005-09-11 07:55:34.7869 sendstreaming response begun...
2005-09-11 07:55:34.7876 Streamed 2016 to 192.168.1.11
2005-09-11 07:55:34.7914 sendstreaming response begun...
2005-09-11 07:55:34.7936 (audio: 4096 bytes)
2005-09-11 07:55:34.7943 sent incomplete chunk, requeuing 272 bytes
2005-09-11 07:55:34.7947 Streamed 3824 to 192.168.1.11
2005-09-11 07:55:34.8217 sendstreaming response begun...
2005-09-11 07:55:34.8226 Streamed 272 to 192.168.1.11
2005-09-11 07:55:34.8234 sendstreaming response begun...
2005-09-11 07:55:34.8261 (audio: 4096 bytes)
2005-09-11 07:55:34.8268 Streamed 4096 to 192.168.1.11
2005-09-11 07:55:34.8372 sendstreaming response begun...
2005-09-11 07:55:34.8390 (audio: 4096 bytes)
2005-09-11 07:55:34.8397 Streamed 4096 to 192.168.1.11
2005-09-11 07:55:34.8408 sendstreaming response begun...
2005-09-11 07:55:34.8429 (audio: 4096 bytes)
2005-09-11 07:55:34.8436 sent incomplete chunk, requeuing 880 bytes
2005-09-11 07:55:34.8454 Streamed 3216 to 192.168.1.11
2005-09-11 07:55:34.8510 sendstreaming response begun...
2005-09-11 07:55:34.8519 Streamed 880 to 192.168.1.11
2005-09-11 07:55:34.8546 sendstreaming response begun...
2005-09-11 07:55:34.8556 (audio: 4096 bytes)
2005-09-11 07:55:34.8564 Streamed 4096 to 192.168.1.11
2005-09-11 07:55:34.8677 sendstreaming response begun...
2005-09-11 07:55:34.8689 (audio: 4096 bytes)
2005-09-11 07:55:34.8695 sent incomplete chunk, requeuing 312 bytes
2005-09-11 07:55:34.8699 Streamed 3784 to 192.168.1.11
2005-09-11 07:55:34.8721 sendstreaming response begun...
2005-09-11 07:55:34.8731 Streamed 312 to 192.168.1.11
2005-09-11 07:55:34.8739 sendstreaming response begun...
2005-09-11 07:55:34.8749 (audio: 4096 bytes)
2005-09-11 07:55:34.8755 sent incomplete chunk, requeuing 1488 bytes
2005-09-11 07:55:34.8758 Streamed 2608 to 192.168.1.11
2005-09-11 07:55:34.9024 sendstreaming response begun...
2005-09-11 07:55:34.9033 Streamed 1488 to 192.168.1.11
2005-09-11 07:55:34.9235 sendstreaming response begun...
2005-09-11 07:55:34.9248 (audio: 4096 bytes)
2005-09-11 07:55:34.9254 Streamed 4096 to 192.168.1.11
2005-09-11 07:55:34.9262 sendstreaming response begun...
2005-09-11 07:55:34.9276 Nothing to stream, let's wait for 0.05 seconds...
2005-09-11 07:55:34.9285 Got nothing for streaming data to 192.168.1.11
2005-09-11 07:55:34.9790 sendstreaming response begun...
2005-09-11 07:55:34.9845 (audio: 4096 bytes)
2005-09-11 07:55:34.9852 Streamed 4096 to 192.168.1.11
2005-09-11 07:55:34.9863 sendstreaming response begun...
2005-09-11 07:55:34.9872 Nothing to stream, let's wait for 0.05 seconds...
2005-09-11 07:55:34.9877 Got nothing for streaming data to 192.168.1.11
2005-09-11 07:55:35.0385 sendstreaming response begun...
2005-09-11 07:55:35.0396 (audio: 4096 bytes)
2005-09-11 07:55:35.0404 Streamed 4096 to 192.168.1.11
2005-09-11 07:55:35.0414 sendstreaming response begun...
2005-09-11 07:55:35.0423 Nothing to stream, let's wait for 0.05 seconds...
2005-09-11 07:55:35.0430 Got nothing for streaming data to 192.168.1.11
2005-09-11 07:55:35.0937 sendstreaming response begun...
2005-09-11 07:55:35.1001 (audio: 4096 bytes)
2005-09-11 07:55:35.1012 Streamed 4096 to 192.168.1.11
2005-09-11 07:55:35.1022 sendstreaming response begun...
2005-09-11 07:55:35.1031 Nothing to stream, let's wait for 0.05 seconds...
2005-09-11 07:55:35.1036 Got nothing for streaming data to 192.168.1.11
2005-09-11 07:55:35.1566 sendstreaming response begun...
2005-09-11 07:55:35.1577 (audio: 4096 bytes)
2005-09-11 07:55:35.1585 Streamed 4096 to 192.168.1.11
2005-09-11 07:55:35.1596 sendstreaming response begun...
2005-09-11 07:55:35.1607 Nothing to stream, let's wait for 0.05 seconds...
2005-09-11 07:55:35.1615 Got nothing for streaming data to 192.168.1.11
2005-09-11 07:55:35.2120 sendstreaming response begun...
2005-09-11 07:55:35.2132 (audio: 4096 bytes)
2005-09-11 07:55:35.2138 Streamed 4096 to 192.168.1.11
2005-09-11 07:55:35.2146 sendstreaming response begun...
2005-09-11 07:55:35.2157 Nothing to stream, let's wait for 0.05 seconds...
2005-09-11 07:55:35.2165 Got nothing for streaming data to 192.168.1.11
2005-09-11 07:55:35.2672 sendstreaming response begun...
2005-09-11 07:55:35.2683 (audio: 4096 bytes)
2005-09-11 07:55:35.2689 Streamed 4096 to 192.168.1.11
2005-09-11 07:55:35.2697 sendstreaming response begun...
2005-09-11 07:55:35.2705 Nothing to stream, let's wait for 0.05 seconds...
2005-09-11 07:55:35.2711 Got nothing for streaming data to 192.168.1.11
2005-09-11 07:55:35.3218 sendstreaming response begun...
2005-09-11 07:55:35.3230 (audio: 4096 bytes)
2005-09-11 07:55:35.3237 Streamed 4096 to 192.168.1.11
2005-09-11 07:55:35.3245 sendstreaming response begun...
2005-09-11 07:55:35.3254 Nothing to stream, let's wait for 0.05 seconds...
2005-09-11 07:55:35.3260 Got nothing for streaming data to 192.168.1.11
2005-09-11 07:55:35.3865 sendstreaming response begun...
2005-09-11 07:55:35.3877 (audio: 4096 bytes)
2005-09-11 07:55:35.3884 Streamed 4096 to 192.168.1.11
2005-09-11 07:55:35.3892 sendstreaming response begun...
2005-09-11 07:55:35.3900 Nothing to stream, let's wait for 0.05 seconds...
2005-09-11 07:55:35.3905 Got nothing for streaming data to 192.168.1.11
2005-09-11 07:55:35.4413 sendstreaming response begun...
2005-09-11 07:55:35.4425 (audio: 4096 bytes)
2005-09-11 07:55:35.4432 Streamed 4096 to 192.168.1.11
2005-09-11 07:55:35.4440 sendstreaming response begun...
2005-09-11 07:55:35.4450 Nothing to stream, let's wait for 0.05 seconds...
2005-09-11 07:55:35.4456 Got nothing for streaming data to 192.168.1.11
2005-09-11 07:55:35.4965 sendstreaming response begun...
2005-09-11 07:55:35.4976 (audio: 4096 bytes)
2005-09-11 07:55:35.4984 Streamed 4096 to 192.168.1.11
2005-09-11 07:55:35.4992 sendstreaming response begun...
2005-09-11 07:55:35.5001 Nothing to stream, let's wait for 0.05 seconds...
2005-09-11 07:55:35.5009 Got nothing for streaming data to 192.168.1.11
2005-09-11 07:55:35.5516 sendstreaming response begun...
2005-09-11 07:55:35.5532 (audio: 4096 bytes)
2005-09-11 07:55:35.5539 Streamed 4096 to 192.168.1.11
2005-09-11 07:55:35.5547 sendstreaming response begun...
2005-09-11 07:55:35.5556 Nothing to stream, let's wait for 0.05 seconds...
2005-09-11 07:55:35.5562 Got nothing for streaming data to 192.168.1.11
2005-09-11 07:55:35.6072 sendstreaming response begun...
2005-09-11 07:55:35.6107 (audio: 4096 bytes)
2005-09-11 07:55:35.6119 Streamed 4096 to 192.168.1.11
2005-09-11 07:55:35.6192 sendstreaming response begun...
2005-09-11 07:55:35.6221 (audio: 4096 bytes)
2005-09-11 07:55:35.6231 Streamed 4096 to 192.168.1.11
2005-09-11 07:55:35.6248 sendstreaming response begun...
2005-09-11 07:55:35.6284 (audio: 4096 bytes)
2005-09-11 07:55:35.6293 Streamed 4096 to 192.168.1.11
Are you trying to stream as flc or wav on 6.1? If so it looks like OSX has the same problem that linux 2.4 has - we put a fix in 6.2 but not 6.1.
Could you either try streaming as mp3 rather than flc or wav, moving to 6.2 or changing RETRY_TIME in server/Slim/Web/HTTP.pm to 0.02 rather than 0.05
(see: http://forums.slimdevices.com/showthread.php?t=15194&highlight=4096)
Are you trying to stream as flc or wav on 6.1? If so it looks like OSX has the same problem that linux 2.4 has - we put a fix in 6.2 but not 6.1.
Could you either try streaming as mp3 rather than flc or wav, moving to 6.2 or changing RETRY_TIME in server/Slim/Web/HTTP.pm to 0.02 rather than 0.05
(see: http://forums.slimdevices.com/showthread.php?t=15194&highlight=4096)
As was discussed in a thread in the general forum, how do I make sure what format the stream is in? And how do I change toforce streaming as mp3? I am just using the default convert.conf and slimserver-convert.conf, as supplied with SlimServer and AlienBBC.
Quite possibly the same problem as with linux, as OS X has a Unix underpinning.
I don't think I'll try 6.2, I'm not inclined to go with betas. Did the problem begin with 6? Certainly I never had it in SlimServer 5.
I'll change the RETRY_TIME and see what happens
It shouldn't have changed between 5.x and 6.1 but is very dependant on the order the OS is scheduling tasks and hence an obscure problem.
If you deselect rtsp->wav and rtsp->flc leaving rtsp->mp3 this will force streaming as mp3 [in which case this problem should not exist - does this work?]
Changing the RETRY_TIME seems to have very much improved the situation. I'm not sure that it has solved it completely (I have been listening in the background, so not noticing so much - and there was a complete stop at one point, which may have been due to a cordless phone, though I thought UK phones did not have that issue), but it seems pretty OK.
I can say again that changing the RETRY_TIME vastly improves the situation.
However, something odd is going on (just possibly slow BBC streaming) as the buffer is frequently on 0% (but still playing ok) and rarely above 10%.
I think I'll try disabling the wav and flac settings and see what happens.
On SB2 I think this is always going to be true as the buffer is big and the stream seems to be rate limited to be ~realtime so there is no way to get a large burst into the SB2.
6.2 contains automatic adjustment of RETRY_TIME so if/when you move to this it should cover it.
Yes, I did wonder about that. And, of course, a buffer fullness of 0% probably just means less than 1%, so it can still be adequate.
Disabling flac and wav, and running as mp3 only, did not improve the situation. But I think the lower RETRY_TIME is good enough.
Would there be any reason not to reduce this further, to 0.01?
0.01 will just lead to slightly higher CPU loading. 0.02 is theoretically the right value - but let me know how you get on.
I have same problem (Choppy AlienBBC after a minute or 2)
Fedora C3
SlimServer Version: 6.2b1 - 4241
AlienBBC V0.98
Tried reducing RETRY_TIME to 0.01
Still bad
6.2 contains some code to automatically reduce this to 0.02 for the problem case so I suspect the problem is elsewhere.
What does it sounds like if you play the stream direct with mplayer?
I'm afraid my Linux box is in a rack and is not set up for audio. Is there anything else I can try?
Try dissabling rtsp->flc and rtsp->wav so that it always streams as mp3 - if this doesn't work then the problem is probably at the mplayer end [assuming you have lame installed OK]
Rhere may be a mix of things going on. I've tried disabling tsp to wav and rtsp to flac, but it hasn't helped. I've still had fits and starts, culminating in a stop of the program I was listening to.
At the moment there are six (count them, six) copies of mplayer running. Three of them use around 650Kb while the other three, named as mplayer (not responding) show 15Mb real memory.
But what I noticed during the ups and downs this time (which may have occurred before without my noticing, or may have happened before but for so short a time that it did not register on the screen) was a number of messages aying "lost contact with SlimServer..." Until the stream finally stopped, it just recovered from these messages without any action by me, and just with a stutter or two.
I'll try listening to some things from my hard drive, to see if this problem occurs there.
As remarked, this is all new, it used to work fine, but heaven knows which change has caused the problem.
Well, recording the program to hard drive and then playing it worked fine, as I expected.
I'm tpmted to believe that what is happening is that some process, probably one of the copies of mplayer, is grabbing all the CPU for very short periods, and that this is causing the choppiness and the occasional loss of connection to SlimServer.
But I don't know how I could check this.
RichardGi
2005-09-13, 18:06
Voting for "bug" 296 to natively support real audio might (eventually) fix this problem....
R
Upgraded to mplayer 4:1.0pre8-0.20050820.1, no change
Tried disabling rtsp->flc and rtsp->wav, no change.
.....
You could try changing the "-cache 128" to a larger number as this should mean mplayer does more buffering
Danco - as for the mac - there is definately something wrong here with mplayer copies remaining - this only seems to have started with the latest OSX. I'm afraid that without access to OSX we can't really help diagnose other than asking you to instrument mplayer.sh and letting us know what is going on...
Milhouse
2005-09-14, 11:32
Voting for "bug" 296 to natively support real audio might (eventually) fix this problem....
R
Bug 296 (http://bugs.slimdevices.com/show_bug.cgi?id=296) just got one more vote... up to 10 votes now! :)
296 just got one more vote... up to 10 votes now! :)
That was me ...
I have tried changing "-cache 128" to various values up to 1024 without improvement.
NB the "choppy" output sounds like it's all there but it's being broken up into ~0.3 sec chunks which then come out in the wrong order.
You could try changing the "-cache 128" to a larger number as this should mean mplayer does more buffering
Danco - as for the mac - there is definately something wrong here with mplayer copies remaining - this only seems to have started with the latest OSX. I'm afraid that without access to OSX we can't really help diagnose other than asking you to instrument mplayer.sh and letting us know what is going on...
Sorry, what do you mean by "instrument mplayer.sh"? I'll be happy to try things, but I need guidance as to what to change and what to log.
I'm fairly certain that when I play a "listen again" program and it plays to the end, then the two copies of mplayer (and I think you said that there are supposed to be two copies) then close down.
They stay around, though, if one stops the program before its end (which I often do as the Listen Again may continue past the actual end of the program), or if the dropouts finally lead to the stream stopping.
Unlike bilko2, when I get the choppiness the chunks still seem to come
out in the right order. I see that changing the cache number didn't help him.
I wish I could remember exactly when I started having this problem. It certainly is comparatively new.
I would try a newer version of mplayer if I knew what version of the cook codec is the right one, and where to find it.
As I mentioned elsewhere, I strongly suspect that the issue is some process (perhaps even a copy of mplayer) taking up all the CPU for a brief moment.
Is there any effective way of checking this, either with the Mac's GUI or from the terminal. Using Activity Monitor only gives the CPU usage at 0.5 second intervals, which may be too long.
I've now had some goodlistening with no choppiness.
That makes me pretty sure of the basic cause, though not of the specifics. I keep a lot of programs open, but hidden. They aren't doing anything specific, they are open because I used them not so long ago and expect to use them again shortly, so why bother to close them. I would guess that some program (Internet Explorer, Microsoft Word or whatever) is doing something like refreshing a window behind the scenes, or something else, even though I'm not asking it to do anything, and that this is taking up so much CPU for a small portion of time that it is enough to upset the transmission of AlienBBC, or upsets lame or one of the components
Can't comment on the cpu load thing as I've not familar with macs and so other than typing ps & top (unix commands) I'm sure what to suggest!
As for mplayer - I think you should see two mplayers and two mplayer.sh processes during playback. If the stream ends or you press stop all should die or be killed off. If this is not happening then we need to understand why.
Well, after several bits of good listening I ran into the problem again. I tried closing some programs to get back to the situation that worked, but it still weny badly.
I know about ps and top in general, but don't know the exact syntax. What I would like - is it possible? - is a way of listing only the mplayer processes and of listing the maximum CPU used rather than having to watch the lines to see what is happening. Using the Mac's Activity Monitor (which I think is just a GUI to top) and watching it closely I think I noticed a brief flash of mplayer using 60% or more of the CPU. But I don't know if this was one of the copies that should not have been there.
I'm up now to eighteen copies of mplayer alive (though not necessarily doing anything) as a result of the stream stopping and restarting.
I'll gladly test this for you, but I need to know how to test. If a modified mplayer.sh is needed, perhaps you can supply it for me, together with instructions about what to log.
I don't think I've ever seen an mplayer.sh process listed in Activity Monitor. Perhaps it just comes in under a different name (as one of the threads in perl or something similar, perhaps).
Powered by vBulletin® Version 4.1.12 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.