The broadcast's bitrate + network overhead + any other internet use all need to add up to less than the upstream connection speed. This means it's not very likely that a 32k stream will work reliably with a 33k connection. This is why the "Output Quality" selections are somewhat less than the various connection rate settings.
This is because other computers on the internet that talk to your computer are also using up your bandwidth. If you run a web server or something like Napster and people are connecting to your system you will lose out.
(You might also get strange probes from systems just seeing what's on the internet or maybe your ISP is doing a weekly port scan of you server to see if you are running things you shouldn't - in general these shouldn't cause a problem.) Cable modems and DSL to a lesser extent can have some interesting problems.
These often allow high "bursting" speeds but if the bandwidth usage from a user remains high they start to throttle it down. Basically these ISPs want to make interactive use, like web browsing, fast - but slow down people that are trying to hog bandwidth. Modern routers can also be programmed to give priority to certain services. An ISP might decide that email and web browsing have priority over all other internet services. This could mean that at times those others services get slowed down or packets are lost but web browser still seems fast. Be careful with using web browsing as a quality gauge to network performance.
Many ISPs have caching servers that cache a lot of common web content so you might think the response back from www.nbc.com was fast, but in reality the content was sitting on your ISP's server and your request never left their network.
Some other problems that can cause intermittent headaches include ISPs performing maintenance and rebooting "routers". A router reboot could mean complete or partial network loss for a few minutes. Maintenance often results in a long period of time with no access generally at some strange hour - Sunday morning from 1 AM - 4 AM is a common outage window, but these are at the ISPs discretion. It might be a good idea to talk with the ISP to find out if that have standard outage times or have a means to preannounce them.
Dial up connection pools and broadband connections can often suffer from heavy congestion. A broadcaster might only see skipping and lost connections during peak usage hours (generally evenings) or in some shared network environments, like cable modems, a neighbor could fire off something like Napster and bring every connection around them to a slow crawl.
Sometime ISPs like to drop modem connections. Users tie up a modem for hours and either the operators reset the bank of modems or just have some sort of time out in place to try and encourage people not to monopolize modems 24 by 7. Firewalls are another source of problems. Firewalls or router filters might block certain kind of connections. Typically ISPs don't block outbound connections but it can happen especially if the operators see something as abusive or violating their usage policy.
There are some tools that can help determine if there is a network problem. The most basic is "ping". You can run ping from your DOS (or "command prompt") window. Run about a hundred or so pings to the server that you are trying to talk to during the times you are experiencing problems. See how many fail to return. This should provide a rough idea of how much packet loss there is. Zero packet loss suggests the network is fine. 2-3% loss is generally tolerable. Anymore than that and the reliability isn't there is maintain a skip free broadcast. It should be noted that sometimes servers/routers won't reply to pings so a 100% packet loss could mean the server doesn't return them or it could mean the network has a major problem like a router is down or seriously overworked (pings use ICMP packets and if a router starts to become overloaded it will start dropping ICMP packets even though other packets get through). If you see some packet loss the second step is to try and identify where the problem is.
This is really a challenge. The best thing to do is run trace route (or "tracert") to the server you are trying to talk to and see if can locate a problem. Traceroute tries to identify each router on the way to the server you want to communicate with and how much latency there is to that router. You want to look for a router that doesn't respond or has greatly varied response times.
Traceroute also uses ICMP packets so there will be routers that will never respond to traceroute, so it's a good idea to run a this while there aren't any problems giving you a good idea of what you should see to compare against the problem times.
Live365 support is happy to look at any of the traceroute and ping outputs and if we see a problem we'll contact the network service providers.