Re: handing audio dropouts with synchronized input and output
Re: handing audio dropouts with synchronized input and output
- Subject: Re: handing audio dropouts with synchronized input and output
- From: Stéphane Letz <email@hidden>
- Date: Tue, 07 Aug 2012 15:34:13 +0200
Here is a technotes form Apple site:
https://developer.apple.com/library/mac/#technotes/tn2091/_index.html
You may look at some relevant open source code:
From the Faust project:
http://faudiostream.git.sourceforge.net/git/gitweb.cgi?p=faudiostream/faudiostream;a=blob;f=architecture/faust/audio/coreaudio-dsp.h;h=537d5bf2b48d16bc1bb86c8940ed9a13b317e7c6;hb=e91948f0fb4d5b975ca47bd8b0e949aa30c482ee
LibAudioStream project:
TCoreAudioRenderer.h and TCoreAudioRenderer.cpp here (although the code is possibly not completely uptodate)
http://libaudiostream.cvs.sourceforge.net/viewvc/libaudiostream/libaudiostream/src/renderer/
From the JACK project :
https://github.com/jackaudio/jack2/tree/master/macosx/coreaudio
Or possibly PortAudio :
http://www.portaudio.com/
Stéphane Letz
Le 7 août 2012 à 15:18, christopher raphael a écrit :
> Stephane, Thanks very much for your response. I originally tried to get both input and output working on the same callback, but never succeeded in doing this. The way I got things working was to start from the CAPlayThrough example which sets up an AudioUnit for input and then creates a simple AudioGraph for handling the output. I simplified this example, somewhat, but still have the basic structure where I start separately both the AudioUnit and AudioGraph. So this highest level looks like, after initialization,
>
> err = AudioDeviceAddPropertyListener(outputDevice, 0, true, kAudioDeviceProcessorOverload, DeviceListenerProc, nil);
> err = AUGraphInitialize(mGraph);
> if (err) return(0);
> err = AudioOutputUnitStart(mInputUnit);
> if (err) return(0);
>
> err = AUGraphStart(mGraph);
>
> I can give more detail if that will help, but didn't want to overwhelm with things that may not be relevant.
>
> If you could point me toward an example for the Mac (not IOS) that does simultaneous input and output with a single callback and a single AudioUnit, I would be most grateful!
>
> Chris
>
> On Tue, Aug 7, 2012 at 5:04 AM, Stéphane Letz <email@hidden> wrote:
> >
> > Message: 1
> > Date: Sun, 05 Aug 2012 15:00:15 -0400
> > From: christopher raphael <email@hidden>
> > To: email@hidden
> > Subject: handing audio dropouts with synchronized input and output
> > Message-ID:
> > <CAKTokbZO06kckgkcr-rUmp3BuYq1a=email@hidden>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > Hello LIst, I am working on an application that has full-duplex audio in
> > which the times events are detected in the audio input will affect the
> > timing of events in the output. Thus I need to be able to relate times, in
> > samples of the input stream to times in samples of the output stream. This
> > is not hard to do since the timestamps associated with the input and output
> > callbacks give the actual sample times, so the difference in these two
> > timestamps on the first input and output callbacks gives a measurement of
> > the skew between these two streams.
> >
> > However, I don't understand how to deal with the case when I get audio
> > dropouts and the relationship between the input and output streams changes.
> > I have done everything I can to minimize these dropouts --- my input
> > callback just copies the audio data for processing in another thread, and
> > takes almost no time.
>
> Why that?
>
>
> > My output callback needs to do some processing to
> > generate the samples, and this takes about 1ms.
>
> Why are you using 2 different callbacks for input and output? What exact part of the CoreAudio API are you using?
>
> (duplex applications can perfectly be managed with a single callback that receive input buffers and have to produce output buffers... this is usually simpler to develop)
>
>
> > The time the callback
> > takes is very consistent from callback to callback. For context, my
> > callbacks have 1024 samples at 48kHz, so they occur about ever 20 or so ms.
> > The processing by other threads is significant, but still my program only
> > consumes about 20% of the processor resources on average. While this is
> > not the worst case, I assume that my callbacks would still get precedence,
> > so dropouts would be rare.
>
> CoreAudio callbacks are called in a "real-time" (time-constraint in OSX terminology) thread. This thread (if programmed correctly with no call to possibly blocking functions...) is obviously preempting any other bon real-time thread.
>
> > I get a dropout around once every 10 or 15
> > minutes running with the built-in audio hardware, which is too frequent.
>
> You should not see this kind of dropout, especially if using a buffer of 1024 frames.
> >
> >
> > 1) Is there anything I can do to eliminate or reduce the audio dropouts.
>
> - try to use a unique duplex callback
>
> - analyse your real-time callback code to check that it does not contains any possibly blocking functions (taking locks, file access...etc..)
>
> >
> > 2) When I get a dropout out what I want to happen is the following: It is
> > fine if the outgoing samples never make their way to the speaker and some
> > noise or other random audio gets spliced in instead, as long as I preserve
> > the relationship between incoming and outgoing samples that I started with.
> > This seems to be the default behavior with ASIO and may result from the
> > double buffering paradigm. How do I get this behavior? Any help with this
> > would be greatly appreciated.
> >
> > Chris
> >
>
> My feeling is that you should be able to solve the dropout issue in the first place.
>
> Regards
>
> Stéphane Letz
>
>
> _______________________________________________
> 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
>
>
>
> --
> Prof. Christopher Raphael
> School of Informatics and Computing
> Indiana Univ.
> 812-856-1849
_______________________________________________
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