Howdy Theron,
can you try this build?
Pd-0.53-1-arm64-pa1970.zip http://docs.danomatika.com/pdbuilds/0.53/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-request@lists.iem.at wrote:
Message: 2 Date: Tue, 31 Jan 2023 22:12:08 -0800 From: Theron Trowbridge <theron.trowbridge@gmail.com mailto:theron.trowbridge@gmail.com> To: Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> Cc: "pd-list@lists.iem.at mailto:pd-list@lists.iem.at" <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: Re: [PD] DSP crashing - PD freezes. Message-ID: <CAD+3VoPwLt5CT=aS5oz95b0Bb=5DwNft+JGW5z3tDUqK+Q42jg@mail.gmail.com mailto:CAD+3VoPwLt5CT=aS5oz95b0Bb=5DwNft+JGW5z3tDUqK+Q42jg@mail.gmail.com> 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 http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
This seems to work fine. No error messages in the console, my audio devices show up normally, and I get expected sounds.
It does seem to trigger some alert sounds, though I don't know what for and can't be certain it was not another running app.
Thanks!
-Theron ^
On Thu, Feb 2, 2023 at 12:38 PM Dan Wilcox danomatika@gmail.com wrote:
Howdy Theron,
can you try this build?
Pd-0.53-1-arm64-pa1970.zip http://docs.danomatika.com/pdbuilds/0.53/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-request@lists.iem.at wrote:
Message: 2 Date: Tue, 31 Jan 2023 22:12:08 -0800 From: Theron Trowbridge theron.trowbridge@gmail.com To: Miller Puckette msp@ucsd.edu Cc: "pd-list@lists.iem.at" pd-list@lists.iem.at Subject: Re: [PD] DSP crashing - PD freezes. Message-ID: CAD+3VoPwLt5CT=aS5oz95b0Bb=5DwNft+JGW5z3tDUqK+Q42jg@mail.gmail.com 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 http://twitter.com/danomatika danomatika.com robotcowboy.com
Thanks for the confirmation. Can you explain more about triggering "alert sounds"? Do you mean there are security popoups when the app is run, ie. "Pd would like to access your Microphone.." etc?
On Feb 2, 2023, at 10:36 PM, Theron Trowbridge theron.trowbridge@gmail.com wrote:
This seems to work fine. No error messages in the console, my audio devices show up normally, and I get expected sounds.
It does seem to trigger some alert sounds, though I don't know what for and can't be certain it was not another running app.
Thanks!
-Theron ^
On Thu, Feb 2, 2023 at 12:38 PM Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> wrote: Howdy Theron,
can you try this build?
Pd-0.53-1-arm64-pa1970.zip http://docs.danomatika.com/pdbuilds/0.53/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-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
Message: 2 Date: Tue, 31 Jan 2023 22:12:08 -0800 From: Theron Trowbridge <theron.trowbridge@gmail.com mailto:theron.trowbridge@gmail.com> To: Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> Cc: "pd-list@lists.iem.at mailto:pd-list@lists.iem.at" <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: Re: [PD] DSP crashing - PD freezes. Message-ID: <CAD+3VoPwLt5CT=aS5oz95b0Bb=5DwNft+JGW5z3tDUqK+Q42jg@mail.gmail.com mailto:CAD+3VoPwLt5CT=aS5oz95b0Bb=5DwNft+JGW5z3tDUqK+Q42jg@mail.gmail.com> 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 http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
I figured it out - it was not Pd or the computer. It was my phone alerting me that its microphone was connected to the Mac. Ventura lets you use an iOS device as a mic or camera. I'm guessing it woke up when portaudio was initiated.
-Theron ^
On Thu, Feb 2, 2023 at 2:09 PM Dan Wilcox danomatika@gmail.com wrote:
Thanks for the confirmation. Can you explain more about triggering "alert sounds"? Do you mean there are security popoups when the app is run, ie. "Pd would like to access your Microphone.." etc?
On Feb 2, 2023, at 10:36 PM, Theron Trowbridge < theron.trowbridge@gmail.com> wrote:
This seems to work fine. No error messages in the console, my audio devices show up normally, and I get expected sounds.
It does seem to trigger some alert sounds, though I don't know what for and can't be certain it was not another running app.
Thanks!
-Theron ^
On Thu, Feb 2, 2023 at 12:38 PM Dan Wilcox danomatika@gmail.com wrote:
Howdy Theron,
can you try this build?
Pd-0.53-1-arm64-pa1970.zip http://docs.danomatika.com/pdbuilds/0.53/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-request@lists.iem.at wrote:
Message: 2 Date: Tue, 31 Jan 2023 22:12:08 -0800 From: Theron Trowbridge theron.trowbridge@gmail.com To: Miller Puckette msp@ucsd.edu Cc: "pd-list@lists.iem.at" pd-list@lists.iem.at Subject: Re: [PD] DSP crashing - PD freezes. Message-ID: CAD+3VoPwLt5CT=aS5oz95b0Bb=5DwNft+JGW5z3tDUqK+Q42jg@mail.gmail.com 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 http://twitter.com/danomatika danomatika.com robotcowboy.com
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com robotcowboy.com
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 danomatika@gmail.com:
Howdy Theron,
can you try this build?
Pd-0.53-1-arm64-pa1970.zip http://docs.danomatika.com/pdbuilds/0.53/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-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
Message: 2 Date: Tue, 31 Jan 2023 22:12:08 -0800 From: Theron Trowbridge <theron.trowbridge@gmail.com mailto:theron.trowbridge@gmail.com> To: Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> Cc: "pd-list@lists.iem.at mailto:pd-list@lists.iem.at" <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: Re: [PD] DSP crashing - PD freezes. Message-ID: <CAD+3VoPwLt5CT=aS5oz95b0Bb=5DwNft+JGW5z3tDUqK+Q42jg@mail.gmail.com mailto:CAD+3VoPwLt5CT=aS5oz95b0Bb=5DwNft+JGW5z3tDUqK+Q42jg@mail.gmail.com> 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 http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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 hansw.koch@gmail.com:
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 <danomatika@gmail.com mailto:danomatika@gmail.com>:
Howdy Theron,
can you try this build?
Pd-0.53-1-arm64-pa1970.zip http://docs.danomatika.com/pdbuilds/0.53/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-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
Message: 2 Date: Tue, 31 Jan 2023 22:12:08 -0800 From: Theron Trowbridge <theron.trowbridge@gmail.com mailto:theron.trowbridge@gmail.com> To: Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> Cc: "pd-list@lists.iem.at mailto:pd-list@lists.iem.at" <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: Re: [PD] DSP crashing - PD freezes. Message-ID: <CAD+3VoPwLt5CT=aS5oz95b0Bb=5DwNft+JGW5z3tDUqK+Q42jg@mail.gmail.com mailto:CAD+3VoPwLt5CT=aS5oz95b0Bb=5DwNft+JGW5z3tDUqK+Q42jg@mail.gmail.com> 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 http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-list@lists.iem.at mailto: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
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ć denis.polec@gmail.com 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 hansw.koch@gmail.com:
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 danomatika@gmail.com:
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-request@lists.iem.at wrote:
Message: 2 Date: Tue, 31 Jan 2023 22:12:08 -0800 From: Theron Trowbridge theron.trowbridge@gmail.com To: Miller Puckette msp@ucsd.edu Cc: "pd-list@lists.iem.at" pd-list@lists.iem.at Subject: Re: [PD] DSP crashing - PD freezes. Message-ID: CAD+3VoPwLt5CT=aS5oz95b0Bb=5DwNft+JGW5z3tDUqK+Q42jg@mail.gmail.com 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
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ć denis.polec@gmail.com 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 hansw.koch@gmail.com:
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 danomatika@gmail.com:
Howdy Theron,
can you try this build?
Pd-0.53-1-arm64-pa1970.zip http://docs.danomatika.com/pdbuilds/0.53/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-request@lists.iem.at wrote:
Message: 2 Date: Tue, 31 Jan 2023 22:12:08 -0800 From: Theron Trowbridge theron.trowbridge@gmail.com To: Miller Puckette msp@ucsd.edu Cc: "pd-list@lists.iem.at" pd-list@lists.iem.at Subject: Re: [PD] DSP crashing - PD freezes. Message-ID: CAD+3VoPwLt5CT=aS5oz95b0Bb=5DwNft+JGW5z3tDUqK+Q42jg@mail.gmail.com 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 http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://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
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
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 0using 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
On Sat, 2023-02-04 at 11:32 +0100, Christof Ressi wrote:
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
I rebased your PR to current master with new portaudio version so that I get the benefits of both. Compiled and tested on Ubuntu 22.04 (amd64) and macOS 12.6.3 (had to upgrade from 10.14.6 because brew complained).
Works in all tested configurations for me:
- CoreAudio with and without callbacks
- Jack with and without callbacks (Linux and macOS)
I wasn't able to get the high CPU usage with that build.
And now - this sounds a bit crazy - while testing the scheduling_fix build, the official releases (0.53-1, 0.52-2, etc.) didn't exhibit the high CPU usage anymore. Later, after some more testing, it happened again though, but not with the scheduling_fix build. It's really difficult to determine exactly what circumstances lead to the high CPU usage. It's as if it's possible to "taint" CoreAudio and the scheduling_fix somehow "untaints" it.
After all, the scheduling_fix doesn't seem to cause trouble and seems work ewll. Will test again with Miller's "0.53-2test1" (that should be equivalent to my scheduling_fix build) and report back.
Many thanks for the pointer, Christof, and many thanks to all others involved in tackling backend issues.
Roman
On Sun, 2023-02-05 at 11:45 +0100, Roman Haefeli wrote:
And now - this sounds a bit crazy - while testing the scheduling_fix build, the official releases (0.53-1, 0.52-2, etc.) didn't exhibit the high CPU usage anymore. Later, after some more testing, it happened again though, but not with the scheduling_fix build. It's really difficult to determine exactly what circumstances lead to the high CPU usage. It's as if it's possible to "taint" CoreAudio and the scheduling_fix somehow "untaints" it.
After some more testing, the more likely reason for same Pd version showing different behavior is found in the saved preferences. The issue is much more likely triggered, when enabled callbacks are saved in the preferences and thus Pd enables callbacks at loading time. Toggling DSP then will almost certainly trigger high CPU usage.
Sorry for the confused reporting. Things are not trivial.
Roman
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 0using 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
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 http://docs.danomatika.com/pdbuilds/0.53/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 danomatika@gmail.com 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ć denis.polec@gmail.com 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 hansw.koch@gmail.com:
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 <danomatika@gmail.com mailto:danomatika@gmail.com>:
Howdy Theron,
can you try this build?
Pd-0.53-1-arm64-pa1970.zip http://docs.danomatika.com/pdbuilds/0.53/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-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
Message: 2 Date: Tue, 31 Jan 2023 22:12:08 -0800 From: Theron Trowbridge <theron.trowbridge@gmail.com mailto:theron.trowbridge@gmail.com> To: Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> Cc: "pd-list@lists.iem.at mailto:pd-list@lists.iem.at" <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: Re: [PD] DSP crashing - PD freezes. Message-ID: <CAD+3VoPwLt5CT=aS5oz95b0Bb=5DwNft+JGW5z3tDUqK+Q42jg@mail.gmail.com mailto:CAD+3VoPwLt5CT=aS5oz95b0Bb=5DwNft+JGW5z3tDUqK+Q42jg@mail.gmail.com> 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 http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list 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 http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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 danomatika@gmail.com:
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 http://docs.danomatika.com/pdbuilds/0.53/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 <danomatika@gmail.com mailto:danomatika@gmail.com> wrote:
Do you have callbacks enabled? If so, disable the checkbox in the audio dialog.
enohp ym morf tnes
Dan Wilcox danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Feb 4, 2023, at 9:54 AM, Denis Połeć <denis.polec@gmail.com mailto:denis.polec@gmail.com> 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 <hansw.koch@gmail.com mailto:hansw.koch@gmail.com>:
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 <danomatika@gmail.com mailto:danomatika@gmail.com>:
Howdy Theron,
can you try this build?
Pd-0.53-1-arm64-pa1970.zip http://docs.danomatika.com/pdbuilds/0.53/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-request@lists.iem.at mailto:pd-list-request@lists.iem.at wrote:
Message: 2 Date: Tue, 31 Jan 2023 22:12:08 -0800 From: Theron Trowbridge <theron.trowbridge@gmail.com mailto:theron.trowbridge@gmail.com> To: Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> Cc: "pd-list@lists.iem.at mailto:pd-list@lists.iem.at" <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: Re: [PD] DSP crashing - PD freezes. Message-ID: <CAD+3VoPwLt5CT=aS5oz95b0Bb=5DwNft+JGW5z3tDUqK+Q42jg@mail.gmail.com mailto:CAD+3VoPwLt5CT=aS5oz95b0Bb=5DwNft+JGW5z3tDUqK+Q42jg@mail.gmail.com> 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 http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Feb 4, 2023, at 11:46 AM, Denis Połeć denis.polec@gmail.com 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 http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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 danomatika@gmail.com wrote:
On Feb 4, 2023, at 11:46 AM, Denis Połeć denis.polec@gmail.com 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 http://twitter.com/danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/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 danomatika@gmail.com wrote:
On Feb 4, 2023, at 11:46 AM, Denis Połeć denis.polec@gmail.com 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!FqFnjr7... > 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__;!...
Works for me
Thanks!
-Theron ^
On Sat, Feb 4, 2023 at 6:15 PM Miller Puckette msp@ucsd.edu 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 danomatika@gmail.com wrote:
On Feb 4, 2023, at 11:46 AM, Denis Połeć denis.polec@gmail.com
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!FqFnjr7...
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__;!...
On Sat, 2023-02-04 at 18:15 -0800, Miller Puckette via Pd-list 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".
This build does not fix the high CPU usage of the 'pd' process I described earlier. To trigger the behavior, it seems that callbacks need to be enabled initially (saved in the preferences) and only after toggling DSP the CPU usage jumps. I can't trigger the issue as reliably when callback is disabled initially. When toggling DSP a few times with callbacks enabled, Pd sometimes hangs.
The schedule_fix build seems to swallow toggling DSP and callbacks just fine.
According to other reports, updating portaudio has addressed the Ventura specific behaviour (couldn't test myself, don't have access to Ventura), so probably what I describe is here is not directly related. Also, there seem to be no apparent problem when _not_ using callbacks.
Roman
so probably what I describe is here is not directly related.
That's what I tried to say in my last mail. My scheduler fixes - which happen to fix the callback issues - are held back for Pd 0.54.
Christof
On 05.02.2023 21:36, Roman Haefeli wrote:
On Sat, 2023-02-04 at 18:15 -0800, Miller Puckette via Pd-list 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".
This build does not fix the high CPU usage of the 'pd' process I described earlier. To trigger the behavior, it seems that callbacks need to be enabled initially (saved in the preferences) and only after toggling DSP the CPU usage jumps. I can't trigger the issue as reliably when callback is disabled initially. When toggling DSP a few times with callbacks enabled, Pd sometimes hangs.
The schedule_fix build seems to swallow toggling DSP and callbacks just fine.
According to other reports, updating portaudio has addressed the Ventura specific behaviour (couldn't test myself, don't have access to Ventura), so probably what I describe is here is not directly related. Also, there seem to be no apparent problem when _not_ using callbacks.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Christof Ressi -
Dan Wilcox -
Denis Połeć -
hans w. koch -
info＠christofressi.com
-
Miller Puckette -
Roman Haefeli -
Theron Trowbridge