-
When disabled we can save some iterations over timers. There is probably an argument for rtx-delay-reorder to exist, but for normal operations, handling jitter (reordering) is something a jitterbuffer should do, and this variable feels like functionality that is not "in-sync" with what the jitterbuffer is trying to achieve. Example: You have 50ms jitter on your network, and are receiving audio packets with 10ms durations. An audio packet should not be considered late until its rtx-timeout has expired (and hence a rtx-event is sent), but with rtx-delay-reorder, events will be sent pretty much all the time due to the jitter on the network. Point being: The jitterbuffer should adapt its size to the measured network jitter, and then rtx-delay-reorder needs to adapt as well, or simply get out of the way and let the other (better) rtx-mechanisms do their job. Also change find_timer to only use seqnum as an argument, since there will only ever be one timer per seqnum at any given time. In the one case where the type matters, the caller simply checks the type. https://bugzilla.gnome.org/show_bug.cgi?id=769768
1436fc01
