I’m having trouble with the transport stopping immediately after starting. If I switch to JACK as the transport master the transport works, but cues don’t work.
I’ve added my notes to an existing bug report at 0009329: cannot have two events of type TransportStateChange at the same sample - MantisBT where @anahata reported their similar/identical issue, but their issue seemed to resolve itself according to [ERROR]: Session: cannot have two events of type TransportStateChange at the same sample (9978059) (where @dftar had the same issues).
I’m posting here mainly for additional eyes and also because mantis doesn’t seem to get indexed by google (or doesn’t index well).
Are others running OK with v7.x Ardour on pipewire as jack client, and using cues?
Details:
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 deadlock: JACK port-registration blocks on graph-order callback - Ardour hangs (#3183) · Issues · PipeWire / pipewire · GitLab. 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
}
