View source for TPEPlatform/WebRTC B2G/Workweek note

#Audio latency
#*https://bugzilla.mozilla.org/show_bug.cgi?id=884365. Take a lot of time to address this problem. Very tricky issue.
#*Clock drift: http://en.wikipedia.org/wiki/Clock_drift
#*Randell collected all audio issues in one page. https://wiki.mozilla.org/Media/WebRTC_Audio_Issues 
#Audio latency from microphone / network to speaker.
#SDP: Negotiation of Generic Image Attributes in the Session Description Protocol
#*With RFC6236, sender and reciever may handshake frame rate/ size wish.
#*http://tools.ietf.org/html/rfc6236
#SCTP has flow control, should not test network performance above the protocol layer. Measurement between RTP end pionts will be a good one.
#*SCTP has the advantage of TCP's reliability and UDP's less delay.
#*SCTP is used by WebRTC Data Channel, for sending/receiving data (ex: message or file) between two browsers.
#*For more information about Data Channel, see http://www.slideshare.net/zhange1/why-webrtc-datachannel-excites-me
#The jitter buffer in GIPS will resample, generate or drop the incoming audio frames. 
#*When audio is delayed but not timeout, jitter buffer generates fake audio (according to current received data).
#*When the delayed audio comes and the audio is not timeout, jitter buffer resamples the incoming audio with current received data. That makes the audio sounds a lillte sharp.
#*When the delayed audio comes and audio is timeout, jitter buffer drops the incoming audio.
#Linux scheduling  http://www.linuxjournal.com/article/3910
#*Only root can set real-time priority.
#*Task with real-time priority leave CPU only when there is other real-time prioriy task
#*In conclusion, if the process runs as root and there are threads set to real-time priority. Those threads with SCHED_OTHER can be ran only when real-time threads are sleeping.This causes problems. Ex, MSG's thread callback to send video frame to encoder. Just one memory copy and few mutexes, and it costs about 16ms for every call.
#ICE: handle dynamic network interface change
#*https://bugzilla.mozilla.org/show_bug.cgi?id=881982
#*Long term solution: draft-wing-mmusic-ice-mobility-03
#Release workload in RTCP process
#*Disable NACK mode in RTCP.
#*What's NACK?
#*http://techbus.safaribooksonline.com/book/networking/rtp/0672322498/error-correction/ch09lev1sec3
#*But whether NACK is helpful or not is disputing. 
#*#It needs to check the rtp very often. That may cause some overhead
#*#When detecting packet lost, it needs to issue re-send requests very quick or the lost packets may time out. Since packet lost usually happens when network is bad, how can the re-send requests arrive to the sender site quickly?
#*In WebRTC code base, calling SetNACKStatus(mChannel, false) in VideoConduit.cpp. http://dxr.mozilla.org/mozilla-central/source/media/webrtc/signaling/src/media-conduit/VideoConduit.cpp#l258