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. Furthermore, sound files created via [writesf~] and [loadbang] will have a 48k sampling rate, while files created one millisecond after loadbang will have a 44k1 rate. I include a minimal working example.
Is this behavior known?
best, Peter
Hi,
I can't really reproduce this with Pd 0.55.1 (Debian + Jack).
However, I *can* reproduce it with other settings, e.g. Windows + portaudio. I've already found the problem and will make a PR.
But I'm curious: are you really seeing this with Jack? How do you start Pd and how do you start the patch? Can you share your Pd preferences? The confusing part is that when you start Pd with Jack, and the server has a samplerate of 48000, Pd's samplerate should never be 44100 in the first place (the default samplerate is 48000).
Christof
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. Furthermore, sound files created via [writesf~] and [loadbang] will have a 48k sampling rate, while files created one millisecond after loadbang will have a 44k1 rate. I include a minimal working example.
Is this behavior known?
best, Peter
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/OYMU4KGLCG...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Christof,
danke, it's great you can reproduce it and are about to file a PR. I start jackd with 44k1 as $ jackd -t2000 -dalsa -r44100 -p512 -n3 -Xseq -D -Chw:PCH -Phw:PCH
~.pdsettings holds audioapi: 5 noaudioin: False audioindev1: 0 2 audioindevname1: JACK noaudioout: False audiooutdev1: 0 2 audiooutdevname1: JACK audiobuf: 25 rate: 44100 callback: 0 audioblocksize: 512
Pd is started from the CLI without the patch as only argument: $ pd writesf-samplerate-MWE.pd
best, Peter
Hi,
I can't really reproduce this with Pd 0.55.1 (Debian + Jack).
However, I *can* reproduce it with other settings, e.g. Windows + portaudio. I've already found the problem and will make a PR.
But I'm curious: are you really seeing this with Jack? How do you start Pd and how do you start the patch? Can you share your Pd preferences? The confusing part is that when you start Pd with Jack, and the server has a samplerate of 48000, Pd's samplerate should never be 44100 in the first place (the default samplerate is 48000).
Christof
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. Furthermore, sound files created via [writesf~] and [loadbang] will have a 48k sampling rate, while files created one millisecond after loadbang will have a 44k1 rate. I include a minimal working example.
Is this behavior known?
best, Peter
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/OYMU4KGLCG...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/VCEAVS3T4D...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Thanks!
I now realize that I misread your e-mail. I thought that your output is first 44100 and then 48000, while it's really the other way round. Now it all makes sense. (48000 is Pd's default samplerate and your jackd runs at 44100.)
As IOhannes correctly analyzed, the problem is that the "dsp" message only actually openes the audio device at the beginning of the next scheduler tick, but not immediately. That's why a [del 0] can be used as a (temporary) workaround. I already have a PR that fixes this. Will do some more regression testing and push later this evening. I'll let you know so you can test.
Christof
On 10.01.2025 09:04, Peter P. wrote:
Christof,
danke, it's great you can reproduce it and are about to file a PR. I start jackd with 44k1 as $ jackd -t2000 -dalsa -r44100 -p512 -n3 -Xseq -D -Chw:PCH -Phw:PCH
~.pdsettings holds audioapi: 5 noaudioin: False audioindev1: 0 2 audioindevname1: JACK noaudioout: False audiooutdev1: 0 2 audiooutdevname1: JACK audiobuf: 25 rate: 44100 callback: 0 audioblocksize: 512
Pd is started from the CLI without the patch as only argument: $ pd writesf-samplerate-MWE.pd
best, Peter
- Christof Ressi info@christofressi.com [2025-01-10 06:35]:
Hi,
I can't really reproduce this with Pd 0.55.1 (Debian + Jack).
However, I *can* reproduce it with other settings, e.g. Windows + portaudio. I've already found the problem and will make a PR.
But I'm curious: are you really seeing this with Jack? How do you start Pd and how do you start the patch? Can you share your Pd preferences? The confusing part is that when you start Pd with Jack, and the server has a samplerate of 48000, Pd's samplerate should never be 44100 in the first place (the default samplerate is 48000).
Christof
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. Furthermore, sound files created via [writesf~] and [loadbang] will have a 48k sampling rate, while files created one millisecond after loadbang will have a 44k1 rate. I include a minimal working example.
Is this behavior known?
best, Peter
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/OYMU4KGLCG...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/VCEAVS3T4D...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/5YOHLLOWPP...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
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.
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.
That's expected. If the backend has a fixed samplerate, Pd does not take the samplerate from the preferences, instead it starts with the default samplerate and then gets the actual samplerate from the backend. Makes totally sense to me.
In practice this doesn't matter because turning on DSP will immediately get the actual samplerate. (Well, after my fix :)
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¹.
That's weird indeed.
Turns out it's not as easy as I thought :/ There are some rough edge cases with the callback scheduler. I have some ideas, but I need to think them through and find an elegant solution. Stay tuned!
On 10.01.2025 14:23, Christof Ressi wrote:
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.
That's expected. If the backend has a fixed samplerate, Pd does not take the samplerate from the preferences, instead it starts with the default samplerate and then gets the actual samplerate from the backend. Makes totally sense to me.
In practice this doesn't matter because turning on DSP will immediately get the actual samplerate. (Well, after my fix :)
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¹.
That's weird indeed.
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/WEPRWPGKQ5...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Here you go: https://github.com/pure-data/pure-data/pull/2512.
I've tested systematically with JACK (Linux) and Portaudio (Windows) and did't find any regressions, but it would be great if others could test as well.
Christof
On 11.01.2025 01:03, Christof Ressi wrote:
Turns out it's not as easy as I thought :/ There are some rough edge cases with the callback scheduler. I have some ideas, but I need to think them through and find an elegant solution. Stay tuned!
On 10.01.2025 14:23, Christof Ressi wrote:
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.
That's expected. If the backend has a fixed samplerate, Pd does not take the samplerate from the preferences, instead it starts with the default samplerate and then gets the actual samplerate from the backend. Makes totally sense to me.
In practice this doesn't matter because turning on DSP will immediately get the actual samplerate. (Well, after my fix :)
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¹.
That's weird indeed.
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/WEPRWPGKQ5...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/5XPAZCYM2Y...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/