Can't set buffertime for a live audio stream

[jiwan2004]

We use a server to forward audio to all clients. It always report an error in Cumulus when we set buffer time for a RTMFP stream in client. "raw message unknow XXXXXXXXXXXXXXXXx for flow 2"

The audio will be broken if we use RTMFP when buffertime is set as 0. So we need to set buffer time

Thanks a lot.

[cumulusdev]

Ok, I will look it, but you are speaking about "NetStream.bufferTime" property we are right?

[nsdns]

YES, I find the same problem. It is why?

[jiwan2004]

yes. it's Netstream.buffertime. thanks a lot!

[jiwan2004]

If we don't set netstream buffertime in client side, we found some user can't hear the voice clearly. The voice is broken. It maybe rooted from cpu or sound card device. I guess it's clock skew problem. Jitter buffer can't fix this problem. So it's important to set netstream buffer time in some client.

Maybe the opentrtmfp doesn't support user ctrl message now. If we set buffer time in client side, we can't hear any voice. I'm not sure it's flash client problem or server problem.

We have tested live stream for the openrtmfp, it's stable. It works great form some computer which has good sound card or cpu. It's really great! Hope we can fix this buffer time problem. Thanks

[nsdns]

HI ,jiwan2004,may i ask you. you are use the test win32 exe,or the build exe,or the linux build file?

[jiwan2004]

We have tested win32.exe and linux build, we got same problem. . We debug the openrtmfp win32.exe. In this function, Flow::fragmentSortedHandler(UInt64 stage,PacketReader& fragment,UInt8 flags) We receive the message Type=4 (if you set buffer time when you receive a rtmfp stream , you will get this message), the function doesn't handle this mesage. So rawhandler print out the error.

We tried to handle this message. We changed Flow and Flow stream rawhandler for tesing void Flow::rawHandler(UInt8 type,PacketRead & data) { if(type==Message::UserCtrl){ writer.writeStatusResponse("set buffer","ok") ; return; } ERROR("Raw message %s unknown for flow %s",Util::FormatHex(data.current(),data.available()).c_str(),NumberFormatter::format(id).c_str()); }

We monitor the network traffic. We found the client have audio flow in but we still can't hear anything.

I'm not very sure if it's a server problem. Everything is normal. The server didn't close or unscribe the audio stream. it kept forwarding audio data. But we couldn't hear anything at client side if we set buffertime

[jiwan2004]

Something maybe helpful:

We monitor audiobufferlength(not buffer length) at client side. For some computer which has very broken voice, the audiobufferlength is very small and it can't increase . We get reasonalbe audiobufferlength in the computer which works fine..

So I still doubt it's clock drifting problem.

[jiwan2004]

Maybe it's not buffer time problem. Choppy audio maybe caused by timestamp in audio packet sent by Cumulus.

For some computer it works fine but not for all.

if we use rtmfp, I'm not sure if framesperpacket setting for speex will lead to unexpected jittter buffer behavior at client side.

So far I guess maybe it's timestamp problem which lead to unexpected jittter buffer behavior in some client.

[jiwan2004]

What's more, even we set audioReliable=true, audio is still very choppy. It's very bizzard

[jiwan2004]

We tested Adobe FMS 5.0. It support setting netstream buffertime. It fix choppy audio problem. So setting buffer time is very important. We highly suggest Cumulus support this function. thanks

[cumulusdev]

My last commit fix this bug :-)