Robert McGwier wrote:
...A sound
system callback wants to feed and be fed and never get blocked. When it
has new data, it should issue a semaphore release on the dsp/data
processing system...
To generalize this just a very little bit: any sort of mechanism will
do, that will let the DSP processing block until the arrival of new data
from the audio subsystem.
We happen to prefer semaphores when using pthreads, but that's entirely
because the alternative under pthreads would be a combination of mutexes
and condition variables. The alternative would mean more lines of code
to accomplish exactly the same effect as semaphores. For uniformity we
also use semaphores to guard critical sections, since there's no real
overhead incurred over mutexes.
Along the same lines, where there are native blocking message queues, or
an attractive library implementation like Eric is providing, that might
be an even better choice than semaphores.
The basic point is that barriers or mutexes are not rich enough on their
own for the callback/client DSP processing model. Some additional
scheduling mechanism is necessary. It's most sensible to take advantage
of whatever the OS or application environment provides for that purpose.
If you're slightly crafty the implementation details will be hidden
behind an opaque API layer anyway.
Frank
AB2KT
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
