Re: Reading and writing from/to sound devices without AU
Re: Reading and writing from/to sound devices without AU
- Subject: Re: Reading and writing from/to sound devices without AU
- From: Rick Mann <email@hidden>
- Date: Wed, 09 Mar 2011 19:18:56 -0800
I already wrote some code as an Audio Unit, and that works fine. But there are times when I want to process the incoming data (which happens to be in the audio spectrum, of sorts, but isn't necessarily audio data) and produce something that is distinctly NOT audio. In this case, I won't be outputting any sounds, and Core Audio won't be calling me to ask for samples.
Moreover, I'll have to put my processed data somewhere, and somehow connect my UI to it. I may have a handle to my AU instance at this point (since my app would be hosting the AU), so that is probably not too much of a problem.
--
Rick
On Mar 9, 2011, at 19:13:39, James Chandler Jr wrote:
> Hi Rick
>
> I don't know much about it, but wonder if you need an audio unit.
>
> If your purpose is to access the radio data and convert it into sound playing on the Mac audio output--
> If your main application has access to the radio data stream--
> If your processing is fast enough to run in the Mac audio thread--
>
> Well, probably your DSP would need to be fast enough to run on the Mac audio threads even if it is inside an audio unit. Unless you get clever with threading.
>
> ====
>
> In Developer/Examples/CoreAudio/SimpleSDK is a simple example app "DefaultOutputUnit".
>
> That simple "DefaultOutputUnit" example opens a sound channel to the Mac's "default output unit" and then stuffs a sine wave into playback buffers when the "default audio unit" pulls data.
>
> You could monkey-see-monkey-do this simple app but substitute your DSP code where the example contains the simple sine wave oscillator code.
>
> If it takes a lot of CPU overhead to fetch your raw radio data, then your main program loop might want to load the radio data to memory so the DSP can find it when your DSP gets called by the Default Output Unit. Your DSP callback would get invoked running on the Mac's Default Output Unit thread, and so if your main program loop is fetching the raw radio data, it would in effect be multi-threaded without you having to intentionally break it into multiple threads. The main program thread would be fetching data and your callback code running on a CoreAudio thread would be sending converted audio.
>
> If your DSP code gets called by the default output unit and your DSP does not have sufficient data to do its thing, then write your DSP code to return zeroed out buffers and nothing bad happens except an audio dropout.
>
> The Mac's default output unit seems pretty bulletproof. I use playback code derived from that example. I can debug step thru my callback code and the mac just keeps cooking (except for audio dropouts of course). If your callback handling happens to be too slow then it doesn't seem to destabilize the Mac. It just causes dropouts.
>
> That is pretty nice compaqred to some other computer audio API's. Some other computer audio API's have been known to be temperamental and risk crashing the app or the bring down the entire system if you can't promptly service the audio callbacks. Debugging on some computer audio API's is like walking on eggshells because of that. It is relatively easy on the Mac.
>
> James Chandler Jr.
>
>
> On Mar 9, 2011, at 9:10 PM, Rick Mann wrote:
>
>> I'm doing DSP on the data from a software defined radio. It presents itself as an audio device to avoid requiring custom drivers.
>>
>> But some processing can result not in audio data, but arbitrary digital data. I need to constantly get samples from the device, and push them into my processing pipeline, rather than relying on Core Audio to pull data from my audio units. If I choose not to output audio, AU would probably stop processing. Also, shoehorning in an output stream of ASCII characters into an AU seems inelegant, at best.
>
>
>
_______________________________________________
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