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

Tomato ConnTrack Settings for ShoutCast

Discussion in 'Tomato Firmware' started by eangulus, Apr 8, 2014.

  1. eangulus

    eangulus Network Guru Member

    Hi,

    Running RT-AC66U in a Community Radio Station.

    Have 800k upload on ADLS2+.

    Have QoS giving streaming server priority and enough bandwidth (nearly full access). Nothing else running in station.

    But listening to the stream from external site, doesn't seem to buffer (as in pause then start playing again), its more of a skip, like a minor scratch in a CD or something.

    Just wondering if there are any special settings to look at under ConnTrack (or anywhere else) that may cause situations like this.
     
  2. koitsu

    koitsu Network Guru Member

    If there's no indication in the playback software of buffering or network socket anomalies, and what you hear is a skip or some kind of garbled audio, then chances are it's the encoding software or encoding codec doing something bad.

    You might try setting up a listener locally, i.e. streaming from http://lan.ip.of.your.rtac66u:someport/whatever.m3u from a machine on your LAN (I hope you're doing all of this over Ethernet and not wireless else all bets are off!) (do NOT access the WAN IP of your router from the LAN!), and save/record the stream to a file for later listening. Then go back and listen to it to see if you can reproduce the issue. If so, then the issue isn't with any part of the IP stack but rather on the client-side OR the server-side (meaning the streaming server).

    I'm not sure consumer routers are good places to be running streaming servers from. Streaming servers are *extremely* CPU intensive depending on what software is being used. If you think I'm kidding, I'm not. Short story:

    Over a decade ago I used to run the west coast 56kbps relay server for Digitally Imported (I did so for free / got no kickbacks from Ari (by my own request); I quit/shut things down when he started talking about putting ads into the stream (which are now heavily prevalent -- I'm very anti-advertising)). Anyway, most of the relays ran Linux with Shoutcast sc_serv, while I ran FreeBSD + Shoutcast sc_serv. I saw CPU on a dual-core box reach way, WAY higher loads than any of the other relays (loads like 6.xx), with about the same number of client connections (few hundred), and occasionally people complained of audio oddities (behaviour varied). The Winamp folks informed me that this was often specific to the FreeBSD version (they weren't sure why) but also that the codec/encoder being used on the client-side made a huge impact on the performance of the relay server, and that there were some pirated/"cracked" MP3 encoding codecs out there which exacerbated this issue. I never got a straight answer from Ari as to what he was using, but that kind of info came straight from the folks who wrote sc_serv.

    Alternately, you could try turning off QoS to see if that makes a difference. If it did I wouldn't be too surprised (QoS is kind of a mess in general), but it's something to rule out regardless.

    BTW, conntrack itself should have nothing to do with this. Netfilter conntrack keeps track of which TCP, UDP, and ICMP (the latter two are stateless) connections are actively in-use (by anything using conntrack, which can even be things that are not using the NAT layer). There are lots of timers involved (esp. for UDP and ICMP, since they're stateless). If you were to actually be having conntrack-related problems, you'd probably see messages about it on the console (dmesg), your streaming client would say something about lost connection / having to retry, or your listeners would report of skips or socket closures/reconnections (both of which can happen anyway because the Internet is unreliable, so figuring out the root cause of things like that is often difficult).

    My recommended above troubleshooting methodology is a good starting place; you can at least rule out local problems that way. I can't be of any assistance past this point, sorry. Good luck!
     
  3. eangulus

    eangulus Network Guru Member

    Thankyou for the detailed answer. Helps allot.

    Will do a local test to eliminate some areas.

    You were saying that the Encoder was CPU intensive. I havn't been able to check CPU usage yet (working remotely at the moment). But the computer doing the encoding is a Windows 7 32Bit Core2Duo E8400 3Ghz with 4Gb RAM. Could this be an issue or is it plenty?
     
  4. eangulus

    eangulus Network Guru Member

    Also why would a Good Consumer grade Router like the RT-AC66U + Tomato be any good. You say its because of the CPU intensive yet isn't that relevant to the streaming server?
     

Share This Page