Re: Streaming audio to built-in audio device
Re: Streaming audio to built-in audio device
- Subject: Re: Streaming audio to built-in audio device
- From: "B. Mitchell Loebel" <email@hidden>
- Date: Mon, 07 May 2007 21:10:11 -0700
Thank you Mark and Andrew.
I need to think overnight about what you've written. Good stuff.
Btw, the app that I'm trying to construct in the Mac is identical to one
I've built in a separate DSP based player. The difference is that in the
case of my dedicated player
I have direct
software control over both threads! In the Mac case I need to
(so to speak) remotely control the AU thread.
Btw, point of info ... my stream is 160 samples/frame with each sample
being 2 bytes wide ... 16KSamples/second. I misspoke originally when I
laid out the parameters.
More tomorrow.
At 05:19 PM 5/7/2007 -0700, Mark Pauley wrote:
The main issue as far as I can
tell is that you must be careful to not block in the Audio render
callback (note that I didn't mention a separate audio thread, because the
API appears to be agnostic to this implementation detail). This
means that if you have more processing to do, you've got to do it right
then (afaik it's not a no-no to do some processing in the render
callback). So what you've got here is a producer-consumer problem
with the caveat that you may have to switch the execution context over if
your consumer is starved.
I would say that if you think about this, and perhaps write a custom
runloop source for the producer, that you may well be able to get this
all working without any locks whatsoever.
In fact, now that I've thought about this some more, you should just be
able to have two global queues and no RunLoop Sources (if you don't mind
polling and wasting cpu). Your producer would pull a buffer out of
the "empty" queue, fill it and once it's absolutely done, toss
it into the "complete" queue. Your consumer would pull
from the complete queue, or send a buffer filled with one single value
(memset would come in handy). You can put the buffer back into the
empty queue at the very beginning of the next audio interrupt. If
two buffers isn't enough, consider using more. Also, consider
sending as much data to the converter as requested.
_Mark
On May 7, 2007, at 2:52 PM, B. Mitchell Loebel wrote:
Thank you Mark and the several
other members of this list ... superb!
I still have a few questions:
- your function 'AudioConverterFillComplexBuffer ()' is the function I
will use to fill a buffer to which the AU will refer to obtain data.
My app has two buffers and I want to assign a pointer
(ioData) to a filled buffer each time the callback function is called.
Important ... how do I synchronize
my app's setting (writing) the buffer pointer and
the AU's using (reading) that pointer? Mutexes, semaphores ...
????
- Here's a cute question ... my buffers are 80 samples long with each
sample being 2 bytes wide. If my processing is not yet ready to hand off
a full buffer to the AU, I want the AU to use the last single sample
from the current buffer until I'm ready. And I want the AU to
continue checking to see if I'm ready, i.e. poll. Of course, a better way
would be for the AU to continue using the last sample until my thread
pulls an interrupt to hand off the OK buffer pointer. How do you suggest
I do these things please?
- What is meant by 'inBusNumber' and 'inNumberFrames' in
the renderCallback() function?
Thank you again.
At 11:59 AM 5/7/2007 -0700, Mark Pauley wrote:
Posting this back to the list,
as the example I'm posting should go to the archives.
I applaud your stubbornness, and would like to say that your post was
intriguing enough for me to wonder if I could do this easily.
So... over the weekend, I wrote more or less what you're talking about: a
command-line C tool that can render to a signed-16bit buffer at
16khz.
The code posted at the bottom is essentially the simplest code I could
think up for doing what you ask, it took me about 2.5 hours from start to
finish to get it up and running, then I went outside because the weather
was nice :). Let me know if it works for you, and if you have any
questions.
I agree that such an example may be useful to those who wish to keep to
the lowest common denominator. If you'd like the program to end a
bit more gracefully than ctrl-c then you'll have to install a signal
handler or some such that stops the main runloop.
_Mark
~~~~~~~~~~~
(snipped ... see previous email from Mark for the code he
suggested.)
---
B. Mitchell Loebel, Executive
Director
408 425-9920
The Tech Startup Connection
(formerly The PARALLEL Processing Connection)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden