View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0010193ardourbugspublic2026-02-20 07:352026-02-20 21:55
Reporterlina Assigned To 
PrioritynormalSeveritycrashReproducibilityalways
Status newResolutionopen 
PlatformGNUOSLinuxOS Version(any)
Product Version9.0 
Summary0010193: Export process cannot handle different freewheel buffer size (pipewire)
DescriptionWhen using PipeWire-JACK, the buffer size is normally configured automatically depending on which device is driving the graph. Since freewheel mode changes the driver to the freewheel driver, this can also change the buffer size.

The export code uses the current buffer size to configure the export process, before switching freewheel on. When freewheel is enabled, the JACK buffer size callback is called, but by then it's too late as the export is already configured for the old buffer size. When the process callback is called with a larger process buffer size, it causes everything to crash. On my system, freewheel seems to default to a 1024 quantum, while I use 256 for my audio interface.

A release build shows an export error dialog, then crashes with a double free() when it is dismissed (sometimes, by the time this happens memory corruption has happened so sometimes you don't even get the dialog).

A debug build crashes here:

ardour-9.0.110: ../libs/ardour/export_graph_builder.cc:174: ARDOUR::samplecnt_t ARDOUR::ExportGraphBuilder::process(ARDOUR::samplecnt_t, bool): Assertion `samples <= process_buffer_samples' failed.

With that variable bumped up to 1024, it instead crashes here:

ardour-9.0.110: ../libs/ardour/session_export.cc:382: void ARDOUR::Session::process_export_fw(ARDOUR::pframes_t): Assertion `0' failed.

With that code removed to allow the exception to propagate, this is what happens:

terminate called after throwing an instance of 'AudioGrapher::Exception'
  what(): Exception thrown by AudioGrapher::Interleaver<float>: Too many samples given to an input

A workaround is `pw-metadata -n settings 0 clock.force-quantum 256` (or whatever) to force the buffer size to be globally constant, even for freewheel. `PIPEWIRE_QUANTUM=256/48000 ardour9` also works (PIPEWIRE_LATENCY is not sufficient).
Steps To Reproduce1. Configure PipeWire to use a fixed buffer size for an audio device, for example,

.config/wireplumber/wireplumber.conf.d/92-alsa-props.conf:

monitor.alsa.rules = [
{
  matches = [ { "node.description" = "Device name here" } ]
  actions = {
    update-props = {
      api.alsa.period-size = 256,
      api.alsa.headroom = 256,
      api.alsa.disable-batch = false,
      device.profile = "pro-audio",
    }
  }
},
]

2. Attempt to export a project
Additional InformationIf this is not supposed to work / too hard to implement, then at least the situation should be handled gracefully with an error informing the user to force a constant quantum size, instead of segfaulting in release builds.
TagsNo tags attached.

Activities

x42

2026-02-20 11:44

administrator   ~0029925

This is a bug in pipewire's JACK emulation.
(the problem does not exist with jackd 1 or jackd 2).

Please report it to https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/ Thank you

lina

2026-02-20 11:48

reporter   ~0029926

JACK allows changing buffer sizes at runtime, right? Although the behavior is different to JACK1 and JACK2, I don't see why this would be considered a bug, since there's nothing strictly incorrect about what PipeWire is doing. In general, having a larger buffer size for freewheel seems like a good idea, since it would speed up the export by reducing process cycle overhead.

(aside: due to personal reasons I am uncomfortable reporting PipeWire bugs myself at this time, so if you believe it should be changed on the PipeWire side, would it be possible for you to file the bug?)

paul

2026-02-20 17:16

administrator   ~0029933

JACK1/JACK2 do allow buffer size changes (Ardour's Audio/MIDI setup dialog even specifically includes a widget to change it), but such changes are sent as callback-notifications to all clients, so that they can adjust to them. It appears that PW is not doing this when switching to freewheeling.

lina

2026-02-20 19:25

reporter   ~0029947

PipeWire is sending the notification, as I mentioned ("the JACK buffer size callback is called", I checked, Ardour is getting it). The issue is that Ardour assumes the buffer size does not change when enabling freewheeling, as it checks the buffer size when starting the export process and assumes it does not change later.

This can be seen here: https://github.com/Ardour/ardour/blob/8db31ef9b6f8d1700dc51989c9d2186d99550592/libs/ardour/export_graph_builder.cc#L162 (this gets constructed *before* enabling freewheeling, and this causes the first assert to fire). I haven't tracked down the AudioGrapher::Interleaver one later, but I assume it's the same deal, something that queries the buffer size on construction and then assumes it does not change later.

paul

2026-02-20 19:46

administrator   ~0029950

Ah, I see now.

so this is not so much a "bug" in PW, but a different behavior that is entirely legal but trips us up ... really, the export graph can't be built until the first process() call during a freewheel

not clear if PW ought to get itself in line with JACK1/2 behavior or if we should reengineer the whole export graph design to workaround their change ....

paul

2026-02-20 21:55

administrator   ~0029964

from OFTC #pipewire

<las> wtay, is there a reason that PW's JACK implementation changes buffer size when entering freewheel ? neither JACK1 nor JACK2 do this ...
<las> wtay, https://tracker.ardour.org/view.php?id=10193
<wtay> it should do what jack1/2 does, I would need to investigate how it happens

Issue History

Date Modified Username Field Change
2026-02-20 07:35 lina New Issue
2026-02-20 11:44 x42 Note Added: 0029925
2026-02-20 11:48 lina Note Added: 0029926
2026-02-20 17:16 paul Note Added: 0029933
2026-02-20 19:25 lina Note Added: 0029947
2026-02-20 19:46 paul Note Added: 0029950
2026-02-20 21:55 paul Note Added: 0029964