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: Mon, 7 Jul 2008 18:34:02 +0200
- Organization: Datakonsulten AB
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.
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;
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?
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