High CPU Usage with Audio playback #185
Comments
|
0.3.2 is not worth caring about; it inherited a legacy of using ffmpeg to process audio and then contacting it via IPC. 10% CPU per stream is... remarkable. As a sanity check, you are compiling with
This cannot be avoided unless you feed in an opus source -- libopus costs what it costs. Even so, wav is cheap: You could try running |
|
Yeah I made sure to build it with Here is the full benchmark that i got on the EC2 Instance: |
|
PR #179 Does seem to improve this significantly with per stream CPU usage at 1.6% with 1.9% peaks. Which is much better but still 0.3% Per Stream off from Lavalink though that is probably good enough for most applications. |
|
Thanks for running the benchmarks locally, that's pretty disappointing (but I'm glad #179 has a big effect). I can think of some remaining places that are less than optimal (e.g., event thread wakeups regardless of handler registration). The only other thing that comes to mind is maybe the async->sync adapter adding more memcpys in the Http case. What I can recommend today is setting softclip to false for a marginal improvement -- it's enabled by default to prevent folks from blowing out someone's eardrums by naïvely playing too many audio sources at once. There are one or two things in symphonia that trip us up here: because it works in planar audio, we're doing a lot of copying on WAV to achieve interleaved (wav) -> planar (mixing) -> interleaved (libopus). I don't think those can be fixed without rearchitecting. |
|
Alright thanks for the advice. |
Songbird version:
nextbranch and 0.3.2Rust version (
rustc -V): 1.69Serenity/Twilight version: serenity: 0.11.5
Description:
I'm getting really high (relatively) CPU usage when playing back audio using either the
nextbranch and songbird 0.3.2 (I haven't tested any other versions). It seems to use about 4 - 10% extra CPU per concurrent stream.Which is a bit of a problem because at that rate you may only get 10 - 20 concurrent streams. I created a flamegraph with
cargo flamegraphfor both thenextbranch and 0.3.2. It seems like a lot of the time is spent on opus encoding (Im using a WAV file as a source). But more generally that a lot of minor inefficiencies seem to be adding up to a larger issues with performance.For a quick comparison with the same load lavalink peaks at around 3.3%.
I have attached the flamegraphs below. It does seem like the
nextbranch version is somewhat better at CPU utilization but only by about 2%. I'm measuring CPU usage with thetopcommand If that's important. Im using an AWS EC2 Instance with 8GB of memory and four Intel Cores.Steps to reproduce:
NEXT:
0.3.2:
The text was updated successfully, but these errors were encountered: