Another thread got me interested in trying PipeWire + JACK again as the last time I tried it (last year) I would get freezing during export. Since then I’ve been happily using ALSA. When I tried PW+J again today I got the same freeze, but for the few ranges that did export I noticed it was much faster than using ALSA, so I’d like to try and get it working.
Here is a video of the issue with JACK - https://filedn.eu/larUQgXOwVjQdvpPaD96lHH/simplescreenrecorder-2022-07-04_21.17.36.mkv
If this works with ALSA and jackd, then it’s a pipewire bug.
Any reason why ALSA would be slower than PipeWire for exporting?
No.
But export speed is also buffersize dependent and PW by default uses huge buffers. Perhaps that also explains the crashes?
I’m using 512 with ALSA and I tried various settings with PW+JACK. I do occasionally get the same issue when using ALSA so perhaps it is a system configuration issue and I’m just seeing it more regularly with JACK.
After more testing I’m seeing the same issue with ALSA too only not as frequently. It exports 200-400 ranges before it freezes.
BTW I asked in the IRC but didn’t see a reply there. I want to commission a couple of additions to the exporter window, is this something you do?
Wow, that are a a lot of ranges. So this likely a different issue (as opposed to pipewire getting stuck on freewheeling switches).
Before export, could you open the Log Window, and see if there is an error message?
“TransportFSM::bad_transition …” or “Duplicate Transport State Event …” or “Cannot prepare transport for export” - Those have meanwhile been fixed for multi-range export.
Apparently you left the chat before I was awake.
Feature requests should usually go to tracker.ardour.org, but IRC helps to discuss things first.
The joy of exporting samples 
I see no error in the log when the freeze occurs with either ALSA or JACK/PW. Should I give Ardour 7 a try?
Yes, it might be worth a shot. Export has significantly changed (now there’s also MIDI stem export etc). – be sure to create a backup of the session before opening it in A7.
If the issue persists, could you share a session that causes it, or provide a step by step recipe how to reproduce the issue?
Thanks, I’ll give it a try and get back to you
My test with A7 seemed to be going well. But I got to about 270 ranges and then received this error (both with JACK/PW and ALSA):
I noticed 1 (possibly 2) other bugs with the nightly build. Do I report these or do I wait until A7 is released before reporting?
Is it a higher or lower buffer that makes the export faster? And is there a reason Ardour doesn’t use the fastest settings possible automatically when exporting?
Looks like I already made the feature request a couple of years ago and forgot about it.
As mentioned in the pre-release warning, IRC is best to discuss issues.
The feature request is a good one. Although since the list has individual checkboxes it is not trivial to allow range-selection toggles. It’ll be a bit of work to make this happen.
I guess I should pay more attention
I’ll send you a PM with a link to one of the projects I’m working on that I’m having the issue with.
Edit: @x42 How do I send a PM?
on IRC? /msg x42 ... but email also works fine robin@garues.org.
If you can reproduce the Memory Pool overflow, could you run a recently nightly version (7.0-pre0-3140 or later) from the commandline?
Ardour now prints the complete memory-pool content which may allow us to deduce why it fills up.
Ah cool, I’ll do this today.
I updated to 0-3140. This time I got a segfault and no error message.
Edit: One thing I just realised is the files loaded into these projects are all .flac, I don’t know if that makes a difference.
Thanks that perfectly explains it the issue!
“TransportStateChange” events are not handled while exporting, and just accumulate in the event-queue.
Those events are not relevant during export and can be ignored, but it looks like 2 are added for each export range (start, stop transport). After 512 such events have accumulated … boom.
Ah I see so my massive amount of ranges revealed the issue
Indeed. This should now be fixed and since 7.0-pre0-3144 you should be able to export as many ranges as you like.
Thanks for helping to track this down!