Re: samplerate~ race condition?

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 <[email protected]> [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
>>>
>>> ---
>>> [email protected] - the Pure Data mailinglist
>>> https://lists.iem.at/hyperkitty/list/[email protected]/message/OYMU4KGLCG2FGLTRLJPYD36UESIDLJC6/
>>>
>>> To unsubscribe send an email to [email protected] mailing list
>>> UNSUBSCRIBE and account-management -> https://lists.iem.at/
>> ---
>> [email protected] - the Pure Data mailinglist
>> https://lists.iem.at/hyperkitty/list/[email protected]/message/VCEAVS3T4DNJJEAPAMNCQ4I3I5SKFVB5/
>>
>> To unsubscribe send an email to [email protected] mailing list
>> UNSUBSCRIBE and account-management -> https://lists.iem.at/
>>
> ---
> [email protected] - the Pure Data mailinglist
> https://lists.iem.at/hyperkitty/list/[email protected]/message/5YOHLLOWPPHIM2FBG2SAOJV4IXKIL7JU/
>
> To unsubscribe send an email to [email protected] mailing list
> UNSUBSCRIBE and account-management -> https://lists.iem.at/
>

---
[email protected] - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/[email protected]/message/LXFT4ALWHRQB4AKAAE7ROGV3VBQHX73A/

To unsubscribe send an email to [email protected] mailing list
UNSUBSCRIBE and account-management -> https://lists.iem.at/