Re: A simple 'Device Through' app (need some help).
Re: A simple 'Device Through' app (need some help).
- Subject: Re: A simple 'Device Through' app (need some help).
- From: "Mikael Hakman" <email@hidden>
- Date: Fri, 4 Jul 2008 14:04:05 +0200
- Organization: Datakonsulten AB
On Friday, July 04, 2008 5:41 AM, Glenn McCord wrote:
Just to bring this thread full circle again, I was able to make a
console 'through' application by looking at the Portaudio source code.
They used to use a HAL implementation which is coded inside
pa_mac_core_old.cpp.
With the help of that code and some other sources, I was able to make
a console application that plays through the inputs and straight to
the outputs. Unfortunately I get very regular, almost rhythmic popping
(imperfections in the audio) with frame sizes up to 2056 (I haven't
tried higher). This is despite being able to use Portaudio with a
frame size of 64 with no audio imperfections.
As much as I don't want to, I have attached the code to this email
with the hope that something really really obvious is causing the
problems.
Essentially I'm using the following code flow
- Find the input and output ids of my device
- set the sample rates and frame buffer size for the device
- set up and input and output callback
- make a temporary AudioBufferList object to store the input data so
that it can be copied to the output
Then the callbacks do their thing and data gets copied from input to
output.
One of the guys suggested that Portaudio does some kind of extra
buffering, but that would have to be some significant buffering.
Just a couple of points:
- My device is regarded as two devices, input and output.
- If I create a sine wave programatically and copy that data straight
to output, then I get no imperfections in playback.
Hopefully my issue is relatively simple, but I've been at this all
week and need a bit of help.
If I understand your code correctly then in your AudioInputProc, the
statement:
(*savedAudioBufferList) = (*inInputData);
copies contents of inInputData structure to savedAudioBufferList structure,
both of which are of AudioBufferList type. AudioBufferList is defined as:
struct AudioBufferList {
UInt32 mNumberBuffers;
AudioBuffer mBuffers[kVariableLengthArray];
};
Constant kVariableLengthArray is defined as:
enum {
kVariableLengthArray = 1
};
This means that the copy operation copies entire inInputData->mBuffers[0]
including its mData member over to savedAudioBufferList. After copy,
savedAudioBufferList->mBuffers[0].mData will point to the same area as
inInputData->mBuffers[0].mData. Which means that nothing will be buffered
and your original in Start() allocated buffer area is lost. In your data
copy loop latter on, you "copy" the contents to itself. Your AudioOutputProc
works therefore on the original data address passed to your AudioInputProc
by your audio driver which at that time was returned to your driver and
probably is reused again for new samples.
BTW, why do you use a loop and copy each sample separately? Why not use
memcpy and copy the whole shebang at once?
Regards/Mikael
_______________________________________________
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