On Thu, 2012-03-08 at 21:40 +0100, Clemens Ladisch wrote:
Jonathan Andrews wrote:
Using the static libasound without pthreads now.
Process still stalls in same way:
ARM / # strace -p 408 Process 408 attached - interrupt to quit futex(0x15a684, FUTEX_WAIT, 2, NULL
So it's not a call from alsa-lib.
The alsa code is a conditional compile, as is that for the /dev/dsp device. Only the alsa version fails, the version that just takes data from the network and mixes it does not fail.
cc udp-many-way-audio-rx.c -DARM -DALSA -lasound -lrt -lm -o udp-many-way-audio-rx_alsa_arms --static Fails randomly
cc udp-many-way-audio-rx.c -DARM -DDUMMY -DSTATIC -o udp-many-way-audio-rx_dummy_arms --static Dummy version, never fails. Still has network code and my audio mixer.
Its not as if I'm linking in a lot of libs...
An strace of a stall (intel this time) is here. Its 2GB and on a slow link (sorry). http://www.jonshouse.co.uk/download/a_stop.txt
If only there were a tool to compress files ...
Ok, i'm pretty tired I admit it .... 30MB http://www.jonshouse.co.uk/download/a_stop.txt.gz
The futex address 0xae5320 occurs only once at the end of the text file so I have no idea what sets it up.
Can't you attach gdb to your process?
I need to build an arm version, will work on that next.
Or at least log where in your program you are?
I did that, best I can tell it enters one of these two functions but never exists. Makes sense as these are the two conditional compiles wrapped around #ifdef ALSA in the main loop. http://www.jonshouse.co.uk/download/udp-many-way-audio-playsample-alsa.c
(If strace has too much overhead, write to a variable, and run a thread that waits for keyboard input and prints the variable.)
The strace (now gzipped) is the same process as the arm running (and then stalling) on the PC. It still stalls, just takes (on average) longer to stall on the faster machine ......
Thanks, Jon