Re: [PD] How to increase audio latency on linux?
On Sun, 2012-12-09 at 13:39 -0800, Miller Puckette wrote: grasping at straws but... maybe try Alsa using callbacks - so that Pd maintains the FIFO instead of having ALSA do it. I think you can do this by opening ALSA through portaudio, requesting blocking in Pd but replace #if defined(__APPLE__) #define FAKEBLOCKING #endif with just #define FAKEBLOCKING in s_audio_pa.c I haven't tried this - don't have time right now - but if you're willing I'd be eager to hear how it turns out :) Hey, I can compile Pd now with portaudio support! I applied your suggested change, re-compiled Pd and it seems now the default back-end is -pa. It turns out, that I am only able to open ALSA through portaudio, when no pulseaudio daemon is running. Turning pulseaudio off is not as easy as 'pulseaudio --kill', as the daemon will automatically be relaunched in a standard Ubuntu environment. I had to write: autospawn = no to ~/.pulse/client.conf and then do 'pulseaudio --kill' in order to really stop it. Now I was able to select the 'raw' soundcard through the portaudio dialog of Pd. It turns out that with your proposed change to s_audio_pa.c I can set an arbitrarily high buffer. With an audio buffer setting of 1000ms I was able to do stuff like: [100( | [until] | [pow 123.456] without getting any drop-outs! Mission accomplished. Many thanks for your help! Regarding callbacks: This was without checking the 'use callbacks' checkbox in the portaudio dialog. I wasn't able to change the audio buffer when it was checked withouth Pd crashing. Also when I check it after using a high buffer setting, Pd crashes: *** glibc detected *** pd: free(): corrupted unsorted chunks: 0x082797b8 *** === Backtrace: = /lib/i386-linux-gnu/libc.so.6(+0x75ee2)[0xb7506ee2] /usr/lib/i386-linux-gnu/libportaudio.so.2(+0x1a45f)[0xb767545f] /usr/lib/i386-linux-gnu/libportaudio.so.2(+0x8a73)[0xb7663a73] /usr/lib/i386-linux-gnu/libportaudio.so.2(+0xb365)[0xb7666365] /usr/lib/i386-linux-gnu/libportaudio.so.2(Pa_CloseStream+0x73)[0xb7661f83] pd(pa_close_audio+0x21)[0x8119fb1] pd(sys_close_audio+0xe5)[0x80ca4c5] pd(m_mainloop+0x917)[0x80bbad7] pd(main+0x1b)[0x8055deb] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb74aa4d3] pd[0x8055e11] Anyway, I am very glad to see this work in Linux. Will have to test it on the machine with the 'real' soundcard as I only tested with a build-in HDA Intel, CONEXANT Analog. Many thanks for your help, Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pb with readanysf compilation.
Le 09/12/2012 16:15, Hans-Christoph Steiner a écrit : http://packages.debian.org/search?keywords=libgmerlin-avdec-dev http://packages.ubuntu.com/search?keywords=libgmerlin-avdec-dev Its not in Debian/squeeze, it was added later. .hc On Dec 9, 2012, at 8:20 AM, contact wrote: In fact i can't find the libgermelin-avdec-dev package package with the multimedia repository. François-Marie BILLARD Le 08/12/2012 21:54, IOhannes m zmölnig a écrit : On 12/08/2012 17:15, contact wrote: In file included from src/FifoVideoFrames.cpp:20: src/FifoVideoFrames.h:30:27: error: gmerlin/avdec.h: Aucun fichier ou dossier de ce type while it is sometimes simple for speakers of different languages to guess what a localized error-message means, it is often unintelligible. it would therefore be great, if you could try to provide english error messages. try temporarily setting your locale to C before running the failing build. e.g. $ LANG=C make apart from that, hans is probably right and you should install the libgmerlin-avdec-dev package. fgmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list contact.vcf___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list thank's F.M attachment: contact.vcf___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] graph on parent problem?
hi Hans, I am attaching the patch. changing env~ parameter solved the problem. I did, however, test what happens if the vumeter is in the top patch (rather then inside the subpatch) and that doesn't create the same problem (i.e. doing [env~] without giving it a large buffer size). So there might be some additional issue with gop property there. thanks Oded ___ Oded Ben-Tal http://ccrma.stanford.edu/~oded o...@ccrma.stanford.edu #N canvas 301 37 864 693 10; #N canvas 741 317 287 398 taprhythm 0; #X obj -51 240 list prepend; #X obj -68 106 t b b b; #X obj -68 139 timer; #X obj -68 21 inlet; #X obj 45 19 inlet; #X obj -43 354 outlet; #X obj -51 270 t l l; #X obj 45 108 sel 0 1; #X obj -37 300 list; #X obj -67 73 spigot 0; #X obj -68 167 t f b; #X obj -41 194 s hit; #X msg 24 85 bang; #X connect 0 0 6 0; #X connect 1 0 2 0; #X connect 1 1 2 1; #X connect 2 0 10 0; #X connect 3 0 9 0; #X connect 4 0 7 0; #X connect 4 0 9 1; #X connect 4 0 12 0; #X connect 6 0 8 1; #X connect 6 1 0 1; #X connect 7 0 8 0; #X connect 7 1 0 1; #X connect 8 0 5 0; #X connect 9 0 1 0; #X connect 10 0 0 0; #X connect 10 1 11 0; #X connect 12 0 2 0; #X restore 104 134 pd taprhythm; #N canvas 476 0 747 410 playrhythm 0; #X obj 44 108 list split 1; #X obj 38 228 del; #X obj 93 197 list append; #X obj 44 25 inlet; #X obj 139 29 inlet; #X obj 44 75 list; #X obj 38 362 outlet; #X obj 454 324 outlet; #X obj 252 25 inlet; #X obj 38 199 * 1; #X connect 0 0 9 0; #X connect 0 1 2 1; #X connect 0 2 7 0; #X connect 1 0 6 0; #X connect 1 0 2 0; #X connect 2 0 0 0; #X connect 3 0 5 0; #X connect 4 0 5 1; #X connect 5 0 0 0; #X connect 8 0 9 1; #X connect 9 0 1 0; #X restore 28 273 pd playrhythm; #X obj 17 157 bng 15 250 50 0 empty empty play 17 7 0 10 -262144 -1 -1; #X obj 173 108 tgl 15 0 empty empty on/off 17 7 0 10 -262144 -1 -1 0 1; #X text 152 55 tap space bar; #X text 184 133 collect rhythm; #N canvas 408 70 450 300 noise 0; #X obj 166 51 inlet; #X obj 166 73 t b b; #X obj 198 118 del 100; #X msg 124 123 1 20; #X obj 132 188 line~; #X obj 70 238 outlet~; #X obj 44 181 noise~; #X obj 70 207 *~; #X msg 187 150 0 100; #X connect 0 0 1 0; #X connect 1 0 3 0; #X connect 1 1 2 0; #X connect 2 0 8 0; #X connect 3 0 4 0; #X connect 4 0 7 1; #X connect 6 0 7 0; #X connect 7 0 5 0; #X connect 8 0 4 0; #X restore 72 394 pd noise; #X obj 28 301 s hit; #X obj 28 32 r hit; #X obj 33 68 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X obj 72 359 r hit; #X obj 370 632 output~; #X obj 103 315 spigot; #X obj 142 288 tgl 15 0 empty empty loop-on/off 17 7 0 10 -262144 -1 -1 0 1; #X obj 72 428 *~ 0; #X obj 281 463 equal_power_pan~; #X obj 377 432 hsl 30 15 0 1 0 0 empty empty pan 3 7 0 10 -262144 -1 -1 0 1; #X obj 369 588 freeverb~; #X msg 444 366 roomsize \$1; #X msg 444 411 damping \$1; #X msg 444 455 width \$1; #X msg 444 499 wet \$1; #X msg 444 543 dry \$1; #X obj 456 520 hsl 60 18 0 1 0 1 empty empty dry 2 9 1 12 -225271 -1 -1 5700 0; #X obj 456 476 hsl 60 18 0 0.2 0 1 empty empty wet 2 9 1 12 -225271 -1 -1 1900 0; #X obj 456 432 hsl 60 18 0 1 0 1 empty empty width 2 9 1 12 -262131 -1 -1 5900 0; #X obj 456 388 hsl 60 18 0 2 0 1 empty empty damping 2 9 1 12 -261689 -1 -1 1475 0; #X obj 456 343 hsl 60 18 0.11 1.1 0 1 empty empty roomsize 2 9 1 12 -261689 -1 -1 4410 0; #X floatatom 426 347 3 0 0 0 - - -; #X floatatom 426 392 3 0 0 0 - - -; #X floatatom 426 437 3 0 0 0 - - -; #X floatatom 426 480 3 0 0 0 - - -; #X floatatom 426 524 3 0 0 0 - - -; #X obj 138 404 vsl 15 40 0 1 0 0 empty empty empty 0 -9 0 10 -262144 -1 -1 0 1; #X obj 198 339 catch~ sig; #X obj 71 461 throw~ sig; #N canvas 275 234 1104 536 playsample 0; #X obj 618 197 soundfiler; #N canvas 0 0 450 300 (subpatch) 0; #X array asound 144384 float 2; #X coords 0 1 144384 -1 200 140 1; #X restore 346 86 graph; #X obj 618 119 openpanel; #X floatatom 543 336 5 0 0 1 length - -; #X msg 618 157 read -resize \$1 asound; #X obj 59 413 line~; #X obj 46 446 tabread4~ asound; #X obj 262 232 -; #X obj 262 204 t b f; #X obj 262 261 * 1000; #X obj 261 294 /; #X obj 166 191 t b b b; #X obj 95 236 f 1; #X obj 159 227 f 2; #X obj 245 321 f 1; #X obj 245 344 abs; #X obj 121 478 outlet~; #X obj 170 27 r hit; #X obj 618 83 inlet; #X obj 57 38 inlet; #X text 57 19 from; #X obj 116 38 inlet; #X obj 296 43 inlet; #X text 295 26 speed; #X obj 636 356 outlet; #X obj 70 329 pack 0 0; #X obj 203 100 counter 0 4; #X obj 170 53 t b b; #X obj 98 372 route 0 1 2 3 4; #X obj 156 414 line~; #X obj 157 444 tabread4~ asound; #X obj 266 416 line~; #X obj 267 446 tabread4~ asound; #X obj 377 416 line~; #X obj 378 446 tabread4~ asound; #X obj 491 415 line~; #X obj 492 449 tabread4~ asound; #X obj 159 338 pack 0 0 0; #X obj 753 265 tabwrite~ asound; #X text 112 15 duration; #X obj 103 134 +; #X obj 115 107 t b f; #X obj 111 168 clip 0 10; #X obj 732 27 adc~ 1; #X obj 613 278 f 0; #X obj 732 57 hip~ 10; #X obj 854 84 inlet; #X obj 856 116 sel 1 0; #X obj 874 186 timer; #X
Re: [PD] How to increase audio latency on linux?
On 09/12/12 11:12, Roman Haefeli wrote: [...] If my intent to have an as huge as possible latency in order to decrease likeliness of drop-outs, it is still advised to use a low latency kernel and run Pd/Jackd with realtime priorities? Or would I be better off then with standard settings? You probably already know/do this.. but there are a couple of factors which can create dropouts/clicks which seem independent from bleeding-edge-realtime etc. settings: - CPU: be sure to set it to performance and *not* on demand - Lots of (Pd) gui objects (e.g. sliders, numberboxs) manipulation/updates. Lorenzo. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] How to increase audio latency on linux?
On Mon, 2012-12-10 at 13:17 +0100, Lorenzo Sutton wrote: On 09/12/12 11:12, Roman Haefeli wrote: [...] If my intent to have an as huge as possible latency in order to decrease likeliness of drop-outs, it is still advised to use a low latency kernel and run Pd/Jackd with realtime priorities? Or would I be better off then with standard settings? You probably already know/do this.. but there are a couple of factors which can create dropouts/clicks which seem independent from bleeding-edge-realtime etc. settings: - CPU: be sure to set it to performance and *not* on demand Yeah, it appears to me that only since a few years this is an issue for me on Linux laptops (not so on non-mobile computers). Somehow the CPU frequency scaling manager is too slow for Pd, so often it sticks to the lower frequency, although Pd is using 100% CPU (or probably it is related to multi-core CPUs? I don't know). $ sudo cpufreq-selector -g performance seems to get rid of the issue. - Lots of (Pd) gui objects (e.g. sliders, numberboxs) manipulation/updates. The reason I'm interested in huge latencies is exactly because of this. I'm using Pd in non-interactive setups, so the huge latency doesn't matter. On the other hand, the big latency allows for doing a lot of stuff in zero logical time without risking drop-outs. One example is load new presets while the patch is running, which means reading and parsing a text file, setting loads of number boxes and sliders, loading a number of soundfiles into [readsf~]s or [readanysf~]s, all this in zero logical time. With low latency, this is much more complex while avoiding drop-outs (like loading the preset step-by-step, for instance). Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] graph on parent problem?
I think it does it is just that when it is inside a gop it may be more noticeable as array is one of components GUI has to circumnavigate to find the right thing to draw. Try putting both the array and vumeter onto the root canvas and see if it still is better than the one in gop. My hunch would be it would be the same. Let me know. -Original Message- From: Oded Ben-Tal [mailto:o...@ccrma.stanford.edu] Sent: Monday, December 10, 2012 6:37 AM To: Hans-Christoph Steiner Cc: Ivica Ico Bukvic; pd-list@iem.at Subject: Re: [PD] graph on parent problem? hi Hans, I am attaching the patch. changing env~ parameter solved the problem. I did, however, test what happens if the vumeter is in the top patch (rather then inside the subpatch) and that doesn't create the same problem (i.e. doing [env~] without giving it a large buffer size). So there might be some additional issue with gop property there. thanks Oded ___ Oded Ben-Tal http://ccrma.stanford.edu/~oded o...@ccrma.stanford.edu ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] what makes Pd-extended 0.43 so CPU-hungry?
On Fri, Dec 7, 2012 at 11:46 PM, Hans-Christoph Steiner h...@at.or.at wrote: Thanks for this write-up and all that testing, its definitely very helpful. So in the end, you're talking about Pd-extended on debian only? It sounds like your tests show that 0.43 was not slower on Mac OS X. It does look like the Debian-i386 builds don't have optimization turned on, you can look at the build log to see exactly how it was built Hans I checked build logs for various Linux builds and for OSX. As it turns out, Pd core is optimized as well as some external libs (ie GEM), but other externals (like freeverb~) are optimized for OSX and not for Debian. I suspect the problem is in Makefiles according to the template. They have lines like OPT_FLAGS = -O6 -funroll-loops -fomit-frame-pointer. But Makefiles for packages have OPT_FLAGS as well, therefore in the library template it should be OPT_FLAGS +=, no? The darwin_app package makefile defines a lot of OPT_FLAGS, including -fast. The linux package makefile defines several OPT_FLAGS according to target platform, but no optimization level. Apparently, OPT_FLAGS in the package Makefile are implemented, and not the ones in the template. I don't have a Pd autobuild or SVN setup on my Linux box now, can't test a modification rightaway. Anyhow, I guess the problem is now identified. I am sorry about my blunt subject title 'what makes Pd 0.43 so CPU hungry?'. It wasn't even about Pd, but Pd-extended. Katja ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] linux, elka ek22, sysexin dump unpacking (82 bytes)
hi list. im working on editor for Elka ek/em 22 analogue synth. when i request a parameter dump i get 82 bytes from sysexin. i can see the dump by [print] monitor, but I have no idea how to unpack these 82 bytes. when trigger banging the dump i only get 8 bangs, so i cant put a counter on it. is there anyone who has an idea how to unpack this dump. im on debian, pd-extended 0.43.4 kind regs ~/j -- http://www.fastmail.fm - Choose from over 50 domains or use your own ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] linux, elka ek22, sysexin dump unpacking (82 bytes)
On 12/10/2012 18:53, jamal crawford wrote: hi list. im working on editor for Elka ek/em 22 analogue synth. when i request a parameter dump i get 82 bytes from sysexin. i can see the dump by [print] monitor, but I have no idea how to unpack these 82 bytes. when trigger banging the dump i only get 8 bangs, so i cant put a counter on it. is there anyone who has an idea how to unpack this dump. check the [list] family of objects for re-grouping of your data. fgmasdr IOhannes ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
[PD] autotools on Mac OS X WAS: Build failed in Jenkins: pure-data » macosx106 #164
I'm CC'ing pd-dev since this is good to have in the public and on the record. On Dec 7, 2012, at 3:51 AM, IOhannes m zmölnig wrote: On 12/07/2012 09:22, IOhannes m zmölnig wrote: hi hans! do you have any idea what causes such spurious build failures on the jenkins machines? a related issue, is the build-failure of puredata on the macosx104-powerpc machine, which is consistent and reproducible. i checked and the problem is, that some pkg-config related m4 macros are not expanded correctly. the relevant m4 macro get's installed by fink's pkg-config package as /sw/share/aclocal/pkg.m4 unfortunately, the aclocal binary used on the machine is /usr/bin/aclocal (that is: not-fink), and does not automatically look into /sw/share/aclocal for additional m4 macros. i don't know what the proper way to deal with this is: - either install a pkg-config version of aclocal (which will automatically search the right paths)) - or tell the system's aclocal to use fink's m4-directory (adding -I /sw/share/aclocal to the autoreconf/aclocal flags) i don't like the latter much, as i assume it will be hard to get it right (e.g. not using m4 macros in /sw when the user decides to *not* activate fink even though it's installed on the machine), but i don't know whether the first is actually possible. I think the problem was that Fink's 'autoconf' was installed but not Fink's 'automake-1.10'. So we need to decide to either go full native or full Fink for the autotools. The minimum build env I support is 10.5, so that means: autoconf 2.61 automake 1.10 libtool 1.5.22 If things need newer versions than that, then I say we just use all of the Fink packages. Then we could have: autoconf 2.69 automake 1.12.3 libtool 2.4.2 .hc ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
