View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007164 | ardour | features | public | 2016-12-09 14:24 | 2016-12-28 11:16 |
| Reporter | unfa | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | PC / Linux | OS | Linux Mint / KX Studio | OS Version | 18 KDE5 |
| Product Version | 5.5 | ||||
| Summary | 0007164: Ardour JACK transport: scrubbing doesn't refresh continuosly | ||||
| Description | I work with Ardour and Blender is sync to edit video and audio at the same time. When I scrub the playhead in Blender - Ardour's playhead follows closely along. When I scrub Ardours playhead - Blender's playhead updates only when I release the mouse drag on the Ardour playhead. I'd love Ardour to be able to send out JACK transport update continuously. Even if it can break some programs - I'd love to have such option (with a warning if this is considered bad practice). I'd be very happy to see Blender and Ardour transport synced more closely together. | ||||
| Tags | No tags attached. | ||||
|
|
You cannot scrub in Ardour using the playhead. You must use the scrub tool below the transport controls. Scrubbing is EXTREMELY hard to do correctly, and certainly not with JACK transport. The JACK transport protocol is just not designed for this. I would probably not expect this to ever work without the development of a new protocol shared by Ardour and Blender. |
|
|
I guess I used wrong wording. If scrubbing means dragging the playhead while the transport is rolling, it's not what I meant. I meant dragging the playhead with the transport stopped. When I drag the playhead in Blender - Ardour updates continuously - this is useful, because I can see the relative positions of both playheads immediately. I can see points that match in time in both programs easily. When I drag the Ardour's playhead - Blender updates only when I release the mouse drag in Ardour. I guess Ardour isn't sending the transport data continuously. To me (agnostic to the internal workings and the JACK transport design) - what Blender does seems to work very well and makes my work easier - keep the programs in a tighter sync, giving me a better feeling of how the two sessions interact. Is it be possible for Ardour to send JACK Transport position continuously when dragging it's playhead when the transport is stopped? Would that break anything? Ardour seems to nicely follow along, when Blender sends the messages in that way so I guess it'd also work well the other way around. |
|
|
"When I drag the Ardour's playhead - Blender updates only when I release the mouse drag in Ardour." That is intentional. Moving the playhead to a different position will result in the need to read data from disk at the target position to refill buffers. With many audio tracks or video tracks that is be significant overhead. JACK transport explicitly defines a "starting" state for this case http://jackaudio.org/files/docs/html/transport-design.html Trying to shoehorn scrubbing by using continuous seeks may work in some cases (small sessions or SSD) but will eventually fail one way or another. It definitely does not scale. |
|
|
I see that buffering can be an issue - but I don't need this to work while the transport is rolling! I don't need Ardour to play sound while I drag the playhead around - that'd be crazy and rather unpleasant. I guess I bady used the word "scrubbing" - I only mean synchronized playhead motion while the transport is stopped. I see that I used that all over the initial report and I think this is misleading. I'd loive to edit the issue details to correct the working, becasue I don't really mean "scrubbing". It's basically the same as if I stopped the playback and dragged the playhead in Ardour manually - only the location data is not taken from the mouse input, but from the JACK Transport. It's like I'm using a VNC session to send the same control data to both Ardour and Blender. What I do is pause the playback and simply move the playhead in Blender to locate a spot in animation I need to sync a sound event to - and Ardour playhead shows me the related spot in Ardour session. I use that for visual reference. I'd like to be able to do the same in reverse - move the playhead in Ardour and see how Blender playhead moves along- to help me get the feel of relation between the two timelines I'm working on. And since Ardour keeps up well with Blender - I guess Blender could also keep up with Ardour. |
|
|
While you don't need it, jack demands that an application pre-buffer on locate and tell jack when the seek is complete. This is required so that all jack clients can start in playing in sync immediately and it's baked into JACK-transport design. It's been annoying me a lot when doing film soundtracks and was the main reason why I added other timecode sources and sync (MTC, LTC) to xjadeo and Ardour and later added internal control of xjadeo via OSC by Ardour. In each case bypassing JACK transport. |
|
|
These JACK Transport sync checks generally sound like a great thing. Just in my use case they are not what I need. Could there be a "Rough Ride" mode for JACK Transport that'd ignore the syncing and prioritize the fastest operation over sound quality? Would JACK clients be able to conform to this? Would it require reimplementing this is all clients? |
|
|
There is no "locate" command in the JACK transport API. A client simply sees nonlinear motion, and needs to respond so it is ready for playback again as soon as possible. If the time master keeps sending new non-linear, non-realtime changes in transport position, clients have no way to understand what is happening, at least not reliably. Hence Ardour's behaviour of delaying the update until the drag is finished (or at least until it is idle). |
|
|
As I read there is something called int jack_transport_locate (jack_client_t *client, jack_nframes_t frame); Source: http://jackaudio.org/files/docs/html/transport-design.html I guess if the playhead is relocated unpredictably several times a second, the clients are trying to prefetch audio data to be ready for playback, but it's a waste of resources most of the time in such a case. Would it be possible to differantiate between a "hard relocate" (that implies syncing for playback) and a "soft relocate" (that doesn't)? When draggin a playhead around the "soft relocate" could be used, and once the playhead's unpredictable motion is over (or transport is started) a "hard relocate" command would tell the clients that playback is likely to occur so they should prefetch their data? JACK Transport would enter the "Starting" state and wait for clients to sync as usual before starting the transport. I imagine it could work like this: 1. With transport stopped I grab the playhead with my mouse entering a "soft transport update" state. 2. Any playhead position changes (me moving the mouse while dragging the playhead) are broadcast to clients as "soft relocations" - so they can move their playheads, update some visuals without worrying about being ready to play immediately, expecting next relocations to occur soon and unpredictably. Blender currently sends out transport updates as soon as they the playhead moves - I can see Ardour's playhead follow. 3. Once I release my mouse drag, send out a "hard relocate" command to tell the clients that unpredictable motion is probably over and they should prepare for playback. Currently Ardour sends out transport update at this point only - and I can see Blender playhead update. I guess this would save a lot of needless data prefetching in clients and allow continuous cheap playhead updates to tighten the JACK Transport experience (so Blender will follow Ardour's playhead dragging closely, just like Ardour follows Blender this way now - but in a saner, better-handled way). What do you think? Does it make sense? |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-12-09 14:24 | unfa | New Issue | |
| 2016-12-19 23:05 | paul | Note Added: 0019188 | |
| 2016-12-20 09:31 | unfa | Note Added: 0019195 | |
| 2016-12-22 00:51 | x42 | Note Added: 0019210 | |
| 2016-12-23 09:00 | unfa | Note Added: 0019213 | |
| 2016-12-23 09:04 | unfa | Note Edited: 0019213 | |
| 2016-12-23 11:01 | x42 | Note Added: 0019214 | |
| 2016-12-23 12:07 | unfa | Note Added: 0019215 | |
| 2016-12-23 14:38 | paul | Note Added: 0019216 | |
| 2016-12-28 11:14 | unfa | Note Added: 0019223 | |
| 2016-12-28 11:16 | unfa | Note Edited: 0019223 |
