1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Issues with shoutcast streams on a WRT

Discussion in 'Networking Issues' started by Xelgadis, Sep 5, 2006.

  1. Xelgadis

    Xelgadis LI Guru Member

    I've searched all over different forums for clues on how to solve this issue I'm having, with no luck so far. Basically, I've been having some problems with listening to shoutcast streams since I picked up my WRT54GL a week or two ago. I can do everything else without any problems.

    Basically, when I listen to a shoutcast stream on port 80 the latency on the br0 (internal bridged lan) device goes skyward to around 1000ms with some 2000ms spikes. This is on a 6mbps/384kbps link, and it works perfectly fine connected straight to the cable modem as well as on the previous router I was using. The even stranger thing is that if I listen to a shoutcast stream on any other port (8000, etc) the issue doesn't occur (the latency stays around 70-98ms). I've tried 3 different firmwares aside from the factory default, resetting the nvram countless times, overclocking the cpu to 216mhz, and nothing seems to help. I'm currently running OpenWRT WhiteRussian RC5, but I was using Thibor15c before that with similar problems.

    At this point I've considered undoing the br0 device, and just using the vlan0/vlan1/eth1 devices in static routes to see if that helps the problem. Before I do that I want to see if anyone has any suggestions as to how to fix it.
     
  2. Guyfromhe

    Guyfromhe Network Guru Member

    Do you have any access restrictions set? If you have any type of keyword filtering it will have to check that whole datastream as it's comming through and that could put the CPU through the roof...
    Did you check load avgs when this is happening?
     
  3. Xelgadis

    Xelgadis LI Guru Member

    No access filters set, and I switched back to 4.30.7 default linksys firmware. Still happening. The load averages are pretty nominal, anywhere between 0.3/0.4/0.3 to 0.22/0.14/0.10. I noticed that it doesn't only do it on port 80 but on specific streams. The port doesn't seem to make much difference, but it only occurs with shoutcast that I can tell.

    After doing some more investigating it almost seems like the router is getting packet headers that it doesn't know how to handle. This seems to cause it to "chew" on the packet taking up driver time. I'm working on collecting some ethereal caps from inside the network to see what the packets look like. I'll probably connect through my cable modem to see if I can get a clean captured packet to compare that to.

    edit#1: Oh, and I should probably clarify that the high latencies only occur on the internal vlan0, not the wireless lan, and not the outgoing (WAN) interface. I can ping from the router to an internal machine, and the latency goes crazy. If I attempt to ping out from the router the latency stays within 60-80ms.

    I'm totally stumped as to what could be causing this sort of behavior.

    (edit#2: I moved the solution to the above bug into a reply for readability.)
     
  4. Guyfromhe

    Guyfromhe Network Guru Member

    very weird... could be some kind of firmware bug... dunno...
     
  5. Xelgadis

    Xelgadis LI Guru Member

    I figured out what was causing it. The buffering was set too low in Winamp. By default it gets set to 64kb, and this causes what I call the "loop buffer bug" with my WRT54GL. The result of raising the buffering from the default of 64kb to anything higher is a proportional decrease in LAN latency. This bug does -not- affect the wireless clients for some reason. The solution is simple: raise the buffer from the default to 128kb. Fixed!

    Hope the above helps anyone who might be having a similar problem.
     
  6. Guyfromhe

    Guyfromhe Network Guru Member

    Thanks for posting to solution, good to hear you got it working.
     
  7. Xelgadis

    Xelgadis LI Guru Member

    Well, it seems as though the test case doesn't just apply to mp3/aac streams. I've found with some more thorough testing that it also applies to nsv, rts/udp, and mms streams (streaming video basically) if the buffer on the client is too small. I've found that typically playing with the buffer a bit also fixes the issues for those applications as well.
     

Share This Page