If a significant part of your end-users report frequent buffering interruptions for a given live stream, and this happens whenever you increase your encoding bitrate, a first assumption could be that the downlink throughput of end-users is not enough to handle your encoding bitrate. For instance, if you are encoding at 2Mbps bitrate and some end-users can only reach 1.5Mbps of downlink throughput based on their Internet connections, you will inevitably produce frequent buffering interruptions for them.
If you select a random group of users who complain about this and ask them to report their current available downlink throughput, in most cases they will always tell you they have "more than enough bandwidth". Many times, what users report is the speed advertised by their current ISP, which doesn't necessarily reflect the actual available speed, since there may be several other factors involved (i.e. ISP over assigning bandwidth, user sharing overall speed among several devices simultaneously, virus/spyware consuming bandwidth...). You can ask them to perform a realtime online test using something like
http://speedtest.net and compare the values.
If a significant part of your end-users access the stream using slower connections, but at the same time you still want to deliver a high-bitrate version of the stream to those end-users who do have better connections, you may want to consider implementing Multi-Bitrate Streaming. Instead of sending a single rendition of your stream from your encoder (i.e. FMLE or Wirecast), you can send multiple simultaneous renditions, each encoded at a different bitrate, and let each end-user Roku device automatically and dynamically select the one that is more appropriate based on the actual available bandwidth.
Besides checking the end-user's side of the problem, it's also important to make sure your own *uplink* throughput is high enough to handle your encoding bitrate (from your encoder to the Internet). If it isn't, you may be generating the buffering interruptions yourself, by not sending the video at the speed required by your defined encoding bitrate to avoid interruptions. You can test with
http://speedtest.net from the server or computer running your encoder (try selecting a test server that is geographically located near your RTMP publishing point). It's usually a good idea to use an encoding bitrate not higher than 60-70% of your actual uplink throughput.
Finally, bitrate and throughput are just two of the many variables that can influence your stream actual (perceived) quality. Other variables such as resolution, frame rate, keyframe frequency, are also very important.
