Kjetil S. Matheussen wrote: > > BTW, non of the machines I tested on had the sched_getcpu function, so I > added "#define sched_getcpu getpid" to the file. Ok. In Debian this is in libc6-dev (utmpx.h). The purpose of calling sched_getcpu is to check whether the reader and writer threads are running on a different cpu or not. > Machine 1: 8 X (core Intel(R) Xeon(R) CPU E5320 @ 1.86GHz) > === Jack ringbuffer test === > 60288 != 60160 at offset 0 > failure in chunk 373678 > Rest was success > > Machine 2: 1 X (AMD Sempron(TM) 3000+) > Success Success Success > > Machine 3: 3 X (Intel(R) Xeon(TM) CPU 2.80GHz) > === Jack ringbuffer test === > 16640 != 16512 at offset 0 > failure in chunk 2300164 > Rest was success AFAICS your only single-cpu system passes the test. SMP fail. > ------------------- > Machine 4: SunOs 5.8 sun4u sparc SUNW,Ultra-4 Solaris > :-) > > The jack test compiled fine. > > Portaudio version: > "portaudio/pa_ringbuffer.c", line 121: #error: Memory barriers are not > defined on this system. You can still compile by defining > ALLOW_SMP_DANGERS, but SMP s > > Also: > $ ./test-int-array-jack > starting ringbuffer stress test (2 minutes max) > Segmentation Fault Ok, Try this: make test-int-array-jack make test-int-array-portaudio-nobarrier ./test-int-array-jack 512 ./test-int-array-portaudio-nobarrier 512 I'm curious to see whether Portaudio's ringbuffer fail when it has no memory barrier, on non-x86/unusual architectures. -- Olivier Guilyardi / Samalyse _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
