Sorry for the delayed reply; just not enough time in the day.
1) On Dec 17, 2005, at 10:28 AM, Robert McGwier wrote:
I think the question was probably more than what tools but I
could be wrong.
No, I had gotten to the point where what tools was all I was
looking for. But your reply let me
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
On Sat, Dec 17, 2005 at 10:28:26AM -0500, Robert McGwier wrote:
gr-audio-osx should NEVER be blocked awaiting anything in gr.
No, but there are times when gr should block awaiting something in gr-audio-osx.
Eric
___
Discuss-gnuradio mailing list
Exactly. That was the point of my note. That direction is release from
gr-audio-osx using semaphores, flags, etc. but never does it by
releasing a mutex which has been acquired by gr since they (and will)
block the audio callback. If the data is not ready for the audio
callback, issue an
In implementing gr-audio-osx, I've figured out (after much debugging)
that 2 threads are conflicting (GR is 1 thread, CoreAudio is the
other), and thus I need a semaphore or equivalent ... needs to be
thread-safe. Does GR have a preference of what to use for this? Or
is it OS- and
On Tue, Dec 13, 2005 at 03:19:34PM -0500, Michael Dickens wrote:
In implementing gr-audio-osx, I've figured out (after much debugging)
that 2 threads are conflicting (GR is 1 thread, CoreAudio is the
other), and thus I need a semaphore or equivalent ... needs to be
thread-safe. Does GR
