Re: Logic not responding to Audio Engine Changes?
Re: Logic not responding to Audio Engine Changes?
- Subject: Re: Logic not responding to Audio Engine Changes?
- From: BlazeAudio Developer <email@hidden>
- Date: Wed, 30 Aug 2006 09:39:20 +0530
At 10:18 PM 8/28/2006, Jeff Moore wrote:
On Aug 24, 2006, at 11:13 PM,
BlazeAudio Developer wrote:
By default, the driver creates 2
Input Audio Streams and 2 Output
Audio Streams. Each has 8 channels.
All streams are: Linear PCM, 32bit(wide and deep), signed int, big-
endian, mixable.
When Logic starts, it effectively shows 16 channels for input and
16
for output.
Due to one of the changes, we remove all the streams, and again
create 4 streams - 2 input, 2 output. But this time, the channel
count is as follows:
Input 1: 8 channels
Input 2: 4 channels
Output 1: 8 channels
Output 2: 4 channels
When this happens, if HALLab is running in the background, it
correctly detects this, and displays the updated streams (including
proper channel counts, and new stream IDs).
However, Logic continues to show 16 channels for input and 16 for
output (on PPC - this has been tested on both G4 and G5 machines, I
can provide more specs if you think that would help!).
Logic does not necessarily view losing channels as catastrophic. I
believe that it just handles it by pretending they still exist on
the
understanding that they might come back in the future. Perhaps one
of
the Logic folks on the list can comment on this.
I understand that.
However, we tried it the other way around. When Logic started, there were
12 channels. And then, while Logic was open, the channels increased to
16, and still Logic was only showing 12!
Not only that, we
still get clipOutputSamples and
convertInputSamples calls in our driver with the old Stream
objects!!!
This is the problem I'm interested in and was what I wanted to know
how you were detecting this and more importantly, does it stop
eventually and start getting called with the proper formatted data?
I know that it does not start getting called with the proper formatted
data.
I will have to put some additional checks to see whether it eventually
stops on the old stream.
One thing you
should keep in mind is that the communication between
your driver and the apps out in user-space is asynchronous. That is
to
say, your driver can make it's changes, but the apps aren't going
to
know about the changes immediately. In fact, it is quite common for
performClientIO to be called while you are in the middle of making
the
changes. As such, there will be a few of these that will use the
wrong
format. The right thing to do is to either handle this situation
and
preserve as much of the data as you can or you can simply return an
error.
Okay, that's good thing to keep in mind!
Although, it was my understanding that the AudioEngine, and so it's
corresponding user client shares the AudioDevice's work-loop, so if our
code is making any changes, performClientIO() would not actually do
anything, until our code would return. Am I mistaken there?
[I do realize that that would still not prevent the performClientIO from
doing it's work with possibly stale information, at least once!]
Thanks.
Devendra.
_______________________________________________
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