Results 1 to 3 of 3

Thread: Audio chat app - Wowza dropping 33% or more of Speex frames

  1. #1

    Default Audio chat app - Wowza dropping 33% or more of Speex frames

    I have an audio conference app (written in Java, using an RTMP client lib from that sends Speex frames to Wowza.

    I have two test clients - one, a publisher, sends frames to an app/room/stream (each with a sequence number inserted in the frame) and another connects to the app/room/stream and plays the stream. The player picks the sequence number from each frame and reports when frames are skipped.

    On my local machine (OS X Lion, Java 1.6.0_29-b11-402-11M3527, 64bit) I'm finding that Wowza is consistently skipping 1, 3 or 5 frames (it's never any other number). Frames are always skipped - I track the run length when I receive successive frames and report the last run length when I get a skip - it's always zero.

    My publisher sends a frame every 20ms and I have a check in my player that reports if it ever takes more than 20ms to process a frame, which it never does.

    If I use an RTMP proxy (from JUV RTMP Researcher from I can see data flowing between my client and Wowza. Data received is always 3-5 times less than data sent, which is consistent with the number of dropped frames.

    If I run Wowza on my VPS (Debian 5.0.9, Java 1.6.0_29-b11, 64bit) then it skips 1, 5, 7, 9 or 13 frames with no contiguous frames.

    What am I missing? My Wowza app is a skeleton and does nothing, logging is set to INFO. My local machine is a MacBook Pro Core 2 Duo (2.96GHz) with 4GB RAM and an SSD, 256MB free RAM consistently, CPU usage 2-12% on average. My VPS has 512MB RAM, 256MHz CPU (squid, apache and qmail also running). I could accept that the VPS is a bit underpowered, but does Wowza really have system requirements above that of my MacBook Pro or could there be something else wrong?

    UPDATE: I've checked against the performance guide. Wowza is running "java -server" and I've set the send and receive buffers to 16000 initially and then down to 1600 and finally 160 (my frame size is 57 bytes) with no effect. This is all on a single machine. CPU usage spikes to 83% when the test starts and then settles to ~20%.
    Last edited by edoloughlin; 02-18-2012 at 10:38 AM.

  2. #2


    RTMP uses TCP so any dropped frames would be on the source side not the receiving side. So I would focus there. We do not know anything about the Smaxe stuff. I do know that Speex/Flash/RTMP has some way to combine individual Speex frames into a single RTMP audio packet. There may be something wrong with the way this is being done.


  3. #3


    The library author asked me to change the connection parameters and lower the timeouts. This seems to have made a big difference for local (single machine) operation but there's still data loss.

    I looked at the performance guide and reduced my send and receive buffers to 160 bytes (my frame size is 57 bytes) but this didn't change anything.

    I've put counters in my test clients to get a better idea of what's going on and I've correlated these against the Wowza logs.

    My publisher client reports that it sent 53142 bytes in 932 frames and if I look in the Wowza log, I find a 'destroy stream' entry for the client id where the 'cs-stream-bytes' is 53954.

    My player client reports that it received 11172 bytes in 197 frames. The destroy stream entry on the Wowza log matches this exactly: sc-stream-bytes is 11172!

    The Wowza server is running on a VPS but I shut it down immediately following the test and the load average was reported as: '0.08, 0.08, 0.06', so I don't think CPU is an issue.

    What does the low sc-stream-bytes number mean? Does the fact that Wowza is reporting that it received one number but only send a much smaller number mean that it's been lost internally somehow or could there be a transport problem?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts