Re: Some more questions about sample rate notifications
Re: Some more questions about sample rate notifications
- Subject: Re: Some more questions about sample rate notifications
- From: Jeff Moore <email@hidden>
- Date: Mon, 14 Jan 2008 14:33:53 -0800
On Jan 14, 2008, at 1:38 PM, Stéphane Letz wrote:
- an application (like Max/MSP or Ableton Live) or even the user
using Audio Midi Setup is changing the SR of a *real* device used in
an aggregate one.
Yes. I follow.
- the aggregate device get confused: it's output part (for example)
just disappear .
- the aggregate device then is not "duplex" anymore!!
This is all behaving as it is supposed to behave. I think the trouble
is that you misunderstand how aggregate devices work.
Recall that all sub-devices of an aggregate device have to be at the
same sample rate as the master sub-device. Also, the sample rate of an
aggregate device is always the same as the rate as the master sub-
device. Any sub-device whose rate is different from the master sub-
device's rate is dropped from the aggregate, although it will be
picked back up when that sub-device's rate matches the master sub-
device's rate again.
So what appears to be happening in the case you are describing is that
one or more of the sub-devices in the aggregate you are using have a
sample rate that no longer matches the master sub-device's rate and
thus are getting dropped from the aggregation.
As I said, this is exactly what is supposed to happen. The problem
seems to be that your app doesn't know what to do when a device's
stream configuration changes radically like this case shows can happen.
- trying to setup back the current SR is not a good strategy OK, OK
I'm not sure that this is why things are confused given the above, but
you shouldn't try to "win" the race to be the last app to set the
sample rate. Bad things can only come of it.
- what I am I supposed to do in my application? (which is actually a
server that cannot warn the user so easily). Just fail??
Yes. Why is failing such a bad thing?
Either you have to fail outright and put up an alert to tell the user
what happened or you need to implement some kind of fail-over to
another device. This is exactly what an application should be doing
anyway. It's part of the app's job description to re-evaluate the
state of a device when said state changes dynamically and handle the
changes in a sensible way, whatever they may be.
I understand that maybe a lot of applcations are not doing the right
thing. The question is WHAT TO DO NOW?
It would seem that the root cause of your problem are that your app
fails to account for the rather radical state changes that can come
about when using aggregate devices. I think if you address this, not
only will your app work better under these circumstances but I imagine
that it will be much more robust to changes in hardware state in
general. Which is a good thing.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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