pts@mendel.acc.Virginia.EDU (Paul T. Shannon) (08/17/90)
I'm in the midst of testing a data acquisition scheme which uses the C sound
functions (principally SNDAlloc and SNDStartRecording) and the codec microphone
port. I create a number of buffers (currently 5, of 2048 bytes each) which
get queued up, and then recycled continuously until some signature value
is encountered in the data stream. I pass a function to SNDStartRecording,
called 'bufferCompletionRoutine', which SNDStartRecording calls every time
it's filled one of my buffers, and it is this function which examines the
newly-returned buffer, and which puts this buffer back in the queue for re-use.
Unfortunately, some of the buffers don't get returned. Each is given
a tag, in ascending order, and bufferCompletionRoutine knows that it should
get the buffers in that same order. Other activity on my cube seems to be
the culprit. Sometimes a buffer gets lost right away, and sometimes thousands
get returned before a failure occurs. The size and number of buffers doesn't
seem to affect the problem.
I've mucked around with running this little test program at various priorities
and I found that a higher priority (meaning a reduced chance of being scheduled)
causes the program to run longer before failure. This is the opposite of
what I expected. If, while the program is running as the result of typing
nice +19 ./timedResp
and I type 'ps -am' in another window, this is what I see:
USER PID TT %CPU STAT PRI SYSTEM USER COMMAND
root 6599 p1 47.4 R N 94 0:01.01 0:22.76 ./timedResp
25.7 R 63 0:08.01 0:03.68
It looks as if the second line is a status report on a thread, maybe the
recording thread, or maybe the bufferCompletionRoutine. Interestingly
the command
nice +19 ./timedResp
doesn't affect the priority of the thread, though
renice +19 6559
lowers the priority of both the process and the thread:
USER PID TT %CPU STAT PRI SYSTEM USER COMMAND
root 6599 p1 56.1 R N 113 0:04.43 1:59.60 ./timedResp
28.3 R N 103 0:42.31 0:19.14
In either case, if there's not a lot of applications running on the cube, and
if I lower the priority of the program, it takes (on average) longer for a
buffer to get lost.
If I haven't confused you, or bored you -- if you're still with me, here's
my question:
How do I change the priorities of this program (and its thread) so that
I can absolutely minimize the chance of losing a buffer? Should I
kill all uneeded processes, all the way down to the window manager and
net daemons, and disabling cron?
On the other hand, if you think that this effort is foolish, and doomed
to failure, I'd be interested in hearing why you think so. (A few weeks
ago I posted a question on this general topic, data acquisition from the
codec port, and the net was dead silent, except for an in-person reply
from Steve Boker. Hope springs eternal, and so I'm asking for help
again.)
I will be very grateful for any help.
- Paul Shannon
pts@virginia.edu