On 10/01/2025 00:13, Peter P. wrote:
Hi list,
on Debian Linux with jackd running at 44100 it seems that [samplerate~] when [loadbang]ed will report a rate of 48000. But if this loadbang is [delay]ed by 1msec it will report the correct rate of 44100.
i can reproduce this. (and btw, a [delay 0] is sufficient to get the correct samplerate)
i wouldn't call it a "race condition" though, it's just that Pd initializes the audio backend after sending out the loadbangs.
christof's PR will probably fix this.
in general, the audio backend might impose a samplerate different from what you (or Pd) expected. that could lead to a behaviour similar to what you describe, though totally expected. e.g. if you have two fixed-samplerate soundcards, one of them running at 48k and the other at 44.1k, and you switch from one to the other; then [samplerate~] should report different rates depending on when you bang it. in order to work around this, you should probably query [samplerate~] when the DSP gets (re)started, rather than with loadbang.
however, the the really weird thing about this is actually that the samplerate passed via the preferences (and cmdline-flags) is ignored. i would expect Pd to honour those settings in the first place (defaulting to 48000), and only change it if the audio backend demands otherwise.
using your settings-file (which sets 44100) and starting Pd *without* sound, but with (or without) an explicit "-r44100" i get:
pd -nosound -r 44100
i get: @loadbang: 48000 @loadbang+0: 48000 @loadbang+1: 48000
hecking the audio-settings, i see that Pd claims to still use JACK as the backend (though - as expected - there's no sound), even if no JACK is actually running¹.
so yes, there are things to be fixed.
gmsadr IOhannes
¹ all my JACK experiments now are a bit complicated, as i have PipeWire running and it's the default JACK implementation. but uisng LD_LIBRARY_PATH= to force the "real" JACK onto Pd (and jackd), seems to work OK.