Re: [PD] DSP crashing - PD freezes.
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 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.
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 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] DSP crashing - PD freezes.
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 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.
Thanks a lot for testing!> Will test again with Miller's "0.53-2test1" (that should beequivalent to my scheduling_fix build) and report back.Millers bug fix release only contains the portaudio update. My scheduler fixes will (hopefully) be included in Pd 0.54.ChristofAm 05.02.2023 11:45 schrieb Roman Haefeli :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 ___ 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.
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 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
