FMIS 3 - Audio stream performance

[MMLincoln]

I ran a broadcast last night and got to test out our new Win 2003 Server + FMIS
3 setup. We had issues with audio breaking up and I did some logging for
diagnostics. I was hoping that the upgrade from Win 2000 + FMS 2 would resolve
our audio issues, but it has not.

Details:
* 3.0 Ghz Dual processor, dual-core Xeon server w/ 2 Gb RAM
* Windows 2003 Server
* FMIS 3 default installation w/ application scope set to "inst"
* Audio-only stream, Audio rate: 11 Khz (31 kbps per client)
* Server's CPU usage was consistently at 3-4%
* Server's memory remained at 1.3Gb/2Gb available
* A large portion of clients may have dial-up, satellite, municipal wireless,
rural DSL

Timeline:
8:00 - broadcast started w/ about 250 users connected
8:16 - 300 users connected, major audio breakups (5-10 seconds of silence,
back on for a couple seconds, then silence again, garbled audio) Lasted about 3
minutes
8:19 - CPU usage jumped to 25% briefly and audio came back to a consistent
level
8:37 - A few 1/2 second audio skips
8:40 - Audio breakups for 1-5 second periods (lasted for about 1 min)
8:43 - Intermittent skips, completely lost audio for 20 seconds, then had
garbled audio (CPU: 3-5%, RAM: 1.3G available)
8:47 - A few 1/2 second audio skips, then 1/2 second of garbled audio

Any suggestions would be appreciated

[MMLincoln]

Another thought...
We are recording the broadcasts. The recordings made on our server are fine
when we play them back, so I assumed that the connection from the broadcaster
to the server was fine.
However, I was wondering if it was possible that the broadcaster's connection
was bad, getting buffered locally, and then the recording was being reassembled
when it finally made it to the server? If this does happen, how long would the
stream buffer locally? Some of our audio breakups were 5-20 seconds long.

[techeye]

You should check to see if there is there anything in the FMS log files. That
is probably your best bet. If they look clean, it may have been a network
issue, or perhaps some other OS/ software running ?

[fmslove]

easy suspect would be the buffer settings on flash client side (.swf). A buffer
length of >3 to 5 second should help more ( if it was not the case currently)
Assuming that your broadcast is one-way and delay of 3 to 5 second is
tolerable for better performance;

[MMLincoln]

Thanks for the replies. I checked the log files and there wasn't anything
abnormal in there.

I did some testing this morning and I think we got it figured out. We assumed
since the server recording was perfect that the broadcaster's connection to FMS
was good. However, it looks like the .FLV recording is getting reassembled on
the flash server as soon as the broadcaster's connection cleans up. I can go to
around 15 seconds of being disconnected and it still results in a perfect .FLV
recording. (After 15 seconds the NetConnection close method is called on the
broadcaster app)

This particular app can tolerate some audio latency, so I am considering using
a 3-5 second buffer on the netstream.