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: "Glenn McCord" <email@hidden>
- Date: Sat, 5 Jul 2008 10:30:22 +0000
On Fri, Jul 4, 2008 at 12:04 PM, Mikael Hakman <email@hidden> wrote:
> 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.
Is making a copy of the inInputBuffer going to copy the AudioBuffer
array called inInputBuffer->mBuffers[0] or is it going to copy an
address?
Should I memcpy mBuffers[0] with:
memcpy(savedAudioBufferList->mBuffers, inInputBuffer->mBuffers,
sizeof(AudioBuffer)) ?
>
> BTW, why do you use a loop and copy each sample separately? Why not use
> memcpy and copy the whole shebang at once?
I was trying to use memcpy initially but for some reason I couldn't
get the application to work. I can't remember the details now, so
maybe it was some other code that was causing the grief.
I'm assuming I can only memcpy that void * mData array by itself and
not the AudioBufferList struct in its entirety.
memcpy( savedBuffer->mData, savedBuffer->mData, inputBuffer->mDataByteSize);
My code is at work and I don't have a mac, so I can't test things until Monday.
Thanks for the help.
>
> 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