View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009329 | ardour | bugs | public | 2023-05-09 09:01 | 2023-05-31 09:11 |
| Reporter | al f | Assigned To | |||
| Priority | low | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | Arch | OS | Linux | OS Version | (any) |
| Product Version | 7.4 | ||||
| Summary | 0009329: cannot have two events of type TransportStateChange at the same sample | ||||
| Description | When playing back recorded / edited audio, if changing playhead position by using arrow keys, the red warning light is lit and messages like these populate the log: 2023-05-09T10:38:49 [ERROR]: bad transition, current state = DeclickToLocate/WaitingForButler/Forwards event = LocateDone 2023-05-09T10:38:49 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (6049280). 2023-05-09T10:38:49 [ERROR]: bad transition, current state = DeclickToLocate/WaitingForButler/Forwards event = LocateDone 2023-05-09T10:38:49 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (5977280). 2023-05-09T10:49:22 [ERROR]: bad transition, current state = DeclickToLocate/WaitingForButler/Forwards event = LocateDone 2023-05-09T10:49:22 [ERROR]: bad transition, current state = DeclickToLocate/WaitingForButler/Forwards event = LocateDone 2023-05-09T10:49:22 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (7585280). 2023-05-09T10:49:22 [ERROR]: bad transition, current state = DeclickToLocate/WaitingForButler/Forwards event = LocateDone 2023-05-09T10:49:22 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (7537280). 2023-05-09T10:49:22 [ERROR]: bad transition, current state = DeclickToLocate/WaitingForButler/Forwards event = LocateDone 2023-05-09T10:49:22 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (7513280). The playhead skips backwards in jumps as expected, playback is not affected and there seems to be no other unwanted events. | ||||
| Steps To Reproduce | 1. Import or record audio 2. Play back audio 3. while playing back, press and hold LEFT or RIGHT 4. Observe the small light indicating error logs / warning turn on, red. | ||||
| Tags | Editor, playhead | ||||
|
|
I am experiencing what appears to be the same issue. In Ardour 7.40 and 7.30 I can open a new session, press "Play" and and the transport buttons appear to respond but immediately revert to stopped (sometimes too fast for me to notice, but always "immediately", by which I mean inside of 200ms). On the first press of play, no log output is produced. If I press play again (and any subsequent time) I get output of: ``` 2023-05-31T17:14:21 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (2048). 2023-05-31T17:14:26 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (2048). 2023-05-31T17:14:26 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (2048). ``` My pipewire quant is 1024, and the above is if the playhead is at sample 0, I can reposition the playhead, and pressing play the first time outputs no messages (and transport stops "immediately"), and on subsequent presses of play it outputs: ``` 2023-05-31T17:18:06 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (866048). 2023-05-31T17:18:12 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (866048). 2023-05-31T17:18:12 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (866048). 2023-05-31T17:18:13 [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (866048). ``` The playhead for the output above was at sample 864000, so the sample noted in the output appears to be playheadPosition + 2048, so perhaps playheadPosition+ ( 2 x bufferSize ). I'm on Debian Sid, running Ardour from the official Ardour builds (not distro packages). I am connecting as a jack client to Pipewire, which I just upgraded to 0.3.71 using packages from Debian's experimental repos - I did that because I was experiencing the lockup when adding a midi track issue from https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/3183. Previously I have been experiencing strange issues with routing (both midi and audio ports not connecting properly within Ardour) which I think there were some likely fixes for in my upgrade from 0.3.65. If I go into "Transport Masters" and set JACK as the master, AND click the External Positional Sync button (so it goes from "Int." to "JACK") the transport will now roll on command, both from within Ardour or by using the `jack-transport` cli utility. Seeking is weird though, if I click in the timeline the playhead jumps to sample 0, but transport will roll from the clicked position when started. If I click twice (in *exactly* the same location) the playhead jumps to 0 on first click, then to the chosen spot. However in this case hitting play doesn't show the transport rolling, but hitting stop relocates the playhead to somewhere forward of that location. Super weird. If I add an audio clip to a track in the cue window and click the "play" button next to the slot, the transport no longer rolls and I get the same error messages as above in the Log window. The transport won't roll again until I clear the slot, at which point the transport rolls immediately (without hitting play) as if it were blocked waiting on the slot. Could this be an issue related to how the cue feature integrates with the timeline / transport? Just an idea. FWIW, previous to upgrading pipewire I was having issues with cues being a bit finicky about stopping and starting, if I recall correctly it would do things like a slot wouldn't stop playing, or once I did get it to I couldn't start others etc. I didn't get a handle on exactly what interaction sequences would cause or resolve that, I was creating so just instinctively clicked around until things worked again. It happened frequently enough that it felt like I was possibly not using it correctly. I'm using wireplumber 0.4.12 (from debian) as the session manager. Kernel is 6.1.27-1. I don't see anything audio/ardour related or coincident in dmesg or journalctl. In `~/.config/pipewire/pipewire.conf.d/99-ajg-custom.conf` I have: ``` context.properties = { ## Properties for the DSP configuration. default.clock.rate = 48000 default.clock.allowed-rates = [ 48000 ] default.clock.quantum = 1024 default.clock.min-quantum = 16 #default.clock.max-quantum = 2048 #default.clock.quantum-limit = 8192 #default.video.width = 640 #default.video.height = 480 #default.video.rate.num = 25 #default.video.rate.denom = 1 # settings.check-quantum = true settings.check-rate = true # # These overrides are only applied when running in a vm. vm.overrides = { default.clock.min-quantum = 1024 } # AJG - might help ardour midi issues alsa.seq.name = "a2j" } ``` And in `~/.config/pipewire/jack.conf.d/99-ajg-custom.conf` I have: ``` jack.properties = { node.latency = 1024/48000 node.rate = 1/48000 node.quantum = 1024/48000 node.lock-quantum = true #node.force-quantum = 0 #jack.show-monitor = true #jack.merge-monitor = true #jack.short-name = false #jack.filter-name = false #jack.filter-char = " " # # allow: Don't restrict self connect requests # fail-external: Fail self connect requests to external ports only # ignore-external: Ignore self connect requests to external ports only # fail-all: Fail all self connect requests # ignore-all: Ignore all self connect requests #jack.self-connect-mode = allow #jack.locked-process = true #jack.default-as-system = false #jack.fix-midi-events = true #jack.global-buffer-size = false # <https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Config-JACK> # Enable this to have the default sink and source show as system:capture_2 etc. # jack.default-as-system = true jack.short-name = true # AJG: Stops it from re-writing note-on-velocity-zero messages # into note-offs (which breaks the MotorMix ping/echo). jack.fix-midi-events = false } ``` |
|
|
Further experimenting (now with 7.4.163 from nightlies) reveals: - If I have an empty, new session, with the default “Int” sync set, the transport won’t roll. - If I add a midi track OR an audio track, AND in the cue window add any clip to a slot, the transport will now roll (either just rolling the timeline with no cues triggered, or by hitting the play button next to the slot. So it seems like the internal transport won’t roll unless there’s a clip loaded into a slot somewhere, regardless of whether that cue is part of playback or not. Turning off the “Play Cues” button doesn’t alter the behaviour. |
