TaskQueuePacedSender::MaybeUpdateStats() is intended to be called when
packets are sent or by a sequence of "scheduled" calls. There should
only be one scheduled call in flight at a time - and that one
reschedules itself if needed when it runs.
A bug however caused the "schedules task in flight" flag to
incorrectly be set to false, leading to more and more schedules tasks
being alive - eating CPU cycles.
This CL fixes that and also makes sure the queue time properly goes
down to zero before the next idle interval check, even if there are no
more packets to send.
Bug: webrtc:10809
Change-Id: I4e13fcf95619a43dcaf0ed38bce9684a5b0d8d5e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176330
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31390}
This is useful in debugging the latency from a packet
is enqueued until it's sent.
Bug: webrtc:11617
Change-Id: Ic2f194334a2e178de221df3a0838481035bb3505
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176231
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31381}
Since locking model has been cleaned up, PacingController can now call
PacketRouter directly - without having to go via PacedSender or
TaskQueuePacedSender.
Bug: webrtc:10809
Change-Id: I181f04167d677c35395286f8b246aefb4c3e7ec7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175909
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31342}
With an optional parameter this allows the task-queue based paced
sender to mimic the old behavior and coalesce sending of packets in
order to reduce thread wakeups and provide opportunity for batching.
This is done by simply overriding the minimum time the thread should
sleep. The pacing controller will already handle the "late wakup" case
and send any packets as if it had been woken at the optimal time.
Bug: webrtc:10809
Change-Id: Iceea00693a4e87d39b0e0ee8bdabca081dff2cba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175648
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31328}
This CL is functionally a noop but may reduce thread wakupes in some
cases.
In particular, consider a send task scheduled for time T. While waiting
for that, a higher-priority packet than the top of the current queue is
added (e.g. an audio packet), and a send is executed immediately.
After sending, it resets the field indicating that a scheduled task is
expected at time T. It then polls NextSendTime() and schedules a new
task, likely at or very close to T. Causing unnecessary task queue
churn and behavior that is more difficult to reason about.
Bug: webrtc:10809
Change-Id: Ic5706f2cc06df3f27cc3e7b473d4de29a669473b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173700
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31116}
The TaskQueuePacedSender today has some inefficiencies:
* Enqueuing a packet will trigger a MaybeProcessPackets() call, but it
won't actually run immediately even if it should - instead it will
schedule a new call in at least 1ms. This incurs delays and extra
CPU overhead.
* Sometimes thread wakeups are scheduled simply in order to do
book-keeping: ProcessPackets() will be called when the media debt has
gone down to 0 even if there is no packet in the queue, in order to
check if we should send padding.
This CL fixes that by called ProcessPackets() immediately if it is
actually time to do so, and by immediately determining when padding
should be sent without having a separate call to drain media debt.
Bug: webrtc:10809
Change-Id: I4870e86e6de2ce4197463fd5b788ad4717fc7177
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/172842
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31010}
This is a reland of 086055d0fd
ANA was accitendly disabled even when transport sequence numbers were
negotiated due to a bug in how the audio send stream is configured. To
solve this we simply continue to always allow enabling ANA and leave it
up to the application to ensure that it's not used together with receive
side estimation.
Original change's description:
> Reland "Only include overhead if using send side bandwidth estimation."
>
> This is a reland of 8c79c6e1af
>
> Original change's description:
> > Only include overhead if using send side bandwidth estimation.
> >
> > Bug: webrtc:11298
> > Change-Id: Ia2daf690461b55d394c1b964d6a7977a98be8be2
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/166820
> > Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
> > Reviewed-by: Sam Zackrisson <saza@webrtc.org>
> > Reviewed-by: Ali Tofigh <alito@webrtc.org>
> > Reviewed-by: Erik Språng <sprang@webrtc.org>
> > Commit-Queue: Sebastian Jansson <srte@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#30382}
>
> Bug: webrtc:11298
> Change-Id: I33205e869a8ae27c15ffe991f6d985973ed6d15a
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/167524
> Reviewed-by: Ali Tofigh <alito@webrtc.org>
> Reviewed-by: Sam Zackrisson <saza@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
> Commit-Queue: Sebastian Jansson <srte@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#30390}
Bug: webrtc:11298
Change-Id: If2ad91e17ebfc85dc51edcd9607996e18c5d1f13
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/167883
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30413}
This is a reland of 8c79c6e1af
Original change's description:
> Only include overhead if using send side bandwidth estimation.
>
> Bug: webrtc:11298
> Change-Id: Ia2daf690461b55d394c1b964d6a7977a98be8be2
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/166820
> Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
> Reviewed-by: Sam Zackrisson <saza@webrtc.org>
> Reviewed-by: Ali Tofigh <alito@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Commit-Queue: Sebastian Jansson <srte@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#30382}
Bug: webrtc:11298
Change-Id: I33205e869a8ae27c15ffe991f6d985973ed6d15a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/167524
Reviewed-by: Ali Tofigh <alito@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30390}
This reverts commit 8c79c6e1af.
Reason for revert: Introduced a Bug that can happen if the include overhead state changes between pushing and poping a packet from the pacer packet queue.
Original change's description:
> Only include overhead if using send side bandwidth estimation.
>
> Bug: webrtc:11298
> Change-Id: Ia2daf690461b55d394c1b964d6a7977a98be8be2
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/166820
> Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
> Reviewed-by: Sam Zackrisson <saza@webrtc.org>
> Reviewed-by: Ali Tofigh <alito@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Commit-Queue: Sebastian Jansson <srte@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#30382}
TBR=saza@webrtc.org,ossu@webrtc.org,sprang@webrtc.org,srte@webrtc.org,alito@webrtc.org
Change-Id: I0cacbc26408b7bec5bc3855a628e62407c081117
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11298
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/167523
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30383}
