View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010116 | ardour | bugs | public | 2026-01-10 11:47 | 2026-04-17 11:50 |
| Reporter | GhostsonAcid | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | macOS | OS | Mojave | OS Version | 10.14.6 |
| Product Version | 9.0-rc | ||||
| Summary | 0010116: Quick resuming of playback after pause/stop seems impossible for larger projects... (2+ second delay) | ||||
| Description | Here, I made another video demo about this (2.5min): https://odysee.com/@icterine:a/Ardour-(8,12-and-pre9)---Ability-to-Play-Again-is-Delayed-by-2+-Seconds:9 Currently, editing tasks that demand hundreds or thousands of rapid plays & pauses of the transport are excruciating, as you sometimes have to wait a considerable amount of time (2+ seconds) to resume playing. What is the cause of this? And are there some settings (etc.) I can change to improve this? (Is this an audio hardware issue, or an Ardour issue? Is this a macOS-specific issue?) ... In the meantime, I'll keep testing and experimenting! Thank you! : ) -J | ||||
| Tags | delay, slow, transport | ||||
|
|
UPDATE: In testing various things, I now know: 1. If you simply mute ALL the regions in the session, the problem goes away! (-No touching of number of regions, tracks, plugins, waveforms, etc..) 2. This is NOT a .wav vs .flac processing issue. ... Initially I suspected *meters* to be the issue, as the processing of their display has always been laggy and slow in general, esp. in settling down to -inf upon hitting pause/stop. So instead of my mute-all-regions test, I just now imported a *completely silent audio region*, duplicated it hundreds of times, and left them UNMUTED... to which the problem remained. : / -Still could deal with meter visualization though, I don't know. -J |
|
|
I don't know why the hell I marked this as "Priority normal" and "Severity minor". ~If I remade this today I'd do "urgent" and "major". : ) Deactivating large swaths of tracks/buses does improve this, but lack of overall *transport responsiveness* (esp. in bigger projects) is still quite unhelpful. But for now, can one of you (@paul or @x42) please at least tell me *why* this delay exists in the first place? *What* aspects of Ardour are preventing the transport from being more responsive to rapid play/pause usage? Thank you! : ) Cheers, -J |
|
|
Buffer refiills. I know it seems saems as if they should not be needed if you just stop and restart, and conceptually that's true. In practice, at present, it's not. Keep in mind that Ye Olde ProTools used to take many seconds for this (for entirely different reasons). Somehow it was still considered The DAW :) |
|
|
Occasionally, highly latent plugins or signal paths can also play a role in this too, but typically not 2 seconds. |
|
|
@paul Thank you very much for the clarification. : ) I will do what I can then to mitigate the issue, like deactivating unused groups. But are there *any other recommendations*??? E.G.: • Use a faster SSD/HDD setup? • More RAM? • Faster RAM? • A faster CPU? ... -Would any (or some) of that help??? Thanks again! -J |
|
|
@paul I mean, a 2-3second delay is absolutely *brutal* to deal with... Clicking somewhere (which one *constantly* does during basic editing on the timeline), pressing play, then waiting 2-3 seconds... ultimately eats into editing/mixing time massively..... Current project/setup in question (as an example): --> 77 routes in total (i.e. tracks and buses). --> 22 mono/stereo sources concurrently playing. --> 29.37ms PDC (-minuscule). --> 32GB RAM, 3.5 GHz 6-Core Intel Xeon E5 (-5 cores for Ardour). --> Source files only located on the internal (main) SSD, with 0000655:0001500/1300 MB/sec read/write speeds. ... Is there not some 'relatively simple' structural/code-change to curtail "buffer refill" time? Some shortcut? I'm on a fairly capable machine (imo)... So how/why could this "refill" process for only 22 source files take about *2-3 whole seconds* to complete?!? O_____o -J |
|
|
1500/1300 MB/sec read/write* (I forgot I can't use the tilde symbol here on Mantis... o___o) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-01-10 11:47 | GhostsonAcid | New Issue | |
| 2026-01-10 11:47 | GhostsonAcid | Tag Attached: delay | |
| 2026-01-10 11:47 | GhostsonAcid | Tag Attached: slow | |
| 2026-01-10 11:47 | GhostsonAcid | Tag Attached: transport | |
| 2026-01-10 13:17 | GhostsonAcid | Note Added: 0029702 | |
| 2026-03-14 11:09 | GhostsonAcid | Note Added: 0030111 | |
| 2026-03-14 12:48 | paul | Note Added: 0030114 | |
| 2026-03-14 12:49 | paul | Note Added: 0030115 | |
| 2026-03-15 11:14 | GhostsonAcid | Note Added: 0030122 | |
| 2026-04-17 11:49 | GhostsonAcid | Note Added: 0030267 | |
| 2026-04-17 11:50 | GhostsonAcid | Note Added: 0030268 |
