Published by PitchChanger · Updated · How these guides are made
How to use this workflow
Define start and finish
Choose whether timing starts at file selection, processing click or completion of engine loading. Stop at a stated event such as prepared output. Report downloading, decoding, processing and saving separately when possible.
Keep the comparison fixed
Use the same source, duration, channels, settings, browser and device. State whether caches were warm and whether the tab stayed foreground. Do not compare an eight-second mono test with a long stereo recording as if only the engine changed.
An original worked units example
Hypothetical job: 120 seconds of source audio processed in 30 seconds after setup. Real-time factor is processing seconds divided by source seconds: 30 / 120 = 0.25. Audio throughput is 120 / 30 = 4 audio seconds per wall second. Neither number means a listener judged output quality.
Swipe or scroll sideways to read all columns.
| Metric | Calculated value | Interpretation |
|---|---|---|
| Processing wall time | 30 s | Time spent in defined stage |
| Real-time factor | 0.25 | Lower means faster for the same workload |
| Audio throughput | 4× real time | Reciprocal of real-time factor |
| Setup included: 20 s extra | 50 / 120 = 0.417 | End-to-end timing differs |
Verify the result and record its limits
Report individual runs and their range rather than only the fastest run. A failed run is a failure, not a zero-second result. Avoid MB/s comparisons across compressed formats: compressed byte size does not express decoded sample workload. These numbers are worked calculations only; record actual device and tool observations before making a performance claim.
Common questions
Was this example measured on my device?
No. The worksheet and any hypothetical numbers are explicitly labeled. Use a harmless recording to collect your own observations and record the browser, date and exact operation.