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