Re: [PD] DSP crashing - PD freezes.

[Denis Połeć]

Hi dan,
 I have tested the build. Unfortunately, I am still experiencing the same 
problem. Nothing works anymore after turning off the DSP.  
 I am on ARM - macOS 13.2. 

denis.

> Am 03.02.2023 um 21:17 schrieb hans w. koch :
> 
> hi dan,
> 
> thanks for putting this up!
> we had one student in a pd class this week, who was running recent pd on 
> M1/ventura and it solved her problems!
> we didn´t stress test it, but a patch with audio and midi was running fine.
> patch loading did take a good while though (couldn´t measure if it was 
> equally sluggish before)
> 
> before your fix, pd would not let her select an audio device or come to a 
> crawl on simple operations.
> 
> three cheers
> hans
> 
>> Am 02.02.2023 um 21:38 schrieb Dan Wilcox > >:
>> 
>> Howdy Theron,
>> 
>> can you try this build?
>> 
>> Pd-0.53-1-arm64-pa1970.zip 
>> 
>> 
>> It is for arm64 (Apple Silicon) and has Portaudio v19.7.0. I tried Miller's 
>> build and saw the same "unknown API" print on macOS 11. This build seems to 
>> work fine for me so, hopefully, it will for you.
>> 
>>> On Feb 1, 2023, at 7:20 AM, pd-list-requ...@lists.iem.at 
>>>  wrote:
>>> 
>>> Message: 2
>>> Date: Tue, 31 Jan 2023 22:12:08 -0800
>>> From: Theron Trowbridge >> >
>>> To: Miller Puckette mailto:m...@ucsd.edu>>
>>> Cc: "pd-list@lists.iem.at " 
>>> mailto:pd-list@lists.iem.at>>
>>> Subject: Re: [PD] DSP crashing - PD freezes.
>>> Message-ID:
>>> >> >
>>> Content-Type: text/plain; charset="utf-8"
>>> 
>>> Mac Mini M1, Ventura 13.1
>>> 
>>> It works better in some ways - the windows close and things quit when I ask
>>> them to. I don't have to force quit, and it doesn't seem to be messing up
>>> audio on the computer.
>>> 
>>> But when I turn on the DSP the output console just spams "unknown API" over
>>> and over again, and when I go into audios settings, I don't see my usual
>>> devices. The input device list has three options: "input device #1", "input
>>> device #2" and "input device #3" and there is no pull-down menu for output
>>> device, but only says "(same as input device)..." And I can't get it to
>>> make any sound.
>>> 
>>> When I turn off DSP, it outputs "sys_close_audio: unknown API 4"
>>> 
>>> 
>>> -Theron
>>> ^
>> 
>> 
>> Dan Wilcox
>> @danomatika 
>> danomatika.com 
>> robotcowboy.com 
>> 
>> 
>> 
>> ___
>> Pd-list@lists.iem.at  mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list
> 
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] DSP crashing - PD freezes.

[Dan Wilcox]

Do you have callbacks enabled? If so, disable the checkbox in the audio dialog.

enohp ym morf tnes
---
Dan Wilcox
danomatika.com
robotcowboy.com


> On Feb 4, 2023, at 9:54 AM, Denis Połeć  wrote:
> 
> 
> Hi dan,
>  I have tested the build. Unfortunately, I am still experiencing the same 
> problem. Nothing works anymore after turning off the DSP.  
>  I am on ARM - macOS 13.2. 
> 
> denis.
> 
>> Am 03.02.2023 um 21:17 schrieb hans w. koch :
>> 
>> hi dan,
>> 
>> thanks for putting this up!
>> we had one student in a pd class this week, who was running recent pd on 
>> M1/ventura and it solved her problems!
>> we didn´t stress test it, but a patch with audio and midi was running fine.
>> patch loading did take a good while though (couldn´t measure if it was 
>> equally sluggish before)
>> 
>> before your fix, pd would not let her select an audio device or come to a 
>> crawl on simple operations.
>> 
>> three cheers
>> hans
>> 
>>> Am 02.02.2023 um 21:38 schrieb Dan Wilcox :
>>> 
>>> Howdy Theron,
>>> 
>>> can you try this build?
>>> 
>>> Pd-0.53-1-arm64-pa1970.zip
>>> 
>>> It is for arm64 (Apple Silicon) and has Portaudio v19.7.0. I tried Miller's 
>>> build and saw the same "unknown API" print on macOS 11. This build seems to 
>>> work fine for me so, hopefully, it will for you.
>>> 
 On Feb 1, 2023, at 7:20 AM, pd-list-requ...@lists.iem.at wrote:
 
 Message: 2
 Date: Tue, 31 Jan 2023 22:12:08 -0800
 From: Theron Trowbridge 
 To: Miller Puckette 
 Cc: "pd-list@lists.iem.at" 
 Subject: Re: [PD] DSP crashing - PD freezes.
 Message-ID:

 Content-Type: text/plain; charset="utf-8"
 
 Mac Mini M1, Ventura 13.1
 
 It works better in some ways - the windows close and things quit when I ask
 them to. I don't have to force quit, and it doesn't seem to be messing up
 audio on the computer.
 
 But when I turn on the DSP the output console just spams "unknown API" over
 and over again, and when I go into audios settings, I don't see my usual
 devices. The input device list has three options: "input device #1", "input
 device #2" and "input device #3" and there is no pull-down menu for output
 device, but only says "(same as input device)..." And I can't get it to
 make any sound.
 
 When I turn off DSP, it outputs "sys_close_audio: unknown API 4"
 
 
 -Theron
 ^
>>> 
>>> 
>>> Dan Wilcox
>>> @danomatika
>>> danomatika.com
>>> robotcowboy.com
>>> 
>>> 
>>> 
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management -> 
>>> https://lists.puredata.info/listinfo/pd-list
>> 
>> ___
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> https://lists.puredata.info/listinfo/pd-list
> 
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] DSP crashing - PD freezes.

[Christof Ressi]

FWIW, the callback problem would be fixed with 
https://github.com/pure-data/pure-data/pull/1756


On 04.02.2023 10:04, Dan Wilcox wrote:
Do you have callbacks enabled? If so, disable the checkbox in the 
audio dialog.


enohp ym morf tnes
---
Dan Wilcox
danomatika.com
robotcowboy.com



On Feb 4, 2023, at 9:54 AM, Denis Połeć  wrote:


Hi dan,
 I have tested the build. Unfortunately, I am still experiencing the 
same problem. Nothing works anymore after turning off the DSP.

 I am on ARM - macOS 13.2.

denis.


Am 03.02.2023 um 21:17 schrieb hans w. koch :

hi dan,

thanks for putting this up!
we had one student in a pd class this week, who was running recent 
pd on M1/ventura and it solved her problems!
we didn´t stress test it, but a patch with audio and midi was 
running fine.
patch loading did take a good while though (couldn´t measure if it 
was equally sluggish before)


before your fix, pd would not let her select an audio device or come 
to a crawl on simple operations.


three cheers
hans


Am 02.02.2023 um 21:38 schrieb Dan Wilcox :

Howdy Theron,

can you try this build?

Pd-0.53-1-arm64-pa1970.zip 



It is for arm64 (Apple Silicon) and has Portaudio v19.7.0. I tried 
Miller's build and saw the same "unknown API" print on macOS 11. 
This build seems to work fine for me so, hopefully, it will for you.



On Feb 1, 2023, at 7:20 AM, pd-list-requ...@lists.iem.at wrote:

Message: 2
Date: Tue, 31 Jan 2023 22:12:08 -0800
From: Theron Trowbridge 
To: Miller Puckette 
Cc: "pd-list@lists.iem.at" 
Subject: Re: [PD] DSP crashing - PD freezes.
Message-ID:

Content-Type: text/plain; charset="utf-8"

Mac Mini M1, Ventura 13.1

It works better in some ways - the windows close and things quit 
when I ask
them to. I don't have to force quit, and it doesn't seem to be 
messing up

audio on the computer.

But when I turn on the DSP the output console just spams "unknown 
API" over
and over again, and when I go into audios settings, I don't see my 
usual
devices. The input device list has three options: "input device 
#1", "input
device #2" and "input device #3" and there is no pull-down menu 
for output
device, but only says "(same as input device)..." And I can't get 
it to

make any sound.

When I turn off DSP, it outputs "sys_close_audio: unknown API 4"


-Theron
^



Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management 
->https://lists.puredata.info/listinfo/pd-list___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] DSP crashing - PD freezes.

[Roman Haefeli]

On Sat, 2023-02-04 at 10:04 +0100, Dan Wilcox wrote:
> Do you have callbacks enabled? If so, disable the checkbox in the
> audio dialog.

So what's the deal with Callbacks on CoreAudio/macOS? On all the
combinations of Pd version and macOS version I tried, funny things
happen with callbacks enabled. Are there situations when using
callbacks  (on CoreAudio) bring any benefit? If so, what are those
situations? I think I understand how callbacks affect the interaction
between Pd and JACK when using JACK, but it's a bit opaque to me what
their purpose is when using CoreAudio. On Jack, using callbacks makes
Pd not add any additional latency on top of JACK's own latency. So,
which latency critical applications, I was hoping to affect latency in
similar way by using callbacks with CoreAudio.

Once I touch the callback toggle, I see Pd's CPU usage jumping to 100%
and there is no way to make go back. Even when I send `@callback 0`
using the mediasettings library, things go havoc. Once in that state,
it cannot be undone by toggling callback (or sending '@callback 1,
@callback 0' to [audiosettings]). Only a restart of Pd helps.

Is it expected that Pd uses 100% of core with callbacks enabled? Or
should I report a bug? What's the supposed benefit of that toggle?

Roman

 


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] DSP crashing - PD freezes.

[Dan Wilcox]

Here is a Pd 0.53-1 arm64 build with portaudio 19.7.0 *and* Christof's 
scheduler update. It may not be the fix for this issue, but probably worth 
trying:

Pd-0.53-1-arm64-schedulerfix.zip 


Likely, I need to update to macOS 13 myself and try things. It seems that many 
Pd mac users are much quicker to update than developers, hence they run into 
issues before we do. ;) This is true for many open source projects, though... 

> On Feb 4, 2023, at 10:04 AM, Dan Wilcox  wrote:
> 
> Do you have callbacks enabled? If so, disable the checkbox in the audio 
> dialog.
> 
> enohp ym morf tnes
> ---
> Dan Wilcox
> danomatika.com
> robotcowboy.com
> 
> 
>> On Feb 4, 2023, at 9:54 AM, Denis Połeć  wrote:
>> 
>> 
>> Hi dan,
>>  I have tested the build. Unfortunately, I am still experiencing the same 
>> problem. Nothing works anymore after turning off the DSP.  
>>  I am on ARM - macOS 13.2. 
>> 
>> denis.
>> 
>>> Am 03.02.2023 um 21:17 schrieb hans w. koch :
>>> 
>>> hi dan,
>>> 
>>> thanks for putting this up!
>>> we had one student in a pd class this week, who was running recent pd on 
>>> M1/ventura and it solved her problems!
>>> we didn´t stress test it, but a patch with audio and midi was running fine.
>>> patch loading did take a good while though (couldn´t measure if it was 
>>> equally sluggish before)
>>> 
>>> before your fix, pd would not let her select an audio device or come to a 
>>> crawl on simple operations.
>>> 
>>> three cheers
>>> hans
>>> 
 Am 02.02.2023 um 21:38 schrieb Dan Wilcox >>> >:
 
 Howdy Theron,
 
 can you try this build?
 
 Pd-0.53-1-arm64-pa1970.zip 
 
 
 It is for arm64 (Apple Silicon) and has Portaudio v19.7.0. I tried 
 Miller's build and saw the same "unknown API" print on macOS 11. This 
 build seems to work fine for me so, hopefully, it will for you.
 
> On Feb 1, 2023, at 7:20 AM, pd-list-requ...@lists.iem.at 
>  wrote:
> 
> Message: 2
> Date: Tue, 31 Jan 2023 22:12:08 -0800
> From: Theron Trowbridge  >
> To: Miller Puckette mailto:m...@ucsd.edu>>
> Cc: "pd-list@lists.iem.at " 
> mailto:pd-list@lists.iem.at>>
> Subject: Re: [PD] DSP crashing - PD freezes.
> Message-ID:
>    >
> Content-Type: text/plain; charset="utf-8"
> 
> Mac Mini M1, Ventura 13.1
> 
> It works better in some ways - the windows close and things quit when I 
> ask
> them to. I don't have to force quit, and it doesn't seem to be messing up
> audio on the computer.
> 
> But when I turn on the DSP the output console just spams "unknown API" 
> over
> and over again, and when I go into audios settings, I don't see my usual
> devices. The input device list has three options: "input device #1", 
> "input
> device #2" and "input device #3" and there is no pull-down menu for output
> device, but only says "(same as input device)..." And I can't get it to
> make any sound.
> 
> When I turn off DSP, it outputs "sys_close_audio: unknown API 4"
> 
> 
> -Theron
> ^
 
 
 Dan Wilcox
 @danomatika 
 danomatika.com 
 robotcowboy.com 
 
 
 
 ___
 Pd-list@lists.iem.at  mailing list
 UNSUBSCRIBE and account-management -> 
 https://lists.puredata.info/listinfo/pd-list 
 
>>> 
>>> ___
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management -> 
>>> https://lists.puredata.info/listinfo/pd-list
>> 


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] DSP crashing - PD freezes.

[Christof Ressi]

The callbacks option has always been broken in some way or another.

Please try my scheduler_fix branch: 
https://github.com/pure-data/pure-data/pull/1756. It would be great to 
get some feedback on this. Personally, I have been successfully using it 
on Windows for a few months, but I didn't really test on macOS or with 
Jack so far...


Christof

On 04.02.2023 10:59, Roman Haefeli wrote:

On Sat, 2023-02-04 at 10:04 +0100, Dan Wilcox wrote:

Do you have callbacks enabled? If so, disable the checkbox in the
audio dialog.

So what's the deal with Callbacks on CoreAudio/macOS? On all the
combinations of Pd version and macOS version I tried, funny things
happen with callbacks enabled. Are there situations when using
callbacks  (on CoreAudio) bring any benefit? If so, what are those
situations? I think I understand how callbacks affect the interaction
between Pd and JACK when using JACK, but it's a bit opaque to me what
their purpose is when using CoreAudio. On Jack, using callbacks makes
Pd not add any additional latency on top of JACK's own latency. So,
which latency critical applications, I was hoping to affect latency in
similar way by using callbacks with CoreAudio.

Once I touch the callback toggle, I see Pd's CPU usage jumping to 100%
and there is no way to make go back. Even when I send `@callback 0`
using the mediasettings library, things go havoc. Once in that state,
it cannot be undone by toggling callback (or sending '@callback 1,
@callback 0' to [audiosettings]). Only a restart of Pd helps.

Is it expected that Pd uses 100% of core with callbacks enabled? Or
should I report a bug? What's the supposed benefit of that toggle?

Roman

  


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list




___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] DSP crashing - PD freezes.

[Christof Ressi]

  Are there situations when using
callbacks  (on CoreAudio) bring any benefit?


With "callbacks" enabled, Pd runs directly on the audio thread. 
Generally, this is not really recommended because Pd itself is not 
realtime safe. Many operations block for an indeterminate amount of 
time, e.g. any call to "malloc()", network IO, file system operations, 
etc. The upside is that you can avoid some extra delay (see below).


With Pd's ringbuffer scheduler (= "callbacks" disabled), you can freely 
adjust the delay according to  your needs. (The "delay" parameter 
basically sets the size of the ringbuffer.) The price you pay is some 
extra delay (1x the hardware buffer size). To minimize this extra delay, 
you would set the /hardware buffer size/ as low as possible (e.g. 64 
samples) since the audio callback does nothing but transfer a bunch of 
samples. In this case, the extra latency would be as low as 64 samples, 
so nothing to worry about too much.


(The "callback" option can indeed make a noticable difference when using 
Jack with larger block sizes. Ideally you would just use the smallest 
Jack block size possible, but this might not work well for other Jack 
clients...)


As a side note: up until now, Pd's scheduler thread regularly goes to 
sleep for a fixed duration, so it may wake up a bit too late. If the 
delay setting is too low, this can lead to drop outs. With my 
"scheduler_fix" branch, the scheduler thread waits on a semaphore and is 
notified immediately when audio data is available. In my experience so 
far, this allows for lower "delay" settings than before.


Christof

On 04.02.2023 10:59, Roman Haefeli wrote:

On Sat, 2023-02-04 at 10:04 +0100, Dan Wilcox wrote:

Do you have callbacks enabled? If so, disable the checkbox in the
audio dialog.

So what's the deal with Callbacks on CoreAudio/macOS? On all the
combinations of Pd version and macOS version I tried, funny things
happen with callbacks enabled. Are there situations when using
callbacks  (on CoreAudio) bring any benefit? If so, what are those
situations? I think I understand how callbacks affect the interaction
between Pd and JACK when using JACK, but it's a bit opaque to me what
their purpose is when using CoreAudio. On Jack, using callbacks makes
Pd not add any additional latency on top of JACK's own latency. So,
which latency critical applications, I was hoping to affect latency in
similar way by using callbacks with CoreAudio.

Once I touch the callback toggle, I see Pd's CPU usage jumping to 100%
and there is no way to make go back. Even when I send `@callback 0`
using the mediasettings library, things go havoc. Once in that state,
it cannot be undone by toggling callback (or sending '@callback 1,
@callback 0' to [audiosettings]). Only a restart of Pd helps.

Is it expected that Pd uses 100% of core with callbacks enabled? Or
should I report a bug? What's the supposed benefit of that toggle?

Roman

  


___
Pd-list@lists.iem.at  mailing list
UNSUBSCRIBE and account-management 
->https://lists.puredata.info/listinfo/pd-list___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] DSP crashing - PD freezes.

[Denis Połeć]

This build works for me! 🎉 
(macOS 13.2 - ARM)
I have tested everything so far and have not detected any problems.
As far as I can tell, everything is going smoothly with the callback settings. 
However, I still haven't quite understood what it is for.

Thank you for your work in general! :)

denis

> Am 04.02.2023 um 11:26 schrieb Dan Wilcox :
> 
> Here is a Pd 0.53-1 arm64 build with portaudio 19.7.0 *and* Christof's 
> scheduler update. It may not be the fix for this issue, but probably worth 
> trying:
> 
> Pd-0.53-1-arm64-schedulerfix.zip 
> 
> 
> Likely, I need to update to macOS 13 myself and try things. It seems that 
> many Pd mac users are much quicker to update than developers, hence they run 
> into issues before we do. ;) This is true for many open source projects, 
> though... 
> 
>> On Feb 4, 2023, at 10:04 AM, Dan Wilcox > > wrote:
>> 
>> Do you have callbacks enabled? If so, disable the checkbox in the audio 
>> dialog.
>> 
>> enohp ym morf tnes
>> ---
>> Dan Wilcox
>> danomatika.com 
>> robotcowboy.com 
>> 
>> 
>>> On Feb 4, 2023, at 9:54 AM, Denis Połeć >> > wrote:
>>> 
>>> 
>>> Hi dan,
>>>  I have tested the build. Unfortunately, I am still experiencing the same 
>>> problem. Nothing works anymore after turning off the DSP.  
>>>  I am on ARM - macOS 13.2. 
>>> 
>>> denis.
>>> 
 Am 03.02.2023 um 21:17 schrieb hans w. koch >>> >:
 
 hi dan,
 
 thanks for putting this up!
 we had one student in a pd class this week, who was running recent pd on 
 M1/ventura and it solved her problems!
 we didn´t stress test it, but a patch with audio and midi was running fine.
 patch loading did take a good while though (couldn´t measure if it was 
 equally sluggish before)
 
 before your fix, pd would not let her select an audio device or come to a 
 crawl on simple operations.
 
 three cheers
 hans
 
> Am 02.02.2023 um 21:38 schrieb Dan Wilcox  >:
> 
> Howdy Theron,
> 
> can you try this build?
> 
> Pd-0.53-1-arm64-pa1970.zip 
> 
> 
> It is for arm64 (Apple Silicon) and has Portaudio v19.7.0. I tried 
> Miller's build and saw the same "unknown API" print on macOS 11. This 
> build seems to work fine for me so, hopefully, it will for you.
> 
>> On Feb 1, 2023, at 7:20 AM, pd-list-requ...@lists.iem.at 
>>  wrote:
>> 
>> Message: 2
>> Date: Tue, 31 Jan 2023 22:12:08 -0800
>> From: Theron Trowbridge > >
>> To: Miller Puckette mailto:m...@ucsd.edu>>
>> Cc: "pd-list@lists.iem.at " 
>> mailto:pd-list@lists.iem.at>>
>> Subject: Re: [PD] DSP crashing - PD freezes.
>> Message-ID:
>>  > >
>> Content-Type: text/plain; charset="utf-8"
>> 
>> Mac Mini M1, Ventura 13.1
>> 
>> It works better in some ways - the windows close and things quit when I 
>> ask
>> them to. I don't have to force quit, and it doesn't seem to be messing up
>> audio on the computer.
>> 
>> But when I turn on the DSP the output console just spams "unknown API" 
>> over
>> and over again, and when I go into audios settings, I don't see my usual
>> devices. The input device list has three options: "input device #1", 
>> "input
>> device #2" and "input device #3" and there is no pull-down menu for 
>> output
>> device, but only says "(same as input device)..." And I can't get it to
>> make any sound.
>> 
>> When I turn off DSP, it outputs "sys_close_audio: unknown API 4"
>> 
>> 
>> -Theron
>> ^
> 
> 
> Dan Wilcox
> @danomatika 
> danomatika.com 
> robotcowboy.com 
> 
> 
> 
> ___
> Pd-list@lists.iem.at  mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
 
 ___
 Pd-list@lists.iem.at  mailing list
 UNSUBSCRIBE and account-management -> 
 https://lists.puredata.info/listinfo/pd-list
>>> 
> 
> 
> Dan Wilcox
> @danomatika 
> danomatika.com 
> robotcowboy.com 
> 
> 
> 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE a

Re: [PD] DSP crashing - PD freezes.

[Dan Wilcox]

> On Feb 4, 2023, at 11:46 AM, Denis Połeć  wrote:
> 
> As far as I can tell, everything is going smoothly with the callback 
> settings. 
> However, I still haven't quite understood what it is for.

There was some discussion, maybe a year ago, about changing the name of this 
option and finding ways to make it clear what it does.

Copy/paste from Christof's email replay to Romain, to which you were not in CC:

>>  Are there situations when using
>> callbacks  (on CoreAudio) bring any benefit?
> 
> With "callbacks" enabled, Pd runs directly on the audio thread. 
> Generally, this is not really recommended because Pd itself is not 
> realtime safe. Many operations block for an indeterminate amount of 
> time, e.g. any call to "malloc()", network IO, file system operations, 
> etc. The upside is that you can avoid some extra delay (see below).
> 
> With Pd's ringbuffer scheduler (= "callbacks" disabled), you can freely 
> adjust the delay according to? your needs. (The "delay" parameter 
> basically sets the size of the ringbuffer.) The price you pay is some 
> extra delay (1x the hardware buffer size). To minimize this extra delay, 
> you would set the /hardware buffer size/ as low as possible (e.g. 64 
> samples) since the audio callback does nothing but transfer a bunch of 
> samples. In this case, the extra latency would be as low as 64 samples, 
> so nothing to worry about too much.
> 
> (The "callback" option can indeed make a noticable difference when using 
> Jack with larger block sizes. Ideally you would just use the smallest 
> Jack block size possible, but this might not work well for other Jack 
> clients...)
> 
> As a side note: up until now, Pd's scheduler thread regularly goes to 
> sleep for a fixed duration, so it may wake up a bit too late. If the 
> delay setting is too low, this can lead to drop outs. With my 
> "scheduler_fix" branch, the scheduler thread waits on a semaphore and is 
> notified immediately when audio data is available. In my experience so 
> far, this allows for lower "delay" settings than before.
> 
> Christof


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] DSP crashing - PD freezes.

[Theron Trowbridge]

It works on my Mac Mini M1 (upgraded to Ventura 13.2 last night) as well.
The callbacks setting doesn't seem to have any obvious effect, but I didn't
do anything too crazy with it.

Thanks for all the troubleshooting on this, it's a big help for me right
now!


-Theron
^


On Sat, Feb 4, 2023 at 3:22 AM Dan Wilcox  wrote:

>
> On Feb 4, 2023, at 11:46 AM, Denis Połeć  wrote:
>
> As far as I can tell, everything is going smoothly with the callback
> settings.
> However, I still haven't quite understood what it is for.
>
>
> There was some discussion, maybe a year ago, about changing the name of
> this option and finding ways to make it clear what it does.
>
> Copy/paste from Christof's email replay to Romain, to which you were not
> in CC:
>
>  Are there situations when using
> callbacks  (on CoreAudio) bring any benefit?
>
>
> With "callbacks" enabled, Pd runs directly on the audio thread.
> Generally, this is not really recommended because Pd itself is not
> realtime safe. Many operations block for an indeterminate amount of
> time, e.g. any call to "malloc()", network IO, file system operations,
> etc. The upside is that you can avoid some extra delay (see below).
>
> With Pd's ringbuffer scheduler (= "callbacks" disabled), you can freely
> adjust the delay according to? your needs. (The "delay" parameter
> basically sets the size of the ringbuffer.) The price you pay is some
> extra delay (1x the hardware buffer size). To minimize this extra delay,
> you would set the /hardware buffer size/ as low as possible (e.g. 64
> samples) since the audio callback does nothing but transfer a bunch of
> samples. In this case, the extra latency would be as low as 64 samples,
> so nothing to worry about too much.
>
> (The "callback" option can indeed make a noticable difference when using
> Jack with larger block sizes. Ideally you would just use the smallest
> Jack block size possible, but this might not work well for other Jack
> clients...)
>
> As a side note: up until now, Pd's scheduler thread regularly goes to
> sleep for a fixed duration, so it may wake up a bit too late. If the
> delay setting is too low, this can lead to drop outs. With my
> "scheduler_fix" branch, the scheduler thread waits on a semaphore and is
> notified immediately when audio data is available. In my experience so
> far, this allows for lower "delay" settings than before.
>
> Christof
>
>
> 
> Dan Wilcox
> @danomatika 
> danomatika.com
> robotcowboy.com
>
>
>
> ___
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] DSP crashing - PD freezes.

[Miller Puckette via Pd-list]

OK, I've uploaded the fix (I hope correctly) to msp.ucsd.edu/software.html,
as "0.53-2test1".  If that seems to work for everyone I'll rename it "0.53-2".

Thanks to all the help from several people (and to the portaudio folks!)

Miller
On Sat, Feb 04, 2023 at 03:09:21PM -0800, Theron Trowbridge wrote:
> It works on my Mac Mini M1 (upgraded to Ventura 13.2 last night) as well.
> The callbacks setting doesn't seem to have any obvious effect, but I didn't
> do anything too crazy with it.
> 
> Thanks for all the troubleshooting on this, it's a big help for me right
> now!
> 
> 
> -Theron
> ^
> 
> 
> On Sat, Feb 4, 2023 at 3:22 AM Dan Wilcox  wrote:
> 
> >
> > On Feb 4, 2023, at 11:46 AM, Denis Połeć  wrote:
> >
> > As far as I can tell, everything is going smoothly with the callback
> > settings.
> > However, I still haven't quite understood what it is for.
> >
> >
> > There was some discussion, maybe a year ago, about changing the name of
> > this option and finding ways to make it clear what it does.
> >
> > Copy/paste from Christof's email replay to Romain, to which you were not
> > in CC:
> >
> >  Are there situations when using
> > callbacks  (on CoreAudio) bring any benefit?
> >
> >
> > With "callbacks" enabled, Pd runs directly on the audio thread.
> > Generally, this is not really recommended because Pd itself is not
> > realtime safe. Many operations block for an indeterminate amount of
> > time, e.g. any call to "malloc()", network IO, file system operations,
> > etc. The upside is that you can avoid some extra delay (see below).
> >
> > With Pd's ringbuffer scheduler (= "callbacks" disabled), you can freely
> > adjust the delay according to? your needs. (The "delay" parameter
> > basically sets the size of the ringbuffer.) The price you pay is some
> > extra delay (1x the hardware buffer size). To minimize this extra delay,
> > you would set the /hardware buffer size/ as low as possible (e.g. 64
> > samples) since the audio callback does nothing but transfer a bunch of
> > samples. In this case, the extra latency would be as low as 64 samples,
> > so nothing to worry about too much.
> >
> > (The "callback" option can indeed make a noticable difference when using
> > Jack with larger block sizes. Ideally you would just use the smallest
> > Jack block size possible, but this might not work well for other Jack
> > clients...)
> >
> > As a side note: up until now, Pd's scheduler thread regularly goes to
> > sleep for a fixed duration, so it may wake up a bit too late. If the
> > delay setting is too low, this can lead to drop outs. With my
> > "scheduler_fix" branch, the scheduler thread waits on a semaphore and is
> > notified immediately when audio data is available. In my experience so
> > far, this allows for lower "delay" settings than before.
> >
> > Christof
> >
> >
> > 
> > Dan Wilcox
> > @danomatika 
> >  >  >
> > danomatika.com
> > robotcowboy.com
> >
> >
> >
> > ___
> > Pd-list@lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> > https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!FqFnjr76hFtszjAnbA1NsOhAiVYr40Oy4ngNvn9Zt0ponRrBuOKI_4wLu9ailljbiTbrAq-It2ekk46IWB6f5MQ$
> >  
> >



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] DSP crashing - PD freezes.

[Theron Trowbridge]

Works for me


Thanks!

-Theron
^


On Sat, Feb 4, 2023 at 6:15 PM Miller Puckette  wrote:

> OK, I've uploaded the fix (I hope correctly) to msp.ucsd.edu/software.html
> ,
> as "0.53-2test1".  If that seems to work for everyone I'll rename it
> "0.53-2".
>
> Thanks to all the help from several people (and to the portaudio folks!)
>
> Miller
> On Sat, Feb 04, 2023 at 03:09:21PM -0800, Theron Trowbridge wrote:
> > It works on my Mac Mini M1 (upgraded to Ventura 13.2 last night) as well.
> > The callbacks setting doesn't seem to have any obvious effect, but I
> didn't
> > do anything too crazy with it.
> >
> > Thanks for all the troubleshooting on this, it's a big help for me right
> > now!
> >
> >
> > -Theron
> > ^
> >
> >
> > On Sat, Feb 4, 2023 at 3:22 AM Dan Wilcox  wrote:
> >
> > >
> > > On Feb 4, 2023, at 11:46 AM, Denis Połeć 
> wrote:
> > >
> > > As far as I can tell, everything is going smoothly with the callback
> > > settings.
> > > However, I still haven't quite understood what it is for.
> > >
> > >
> > > There was some discussion, maybe a year ago, about changing the name of
> > > this option and finding ways to make it clear what it does.
> > >
> > > Copy/paste from Christof's email replay to Romain, to which you were
> not
> > > in CC:
> > >
> > >  Are there situations when using
> > > callbacks  (on CoreAudio) bring any benefit?
> > >
> > >
> > > With "callbacks" enabled, Pd runs directly on the audio thread.
> > > Generally, this is not really recommended because Pd itself is not
> > > realtime safe. Many operations block for an indeterminate amount of
> > > time, e.g. any call to "malloc()", network IO, file system operations,
> > > etc. The upside is that you can avoid some extra delay (see below).
> > >
> > > With Pd's ringbuffer scheduler (= "callbacks" disabled), you can freely
> > > adjust the delay according to? your needs. (The "delay" parameter
> > > basically sets the size of the ringbuffer.) The price you pay is some
> > > extra delay (1x the hardware buffer size). To minimize this extra
> delay,
> > > you would set the /hardware buffer size/ as low as possible (e.g. 64
> > > samples) since the audio callback does nothing but transfer a bunch of
> > > samples. In this case, the extra latency would be as low as 64 samples,
> > > so nothing to worry about too much.
> > >
> > > (The "callback" option can indeed make a noticable difference when
> using
> > > Jack with larger block sizes. Ideally you would just use the smallest
> > > Jack block size possible, but this might not work well for other Jack
> > > clients...)
> > >
> > > As a side note: up until now, Pd's scheduler thread regularly goes to
> > > sleep for a fixed duration, so it may wake up a bit too late. If the
> > > delay setting is too low, this can lead to drop outs. With my
> > > "scheduler_fix" branch, the scheduler thread waits on a semaphore and
> is
> > > notified immediately when audio data is available. In my experience so
> > > far, this allows for lower "delay" settings than before.
> > >
> > > Christof
> > >
> > >
> > > 
> > > Dan Wilcox
> > > @danomatika <
> https://urldefense.com/v3/__http://twitter.com/danomatika__;!!Mih3wA!FqFnjr76hFtszjAnbA1NsOhAiVYr40Oy4ngNvn9Zt0ponRrBuOKI_4wLu9ailljbiTbrAq-It2ekk46Iu51F4FI$
> >
> > > danomatika.com
> > > robotcowboy.com
> > >
> > >
> > >
> > > ___
> > > Pd-list@lists.iem.at mailing list
> > > UNSUBSCRIBE and account-management ->
> > >
> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-list__;!!Mih3wA!FqFnjr76hFtszjAnbA1NsOhAiVYr40Oy4ngNvn9Zt0ponRrBuOKI_4wLu9ailljbiTbrAq-It2ekk46IWB6f5MQ$
> > >
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list