View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010193 | ardour | bugs | public | 2026-02-20 07:35 | 2026-02-20 11:48 |
| Reporter | lina | Assigned To | |||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | GNU | OS | Linux | OS Version | (any) |
| Product Version | 9.0 | ||||
| Summary | 0010193: Export process cannot handle different freewheel buffer size (pipewire) | ||||
| Description | When 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 Reproduce | 1. 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 Information | If 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. | ||||
| Tags | No tags attached. | ||||
|
|
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 |
|
|
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?) |
