Engine will dump core in some preops routines when the engine is started with a different buffer size to the jack daemon.
Affects the hammond and vox algorithms, does not appear to affect the Prophet (or others) which is strange.
Fault occurs when a buffer is zeroed out:
Thread 1 (process 11226):
#0 0xb7d09832 in bzero () from /lib/libc.so.6
#1 0xb7ee4579 in bristolbzero (mem=0x0, count=4096) at bristolcdefs.c:74
#2 0x0805eaea in operateHammondPostops (audiomain=0x81a59e0,
#baudio=0x81bd918, voice=0x82b94e0, startbuf=0x81c56b0) at
#3 0x0804de1a in doAudioOps (audiomain=0x81a59e0, outbuf=0x81c36a8,
#startbuf=0x81c56b0) at audioEngine.c:262
#4 0x0805f98a in audioShim (nframes=1024, jd=0x80babe0) at bristoljack.c:87
#5 0xb7f99574 in jack_client_thread (arg=0x81c2628) at client.c:1504
#6 0xb7de52d3 in start_thread () from /lib/libpthread.so.0
#7 0xb7d6b2fe in clone () from /lib/libc.so.6
The request has been made with 4096 bytes and I am pretty sure this will overrun the internal reservation. The workaround can be delivered reasonably quickly - have the whole lot exit gracefully when there is a mismatch.
The fix is rather more work, it is to revisit all the initialisation routines so they happen after the audio tap is opened. This is a pain in the butt since the audio emulations have to template themselves when the MIDI interface opens, then instantiate themselves when the MIDI interface requests an emulation, which in turn opens the audio interface. I would have to work on having the audio interface open and go idle before any MIDI work starts taking place.
Log in to post a comment.