Awesome, it works!
Any idea why it might be making these assumptions about the number of channels?
D __ _ _ _ _ __ ___ _ _ __ _ ___ ____ _ __ __ __ _ __ __ To talk about it is to miss the point http://sintheta.org
Martin Peach wrote:
David NG McCallum wrote:
Thanks for the syntax, Ben. I've never use gdb before.
The output was:
(gdb) bt #0 0x080af12a in sys_setchsr (chin=270238624, chout=1323783775, sr=44100) at s_audio.c:152 #1 0x080b0553 in sys_open_audio (naudioindev=2, audioindev=0xbf9ca7a4, nchindev=2, chindev=0xbf9ca794, naudiooutdev=2, audiooutdev=0xbf9ca784, nchoutdev=2, choutdev=0xbf9ca774, rate=44100, advance=50, enable=0) at s_audio.c:308 #2 0x080a73ec in sys_main (argc=1, argv=0xbf9ca864) at s_main.c:947 #3 0x4ee26d5f in __libc_start_main () from /lib/libc.so.6 #4 0x08054ccd in _start ()
Any idea how to make sense of this?
Back-tracing the stack shows that it crashed in a function named sys_setchsr which, if you look in the source code file s_audio.c, allocates memory for sound buffers. There is no checking done to see if the pointers returned by malloc are valid (non-NULL) or that the sizes requested are valid (chin*DEFDACBLKSIZE*sizeof(float)) = 270238624*64*8, so probably that's why it crashed: you're asking for a huge amount of ram. Somehow pd thinks you have a _lot_ of sound channels. Maybe you could try using the command-line arguments -inchannels and -outchannels to set just 2 channels. Or maybe you should use alsa or oss or something else for audio...just guessing.
Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list