Re: Very short junk audio signal on 10.5 x86
Re: Very short junk audio signal on 10.5 x86
- Subject: Re: Very short junk audio signal on 10.5 x86
- From: "Andreas Falkenhahn" <email@hidden>
- Date: Tue, 01 Sep 2009 16:35:22 +0200
On 31.08.2009 at 09:34 Doug Wyatt wrote:
>You really shouldn't be allocating or disposing memory (or objects
>like AudioConverters) on the audio I/O proc, which is the thread on
>which the AU render notification is issued. That will block I/O and
>cause audible glitches.
Ok, thanks for clearing that up. I'm taking care of this now.
Another question: I noticed that when setting
ioData->mBuffers[0].mData = NULL;
ioData->mBuffers[0].mDataByteSize = 0;
*ioNumberDataPackets = 0;
in my ACComplexInputProc() to signal the end of the data, there's
a sound glitch whenever two or more channels are on the mixer
unit, and one of them is still playing. If there's only one channel on the
mixer, setting these to NULL/0 simply results in a mute sound. But when
there are multiple channels on the mixer and one is still playing while the
other one has already finished, I'm getting a glitch on the finished channel
that continues until the other channels have finished, too.
To work around this, I've to pass a silent buffer (all zeros) to mData
and set byte size and data packets accordingly. Then it's working
fine but I'm wondering if this behaviour was intended? IIRC it's legal
to set these to NULL/0 when there's no more data...
Any ideas?
Tks
Andreas
--
"Remember: It's nice to be important but it's more important to be nice!"
_______________________________________________
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