View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010116 | ardour | bugs | public | 2026-01-10 11:47 | 2026-03-14 12:49 |
| 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. |
| 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 |
