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: Tue, 8 Jul 2008 16:09:43 +1200
On Tue, Jul 8, 2008 at 4:34 AM, Mikael Hakman <email@hidden> wrote:
> On Monday, July 07, 2008 4:50 AM, Glenn McCord wrote:
>>
>> Thanks, that clarifies a few things.
>>
>> On further playing around, it seems that both Portaudio's old HAL
>> implementation and consequently my HAL through code is still popping.
>> Portaudio's newer AUHAL implementation is fine though.
>>
>> I'm trying to add input AudioBufferLists to a queue for the output
>> callback to work its way through, but it has proved unsuccessful so
>> far. I still get lots of popping.
>
> Well, one thing you could of course do is to look at the new Portaudio
> implementation. What do they do that you don't? By a coincidence, I was
> looking into their Kernel Streaming (Windows) implementation just yesterday.
> It was highly readable.
>
It's almost completely different on account of them using AudioUnits
and the AUHAL; something that I was trying to avoid.
> Otherwise, I would set out to investigate why there is this popping.
> Understanding what is wrong usually helps finding a remedy. In this case, it
> could simply be that the machinery in the OS or in the driver is not capable
> of sequentially calling 2 callbacks (in and out) on the same thread from the
> same driver. Another problem could be that sometimes yours AudioInputProc or
> AudioOutputProc is called twice without intervening call to the other one.
>
> This could be assessed very easy by using a global 3-state flag (initial,
> in-called, out-called). Then in your IOProcs you could check and set this
> flag and output an error message if the sequence is wrong:
>
> int state = 0;
>
> Then in AudioInputProc:
>
> if (state == 1) {
> ERROR
> }
> state = 1;
>
> And in AudioOutputProc:
>
> if (state == 2) {
> ERROR
> }
> state = 2;
Yes, this is happening. Almost all pops I get will be because of an
input or output callback being used twice in a row. I thought
buffering the input AudioBufferLists to a queue would solve this, but
it didn't. What I did was add all input AudioBufferLists to the queue,
then have the output callback pop an AudioBufferList from the front of
the queue. I checked, and there is no situation where there isn't
something in a queue, because the input callback is called about 50
times before the output callback starts. The queue stays at roughly 50
in size, thus the output callback should always have audio to play.
>
> Another experiment is to prepare a buffer containing known signal, e.g. 1
> kHz sine wave. Buffer size should be such that concatenating 2 buffers would
> still produce continuous wave. Then you could perform 2 experiments, doing
> exactly what you already do. In first experiment you could add another
> memcpy at the end of AudioInputProc copying the above 1 kHz buffer over real
> data. In the second experiment you could do the reverse in AudioOutputProc.
> Is popping still there?
I'm not sure if I'm following you here. What I have done is
programatically created a sine wave and given it straight to the
output. This gives no popping. I have also done a separate test where
I copy that sine wave to the input buffer, add the resulting input
buffer to the queue and then let the output proc dequeue it and pass
it to the output buffer. This unfortunately, does result in popping
and will happen when the output callback or input callback is called
twice in a row.
One oversight I fixed which might have been in that original code I
posted, was all the use of malloc inside the callbacks (whoops).
It seems the major issue here is synchronisation between input and
output callbacks and that is something I'm going to need advice over,
because I really though buffering the input would have solved that.
I really appreciate the help you've given in regards to this mess I have.
Glenn
>
> The final experiment in AudioInputProc would consist of writing (appending)
> buffer contents to a file. No special format is needed, just binary bits.
> Close the file at the very end of your app. Then in another app, without
> AudioInputProc, you could in AudioOutputProc successively read this file
> into output buffer. If it still pops then the popping is already in the
> input.
>
> 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