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: William Stewart <email@hidden>
- Date: Thu, 3 Sep 2009 16:09:43 -0700
On Sep 1, 2009, at 7:35 AM, Andreas Falkenhahn wrote:
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;
This is fine (and correct) as you describe below, when using an audio
conveter and its input proc.
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...
Having a guess, I would say that you are also trying to use the same
technique (above) on an audio unit's render callback. You can't.
You can do one of two things:
(1) Most safe is to set the mData pointers to zero (memset(...) - as
this sets silence. If you do this, setting the render action flag's is
silent bit is helfpul. This is basically what you are doing above I
think and why this works.
(2) return an error from the render callback. this *should* work as
the AU will just disregard your input (you don't have any), and a
mixer should just ignore that input and go to the next one.
Bill
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
_______________________________________________
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