-
lysergik
posted in libpd / webpd • read moreHi,
I've been forking around a C++ audio software that uses signed int audio buffer, I wanted to add a multi fx processing unit. Since coding it in c++ seem to me pretty hard I just want to make a multifx pd patch and then use pdlib to have my patch processing the audio buffer of my C++ program.
However I don't any libpd function that process sint32 audio buffer, only short, float or double. So I wonder if just converting my audiobuffer from sint32 to float and back again to sint32 is fine or should I avoid such approach ?
Thanks in advance.
-
posted in technical issues • read more
Hi everone ! I finally got it ! I've just reinstall iemlib with deken, I just have to tick the boxes that says add the path during installation and everything works now. I could run a fine test of a crossover patch with my sound system. It was fun !
-
posted in technical issues • read more
@jameslo I did install ieamlib as you said, got to my preferences to have iemlib at launch, git the message in pd console saying iemlib was launched. But when i try to create a bessel or butterworth filter pure data act like it doesn't know the object i'm calling. I don't know what is wrong with iemlib.
@tungee Thanks a lot it works well, anyway I got some kind of crackling on the high frequency canal, do you know how to fix that ?
-
posted in technical issues • read more
Hi everyone !
I am currently equiping some loudspeaker case, and I dont have any kind of active crossover at the moment. In order to test my speakers I would like to send them an audio signal from my computer that I would filter up with a pd patch using jack. I know about lop~ and hip~ object in pd vanilla but more complexe filter like Beseel, linkwitz and riley or butterworth filter seem only to exists in pd extended. I tried to get extened on my laptop but due to some depedencies clash I couldn't do anything. Is there a way to simply add the filter object of extended in vanilla ?
Thanks in advance for your answer.
-
posted in technical issues • read more
Thanks guys for the tips and links I will look into that in order to figure out the best trick to get a cleaner sound with the less CPU usage possible. I've actualy understood why my soustractive/additive bandlimited oscilators had some noise/clicking and it has nothing to do with aliasing but bad signal use in my design that I could fix easily.
Then while running my osc's with antialising/oversampling I did'nt notice an audible difference with or without antialising/oversampling, at least for the soustractive and additive synthesis. For FM synthesis I ran different test and got a good CPU use/antialising solution when oversampling two times. In order to get the best performance possible I could only apply the antialising method when using my FM osc and not applying it to my banlimited oscilators.
I've also tested inscreasing my block values and the result are interesting though I've heard that doing so leads to increase latency and since I want to make a patch meant for live performance it could became an issue if I rely on that to lower my CPU use. Though I might find a solution to the aliasing within use of a low pass filter which could offer a good alternative to the antialising method I used.
@gmoon I've used once pd~ and I don't know if I poorly implemented it or if the object isn't ready yet to deliver an interesting use of multiple cores but when I used it pd~ managed to multiply by four the CPU use of the patch I was working on. From my experience I won't recomend to anyone using pd~ for CPU optimization but maybe there's someone out there that knows how to use it properly and had succesfully devided his sound processing within pd.
-
posted in technical issues • read more
Hi,
About a year ago I started to learn a bit pure data in order to create a patch that would act as a groovebox and that should perform on limited cpu resources since I want it to run on a raspberry pi. First I tried to make somekind of fork of the Martin Brinkmann groovebox patch, even if it allowed me to learn a lot about data flow I didn't went to the core of the patch tweaking with sound generation. This led me to end this attempt at forking MNB groovebox patch because even if I could seperate GUI stuff from sound generation and run it on different thread ect... I couldn't go further in optimization in order to reduce the cpu use.
Then a few weeks ago I decided to start again from scratch my project and this time I wanted to be more patient and learn anything needed in order to be capable of optimizing my patch as much as possible. After making a functional drum machine which runs at 2/3% of cpu with 8 different tracks, 126 steps sequencer, a bit of fx ect... I tried to find synths that would opperate well aside the drum machine. And I basicly didn't find any patch that wouldn't use massive amount of cpu time. So I created my own synths, nothing incredible but I'm happy with what I got, though I noticed some aliasing. I read a bit the floss manual about anti aliasing and apply the method used in the manual(http://write.flossmanuals.net/pure-data/antialiasing/), it work well but my synths almost trippled their cpu use, even if I put all my oscilators in the same subpatch in order to use only one instance of oversampling.
I didn't tried to oversample it less than 16 time but since oversampling is so cpu intensive I'm wondering if there's no other option in order to get a good sound definition at a lower cpu cost. I'm already using banlimited waveform so I don't know what I could do in order to limit the aliasing, especialy for my fm patch where bandlimited waveform isn't very useful in order to reduce aliasing.
Since I want to have at least 4 synth track with some at least one synth having 5 voice polyphony I want to know what the best thing to do. Letting FM aside for this project and use switch~ for oversampling 2 or 4 time my synths that use bandlimited waveform ? Or should I try to run different instances of pd for each synth and controling it from a gui/control patch with netsend(though it wouldn't bring down the cpu use at least it would provide somekind of multithreading for my patch) ? Or is there another way to get some antiliasing ? Or should I review lower my expectation because there is no solution that could provide a decent antialiasing for 4 or more synth running at the same time with a low cpu use in pure data in 2021.
Thanks to everyone that would read my topic and try to give some advice in order to get the best antialising/low cpu use solution.
-
posted in technical issues • read more
Thanks for your answer, I've succesfully added a swing to my clock and to give more interesting rythm I decided to space the steps differently if it's quarts, eight or sixteenth.(as this patch https://forum.pdpatchrepo.info/topic/4818/shuffle-groove-swing-in-pd).
-
posted in technical issues • read more
Hi, I wasn't so sure where I should post so I post here even though it's not really a technical issue.
I want to had swing to my sequencer, so far it a 8 bar sequencer functioning with a separate clock, with it's own pattern storage thing ect... I know what swing is but I'm not sure how I should implement it.
I've read a bit from old forum post where little is said and without example and here's how I think adding it to my sequencer: defining a random value in miliseconds at each step that would be added to the time of the clock, this value should be redifine at each step and this value should be define into an interval that could be changed by the user. Is this a good way to code a "swing" ?
I never used randominsation inside a pure data patch so it something I would have to learn(I guess it's not that hard to understand). Where I'm more confused is the interval of milisecond I should use to implement the "swing", so if anyone could give some advise in that regard it would be great.
-
posted in technical issues • read more
@whale-av Thanks ! Since I found drum synth I found online I didn't knew about those send and receive inside the propereties menu of the number box. I just had to delete the send and receive and it work. Also I didn't had to rename"osc_pair_1" and the other used for pitch because they are subpatches, and they were relied to the sliders via the same send and receive function that we find elsewere. Thanks again.
-
posted in technical issues • read more
I didn't used array or specific value in those subpatches. Here's the code : drummachine.pd
-
posted in technical issues • read more
No they are named "pd tom" and "pd hihat" so it should be fine
-
posted in technical issues • read more
Hi,
I started a simple project just for fun and I encountered something strange. I use some subpatch on my patch on they work well, though they doing somehting strange. I have made some copies of a few subpatch I've made and when I tweak a value of one subpatch it affect the sound of it's copy, which is strange. It affect all the subpatch I made copy of. And I've tried to made subpatch with the same code but different names and it does the exact same thing. I'm very confused, I don't understand what is going on. -
posted in technical issues • read more
Hi guys, so I manage to get rid of the "output snd_pcm_delay failed" error by running pd with Jack. It doesn't do anything for the CPU, still got my four cores running at 50%. I did some profiling on groovebox 2 and my first my frist version of the "fork" I was working on and I notcied that I didn't get any vfprintf calls, so the problem doesn't come from neither martin Birkmann patch or my first tweaks on it, but only from the implementation of pd~. Since the vfprintf isn't due to the alsa error message, it must be something else. It's not the synth of the patch or the mixer and fx that works well somewhere else. Then the only thing that are remains in this audio processing patch is the following : an object that permits me to get all the value that come from my GUI patch via netsend/netreceive and another object which take the value received via netsend to then them with a message to the pd~ object.
My netsend/netreceive object seems to have worked fine until now I didn't notice any CPU issues when using it. The other object maybe the source of the problem, thoough it's strange because the value that I send from the GUI are sent properly to the audio processing patch. So I'don't know what to do. Should I pack an archive of my code and put it here so you could have a better idea of whats going on ?
-
posted in technical issues • read more
Hi @whale-av thanks to give your outlook on this. My performance on groovebox 2 is similar to yours, a bit more CPU use but my CPU is a bit slower so nothing strange. My "fork" of this patch runs with similar specs. Then the error message I got is happening both to my rpi and laptop, so it would explain why I got messed up performances with pd~. I'll try to see if upgradung to new kernel in both OS helps or to find other way to get rid of this. If this solve my issue with pd~ it would be nice, I'll give you guys an update as soon as I have looked into that.
-
posted in technical issues • read more
Well I do not see what is the main difference with the result I've shown before, maybe now we know that vfprintf function call is linked to printf_chk, that I didn't seen before while profiling. Also we got a malloc call and some dac call, so if you got any clue of what it could meant it would be great. Then I have to agree profiling isn't easy(it's my first time doing it ^^) but trying to fix the problem as such low level coudl be the best way to find a real fix to this bottleneck.
@mnb Hello ! First I thank you to have uploaded your patches, they're great ! Then to answer you, no I'm using the groovebox 2, the one you recommend. So the problem isn't from the filter object. But since you coded this patch you maybe could run it on your config and report here how much CPU power it takes on your side. By doing this we could identify if the problem is coming from the code or my hardware(I remember reading somewhere that embed intel GPU could have crappy result with pd, so with a bit of luck i could find somekind of driver fix to this issue).
@EEight Well, when I'll get something running fine on my laptop I'll port it to the RPI and of course I'll use -nogui, even switch~ if it's possible. But on the two version of my ptach I got either 50% of my first core(whith a 2Ghz CPU) or on the v2 of the patch 4 cores running at peak over 50%. Considering that my Pi is using a Broadcom BCM2837, with 1,2 Ghz on four cores and that the frequency is lock by the system around 900 MGhz if I'm right, it's just impossible to run my patch now on the rpi. I thinked that in theory splitting the audio processing to spread the calculation over the processor I would get 1ghz of calculation devided in four and then I could reach 250-300 MHz on each cores, that could run very smoothly on a rpi. But because there is something bugging somewehre I've just multiply the audio processing ressources by FOUR ! And -no-gui(that I already use on my laptop) or other tip for optimization such as latency doesn't help the CPU on my laptop, so I don't even think of its efficency on a RPI. I also noticed that when I increased the latency of my pure data instances, CPU use goes up ! So it's not something I could use for optimization. And didn't find ways to run pd on alsa on my Pi the only way I could get it to run without crahsing when dsp is on is with jack.
-
posted in technical issues • read more
First subpatch:
report -> - 41,17% 9,23% pd [unknown] [.] 0000000000000000 - 37,73% 0 - 17,87% __printf_chk + 14,75% vfprintf 0,96% __printf_fp - 5,36% 0 - 0xda0580 - 0 0,73% garray_getarray 0,67% pd_findbyclass 3,81% __GI_____strtod_l_internal 2,21% strlen 1,77% binbuf_text 0,82% pd_extern_sched 0,82% atom_getfloat@plt 0,61% 0xba25daeb2f749a00 0,53% atom_getfloat - 1,89% 0x300a300a300a300a 0 - 0,73% 0x1bfca50 0 __printf_chk - 18,60% 0,00% pd [unknown] [.] 0x0000000001bfca50 0x1bfca50 0 - __printf_chk - 15,19% vfprintf 8,65% __GI___printf_fp_l 0,63% __mpn_mul_1 0,96% __printf_fp - 15,19% 4,18% pd libc-2.23.so [.] vfprintf - 11,01% vfprintf 8,65% __GI___printf_fp_l 0,63% __mpn_mul_1 - 4,18% 0x1bfca50 0 __printf_chk vfprintf - 11,33% 0,00% pd [unknown] [.] 0x300a300a300a300a - 0x300a300a300a300a ◆ 6,71% _IO_getc 1,89% 0 1,44% pd_extern_sched - 0,54% __GI___libc_read entry_SYSCALL_64_fastpath sys_read vfs_read __vfs_read new_sync_read - 10,54% 10,54% pd libc-2.23.so [.] malloc_consolidate 0xf1 malloc_consolidate - 10,54% 0,00% pd [unknown] [.] 0x00000000000000f1 0xf1 malloc_consolidate - 8,65% 8,65% pd libc-2.23.so [.] __GI___printf_fp_l 0x1bfca50 0 __printf_chk vfprintf __GI___printf_fp_l - 6,71% 6,71% pd libc-2.23.so [.] _IO_getc 0x300a300a300a300a _IO_getc - 5,24% 5,23% pd pd [.] plus_perf8 plus_perf8 report no children -> - 41,17% 9,23% pd [.] 0000000000000000 - 37,73% 0 - 17,87% __printf_chk - 14,75% vfprintf 8,65% __GI___printf_fp_l 0,63% __mpn_mul_1 0,96% __printf_fp - 5,36% 0 - 0xda0580 + 0 3,81% __GI_____strtod_l_internal 2,21% strlen 1,77% binbuf_text 0,82% pd_extern_sched 0,82% atom_getfloat@plt 0,61% 0xba25daeb2f749a00 0,53% atom_getfloat - 1,89% 0x300a300a300a300a 0 - 0,73% 0x1bfca50 0 __printf_chk - 11,33% 0,00% pd [.] 0x300a300a300a300a - 0x300a300a300a300a 6,71% _IO_getc 1,89% 0 1,44% pd_extern_sched - 0,54% __GI___libc_read entry_SYSCALL_64_fastpath sys_read vfs_read __vfs_read ◆ new_sync_read - 10,54% pd libc-2.23.so [.] malloc_consolidate malloc_consolidate 0xf1 - 9,23% pd [unknown] [.] 0000000000000000 - 0 3,70% 0 1,89% 0x300a300a300a300a ◆ - 8,65% pd libc-2.23.so [.] __GI___printf_fp_l __GI___printf_fp_l vfprintf __printf_chk 0 0x1bfca50 - 6,71% pd libc-2.23.so [.] _IO_getc _IO_getc 0x300a300a300a300a - 5,23% pd pd [.] plus_perf8 plus_perf8 - 4,18% pd libc-2.23.so [.] vfprintf vfprintf __printf_chk 0 0x1bfca50Second subpatch:
report -> - 10,54% pd libc-2.23.so [.] malloc_consolidate malloc_consolidate 0xf1 - 9,23% pd [unknown] [.] 0000000000000000 - 0 3,70% 0 1,89% 0x300a300a300a300a - 8,65% pd libc-2.23.so [.] __GI___printf_fp_l __GI___printf_fp_l vfprintf __printf_chk 0 0x1bfca50 - 6,71% pd libc-2.23.so [.] _IO_getc _IO_getc 0x300a300a300a300a - 5,23% pd pd [.] plus_perf8 plus_perf8 - 4,18% pd libc-2.23.so [.] vfprintf vfprintf __printf_chk 0 0x1bfca50 - 9,92% pd [unknown] [.] 0000000000000000 - 0 ◆ - 0,73% vfprintf __printf_chk 0 0x1257040 - 9,69% pd libc-2.23.so [.] __GI___printf_fp_l __GI___printf_fp_l vfprintf __printf_chk 0 0x1257040 - 7,65% pd libc-2.23.so [.] vfprintf - vfprintf - 7,55% __printf_chk 0 0x1257040 - 5,29% pd pd [.] 0x000000000008748c 0x8748c -
posted in technical issues • read more
Hello everyone ! @Nicolas Danet First I've succesfully compiled pd with the flag, then I profiled my 3 patch/subpatches using the command you showed. So here what I got from this profiling (the report dsos=pd command doesn't gave me intersting result, so it's output is not showed here.)
Mother patch:
report -> - 33,34% 8,01% pd libc-2.23.so [.] vfprintf - 25,33% vfprintf 16,57% __GI___printf_fp_l 2,95% hack_digit - 2,45% __GI___ioctl entry_SYSCALL_64_fastpath sys_ioctl + do_vfs_ioctl 1,29% __mpn_mul_1 0,70% strlen + 8,01% __fprintf_chk - 16,57% 16,18% pd libc-2.23.so [.] __GI___printf_fp_l 16,18% __fprintf_chk vfprintf __GI___printf_fp_l - 13,69% 13,69% pd libc-2.23.so [.] __GI_____strtof_l_internal - 12,53% 0x2f73250064702f6e __isoc99_vsscanf __GI_____strtof_l_internal - 1,16% 0x7ffc9a2c60 __GI_____strtof_l_internal - 12,71% 12,51% pd libc-2.23.so [.] _IO_vfscanf 12,51% 0x2f73250064702f6e __isoc99_vsscanf _IO_vfscanf - 5,49% 5,49% pd [kernel.kallsyms] [k] delay_tsc ◆ - 1,94% 0x3a7e647000732520 vfprintf __GI___ioctl entry_SYSCALL_64_fastpath sys_ioctl do_vfs_ioctl snd_pcm_capture_ioctl + snd_pcm_capture_ioctl1 - 1,49% __GI___ioctl entry_SYSCALL_64_fastpath sys_ioctl do_vfs_ioctl snd_pcm_capture_ioctl + snd_pcm_capture_ioctl1 - 1,34% 0x64c99 __GI___ioctl entry_SYSCALL_64_fastpath sys_ioctl do_vfs_ioctl snd_pcm_capture_ioctl - snd_pcm_capture_ioctl1 - 0,80% snd_pcm_common_ioctl1 snd_pcm_status_user snd_pcm_status snd_pcm_update_hw_ptr snd_pcm_update_hw_ptr0 azx_pcm_pointer azx_get_position azx_get_pos_skl __const_udelay delay_tsc + 0,54% __snd_pcm_lib_xfer report no children -> - 16,18% pd libc-2.23.so [.] __GI___printf_fp_l __GI___printf_fp_l vfprintf __fprintf_chk - 13,69% pd libc-2.23.so [.] __GI_____strtof_l_internal - __GI_____strtof_l_internal - 12,53% __isoc99_vsscanf 0x2f73250064702f6e 1,16% 0x7ffc9a2c60 - 12,51% pd libc-2.23.so [.] _IO_vfscanf _IO_vfscanf __isoc99_vsscanf 0x2f73250064702f6e - 8,01% pd libc-2.23.so [.] vfprintf ◆ vfprintf __fprintf_chk - 5,49% pd [kernel.kallsyms] [k] delay_tsc delay_tsc __const_udelay azx_get_pos_skl azx_get_position azx_pcm_pointer - snd_pcm_update_hw_ptr0 - 2,88% snd_pcm_update_hw_ptr - 2,69% snd_pcm_status snd_pcm_status_user snd_pcm_common_ioctl1 snd_pcm_capture_ioctl1 snd_pcm_capture_ioctl do_vfs_ioctl sys_ioctl entry_SYSCALL_64_fastpath + __GI___ioctl + 2,60% __snd_pcm_lib_xfer -
posted in technical issues • read more
Hi I manage to get the perf tools source but don't know where I should put the -fno-omit-frame-pointer flag. All the tutrial I found show how to compile it with the makefile, so how do I put this gcc flag in the makefile ?
-
posted in technical issues • read more
Sorry for my misunderstanding, I've look up to see If there were a way to see calls which are nested to other ones, and I found this (https://fr.slideshare.net/emBO_Conference/profiling-your-applications-using-the-linux-perf-tools) on a slide there's a command to show what they call children calls. When I launch it I can see all the calls linked to a call by pressing enter. All I need now is to find the interesting calls such as DSP ticking ect...
EDIT:
Here's the childrencalls of the calls I've reported before:- 25,22% 6,90% pd libc-2.23.so [.] vfprintf - 18,32% vfprintf - 16,16% __GI___printf_fp_l 1,47% hack_digit 1,04% __mpn_mul_1 0,70% strlen 0,76% __strchrnul 0,65% _IO_file_xsputn@@GLIBC_2.2.5 - 6,84% 0xffffffffffffffff - 6,81% _start __libc_start_main sys_run_scheduler pd_extern_sched __printf_chk vfprintf - 16,60% 12,52% pd libc-2.23.so [.] __GI___printf_fp_l - 12,44% 0xffffffffffffffff _start __libc_start_main sys_run_scheduler pd_extern_sched - __printf_chk - 12,42% vfprintf __GI___printf_fp_l - 4,09% __GI___printf_fp_l 1,47% hack_digit 1,07% __mpn_mul_1 0,72% strlen - 25,22% 6,90% pd libc-2.23.so [.] vfprintf - 18,32% vfprintf - 16,16% __GI___printf_fp_l 1,47% hack_digit 1,04% __mpn_mul_1 0,70% strlen 0,76% __strchrnul 0,65% _IO_file_xsputn@@GLIBC_2.2.5 - 6,84% 0xffffffffffffffff - 6,81% _start __libc_start_main sys_run_scheduler pd_extern_sched __printf_chk vfprintf - 16,60% 12,52% pd libc-2.23.so [.] __GI___printf_fp_l - 12,44% 0xffffffffffffffff _start __libc_start_main sys_run_scheduler pd_extern_sched - __printf_chk - 12,42% vfprintf __GI___printf_fp_l - 4,09% __GI___printf_fp_l 1,47% hack_digit 1,07% __mpn_mul_1 0,72% strlen ... - 25,22% 6,90% pd libc-2.23.so [.] vfprintf - 18,32% vfprintf - 16,16% __GI___printf_fp_l 1,47% hack_digit 1,04% __mpn_mul_1 0,70% strlen 0,76% __strchrnul 0,65% _IO_file_xsputn@@GLIBC_2.2.5 - 6,84% 0xffffffffffffffff - 6,81% _start __libc_start_main sys_run_scheduler pd_extern_sched __printf_chk vfprintf - 16,60% 12,52% pd libc-2.23.so [.] __GI___printf_fp_l - 12,44% 0xffffffffffffffff _start __libc_start_main sys_run_scheduler pd_extern_sched + __printf_chk - 4,09% __GI___printf_fp_l 1,47% hack_digit 1,07% __mpn_mul_1 0,72% strlenThen I took a look to DSP-tick and sched-tick to see whats going there:
- 66,16% 0,57% pd pd [.] dsp_tick - 65,59% dsp_tick - 2,72% expr_perform - 2,56% ex_eval 2,27% eval_func 2,47% scalartimes_perf8 2,25% plus_perf8 2,19% times_perf8 1,30% 0x8754e 1,23% 0x87487 1,10% 0x8753f 1,08% 0x87491 1,05% voutlet_perform 0,63% 0x87478 0,63% 0x87531 0,63% minus_perf8 0,61% 0x7e4ff 0,61% 0x7aebd 0,60% 0x7e5a5 0,60% 0x7e4b0 0,60% 0x8755d 0,57% 0x7e54b + 0,55% 0x830d7 + 0,55% 0x83018 + 0,54% 0x8311d + 0,53% 0x8308d 0,51% 0x8746a - 65,86% 0,03% pd pd [.] sched_tick 65,83% sched_tick - dsp_tick - 2,72% expr_perform - 2,56% ex_eval 2,27% eval_func 2,47% scalartimes_perf8 2,25% plus_perf8 2,19% times_perf8 1,30% 0x8754e 1,23% 0x87487 1,10% 0x8753f 1,08% 0x87491 1,05% voutlet_perform 0,63% 0x87478 0,63% 0x87531 0,63% minus_perf8 0,61% 0x7e4ff 0,61% 0x7aebd 0,60% 0x7e5a5 0,60% 0x7e4b0 0,60% 0x8755d 0,57% 0x7e54b + 0,55% 0x830d7 + 0,55% 0x83018 + 0,54% 0x8311d + 0,53% 0x8308d 0,51% 0x8746aI've displayed the result for the 3 process for what seems problematic and then for DSP et Sched tick only write the output of one process since it's similar on every process. So the problems seems to come from the process __GI___printf_fp_l and vfprintf and not on other calls(which all seems to run fine. I tried to find vfprintf and __GL___Printf_fp_l because I couldn't find them when running perf on the osc~ 440 patch, so it seems those calls depends of my pd object.
-
posted in technical issues • read more
Well the result I've showed isn't from a global CPU counter(like htop), but it's the result I got by record event comming from the pure data process with perf(with a command like this perf record -p pid), even if there's recurent functions that are called by pd noramlly, they usally don"t run with as much CPU use. I could run a test with a very simple patch to see if the same function calls appear first or not, then we would know if the function calls perf reported are the one linking to the bottlneck.
Edit: I've just run a perf test with a patch looking like this [osc~ 440]-[dac~]. This what perf sends me:
"62,44% pd [kernel.kallsyms] [k] delay_tsc ▒
19,19% pd [kernel.kallsyms] [k] pci_azx_readl "We see now that only delay_tsc is noramlly called by pd but all the other function called I quoted before are link to my patch.