JACK Pa_OpenStream ignores framesPerBuffer parameter

[Be-ing]

Pa_OpenStream has a framesPerBuffer parameter to set the buffer size:

 @param framesPerBuffer The number of frames passed to the stream callback
 function, or the preferred block granularity for a blocking read/write stream.
 The special value paFramesPerBufferUnspecified (0) may be used to request that
 the stream callback will receive an optimal (and possibly varying) number of
 frames based on host requirements and the requested latency settings.
 Note: With some host APIs, the use of non-zero framesPerBuffer for a callback
 stream may introduce an additional layer of buffering which could introduce
 additional latency. PortAudio guarantees that the additional latency
 will be kept to the theoretical minimum however, it is strongly recommended
 that a non-zero framesPerBuffer value only be used when your algorithm
 requires a fixed number of frames per stream callback.

JACK has a function to set this: jack_set_buffer_size. However, the JACK host API currently ignores the framesPerBuffer parameter:

    if( framesPerBuffer != paFramesPerBufferUnspecified )
    {
        /* Jack operates with power of two buffers, and we don't support non-integer buffer adaption (yet) */
        /*UNLESS( !(framesPerBuffer & (framesPerBuffer - 1)), paBufferTooBig );*/  /* TODO: Add descriptive error code? */
    }

[RossBencina]

So long as the buffer processor is configured to use framesPerBuffer as the user buffer size I don't think there is a problem here. The framesPerBuffer parameter controls the size of the buffer passed to the user callback, it does not have to be related to the native API buffer size (jack_set_buffer_size in this case). Presumably this is by design.

[Be-ing]

What I am trying to achieve here is full functionality with PipeWire using the JACK API rather than having to write a whole new host API. With jackd, the user sets a buffer size when configuring the server. PipeWire by contrast sets the buffer size dynamically to the lowest buffer sizes requested by any active application. That requires an application to set the buffer size though.

[RossBencina]

If I understand correctly, what you want is when using the JACK API with PipeWire (but not with JACK server) PortAudio should set the buffer size. Is that correct? Seems reasonable, so long as there is a way to detect that the server is in-fact a PipeWire server.

[philburk]

The old comment in the code about not supporting buffer size that are not powers-of-2 may be obsolete. The PortAudio buffer adaptation code should handle that.

[Be-ing]

so long as there is a way to detect that the server is in-fact a PipeWire server

Why is that needed?

[RossBencina]

Why is that needed?

Because we can't (and don't want to) set the buffer size for a native JACK server. Unless I misunderstand, what you're proposing is:

• native JACK: use the jack server buffer size. (current behavior)
• pipewire: set the buffer size to callback framesPerBuffer