View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006494 | ardour | features | public | 2015-08-02 23:58 | 2015-08-08 02:13 |
| Reporter | lpirl | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Product Version | 4.0 | ||||
| Summary | 0006494: calculation of plugin latency | ||||
| Description | As from what I understand, Ardour calculates the latency for track when stopping the transport. However, I think I came across a use case where updating the latency would also be useful when the transport is stopped (so that when starting to roll, everything is configured correctly). Would it be reasonable to calculate the latency of a track when a plug-in parameter was changed even when not rolling? The LV2 specification requires plug-ins to update their control outputs when `run` is called with sample_count==0. That appears to be useful for that scenario. | ||||
| Tags | No tags attached. | ||||
| related to | 0005073 | new | Latency overcompensation when bouncing tracks |
|
|
Ardour currently only does plugin latency compute runs when instantiating the plugin and after a user manually modifies additional plugins latency (or clicks reset in the plugin latency dialog). IOW Ardour assumes the plugin latency does not change. |
|
|
Okay, this does not match my observations but maybe you can help me understand: I have a plug-in that changes its latency according to the parameters set. Ardour does not adjust to the latency when I change the parameters when rolling (of course). When the transport is stopped, I change the parameters and then I start rolling, Ardour is not adjusted to the latency as well. No matter when I change the plug-in parameters, Ardour adjusts to the latency after stopping (, not changing the parameters) and rolling again. |
|
|
correct. That's a 2nd separate issue or feature, unrelated to plugin latency reporting. The total session (worst-case) latency is only applied ardour's transport stops. New audio read-ahead times are set for the next play (and Ardour starts buffering audio at the right time). That's also true for jack-latency callbacks or graph-order changes. Currently the latency-compensation is only updated after a transport-stop. |
|
|
PS. as mentioned in 5073 it is not reasonable to re-calculate the latency on every parameter change. A different approach will be needed for that case (e.g an implicit variable delayline). It ties in with bus latency compensation, as well. PPS. curious. What plugin is that which changes its latency depending on a parameter? |
|
|
In reply to the PPS: It is probably an edge case but it is a plug-in that positively or negatively delays a signal. <verbose> E.g., this is useful to compensate the offset that is introduced when a sound source was recorded using multiple microphones in different distances. If the delay is changed while not rolling, Ardour plays back "wrongly" the first time. That is confusing. Always reporting the maximum possible latency is not really an option since it introduces a "latency" when the transport starts and the plug-in does not actually need that amount of latency. </verbose> |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-08-02 23:58 | lpirl | New Issue | |
| 2015-08-06 15:36 | x42 | Relationship added | related to 0005073 |
| 2015-08-06 15:38 | x42 | Note Added: 0016996 | |
| 2015-08-07 23:21 | lpirl | Note Added: 0016998 | |
| 2015-08-08 01:16 | x42 | Note Added: 0016999 | |
| 2015-08-08 01:19 | x42 | Note Added: 0017000 | |
| 2015-08-08 02:13 | lpirl | Note Added: 0017001 |
