-
Notifications
You must be signed in to change notification settings - Fork 120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mixer optimisations #21
Labels
driver
Relates to the driver or one of its sub-tasks.
enhancement
New feature or request
feature-request
Request for addition of a new feature or improvement.
Milestone
Comments
FelixMcFelix
added a commit
to FelixMcFelix/songbird
that referenced
this issue
Dec 4, 2020
Benchmarks driver use cases for single packet send, multiple packet send, float vs opus, and the cost of head-of-queue track removal. Mix costs for large packet counts are also included. This is a prelude to the optimisations discussed in serenity-rs#21.
On point 1, "a pair of channels to pass prealloc'd Vecs back and forth" results in a 4% perf regression universally. Skipping for now, as an optimal solution is probably unsafe. |
FelixMcFelix
added a commit
to FelixMcFelix/songbird
that referenced
this issue
Dec 7, 2020
Benchmarks driver use cases for single packet send, multiple packet send, float vs opus, and the cost of head-of-queue track removal. Mix costs for large packet counts are also included. This is a prelude to the optimisations discussed in serenity-rs#21.
FelixMcFelix
added a commit
that referenced
this issue
Dec 26, 2020
* Driver Benchmarks Benchmarks driver use cases for single packet send, multiple packet send, float vs opus, and the cost of head-of-queue track removal. Mix costs for large packet counts are also included. This is a prelude to the optimisations discussed in #21. * Typo in benchmark * Place Opus packet directly into packet buffer Cleans up some other logic surrounding this, too. Gets a 16.9% perf improvement on opus packet passthrough (sub 5us here). * Better track removal In theory this should be faster, but it aint. Keeping in case reducing struct sizes down the line magically makes this faster. * Reduce size of Input, TrackHandle Metadata is now boxed away. Similarly, TrackHandles are neatly Arc'd to reduce their size to pointer length (and mitigate the impact of copies if we add in more fields).
FelixMcFelix
added a commit
to FelixMcFelix/songbird
that referenced
this issue
Jan 4, 2021
* Driver Benchmarks Benchmarks driver use cases for single packet send, multiple packet send, float vs opus, and the cost of head-of-queue track removal. Mix costs for large packet counts are also included. This is a prelude to the optimisations discussed in serenity-rs#21. * Typo in benchmark * Place Opus packet directly into packet buffer Cleans up some other logic surrounding this, too. Gets a 16.9% perf improvement on opus packet passthrough (sub 5us here). * Better track removal In theory this should be faster, but it aint. Keeping in case reducing struct sizes down the line magically makes this faster. * Reduce size of Input, TrackHandle Metadata is now boxed away. Similarly, TrackHandles are neatly Arc'd to reduce their size to pointer length (and mitigate the impact of copies if we add in more fields).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
driver
Relates to the driver or one of its sub-tasks.
enhancement
New feature or request
feature-request
Request for addition of a new feature or improvement.
A few missing mixer optimisations marked as ToDos, in order of importance:
pair of channels to pass prealloc'd Vecs back and forth, or ashared memory buffer with a semaphore or similar mechanism to indicate which packet each side should care about. The former is safer, but probably slower. There are other optimisations we can use here, such as abusing the fact that most of the packet body is already written.opus_frame_backing
a view onto the active packet buffer being readied for send. This will save an extra copy per packet when frame passthrough is happening.Store finished tracks as tombstone entries. This prevents copies due to array reordering on element deletion, but requires that we keep a free list on the side and exactly mirror this behaviour in the event thread.O(1) (non order preserving) deletion will suffice, unless we adopt some SoA layout in the driver in future.The text was updated successfully, but these errors were encountered: