Re: Problems when changing sample rate on a aggregate device
Re: Problems when changing sample rate on a aggregate device
- Subject: Re: Problems when changing sample rate on a aggregate device
- From: Stéphane Letz <email@hidden>
- Date: Thu, 6 Dec 2007 22:00:41 +0100
On Dec 5, 2007, at 1:21 PM, Stéphane Letz wrote:
Message: 2
Date: Wed, 5 Dec 2007 11:47:35 -0800
From: Jeff Moore <email@hidden>
Subject: Re: Problems when changing sample rate on a aggregate
device
To: CoreAudio API <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed;
delsp=yes
Which device is the master device
On Dec 5, 2007, at 6:12 AM, Stéphane Letz wrote:
- Mac Pro Tiger 10.5.1 using an aggregate device that combines
built in input and built-in output :
- when changing SR in AMS *on the aggregate device*,
notification
listener is called, stream converter are updated (that is no
error)
but device *stops* working ...
Define "stops working".
IO callback not called anymore.
Gotcha. But it all works again if you hit play, right? What does the
IO cycle telemetry show?
- when changing SR in AMS *on the built-in output device* (that
is subdevice of aggregate one), notification listener is *not*
called...
Sounds like the built-in output device is not the master device in
the
aggregate, which would make this a normal situation as the sample
rate
of an aggregate is the sample rate of the master device.
Ok i'll check again. But what is supposed to happen is the SR of a
sub-device that is not the master is changed?
That sub-device will get dropped from the aggregate. If it was the
master device that changed, then the other, non-master, sub-devices
will get dropped.
OK. So changing one of th sub-device SR appears to be a quite
"disruptive" event. Not sure our application can deal with that (that
is is input or ouput device just disappear...) Are applications
supposed to deal with this kind of context change? Any notification
that should be listened to?
So they are several strange things: device stops working, and
notification listener *not* called when SR change is done on one of
the aggregate subdevice. Should I fill a bug report here?
So far, I haven't seen anything that resembles a bug.
Except that when I try exactly what you describe with HALLab, I
don't
see playback stopping. I see the file player in HALLab stop, handle
the rate change (or stream layout change or whatever), and then
restart. I never see it just stop.
Ok I was not precise enough. Actually:
- changing SR from AMS on one sub-device of the aggregate device, no
change in HALLAB
Pretty much as I'd expect given what you've said about things so far.
- using the file player tool in HALLAB, changing SR from AMS on one
sub-device of the aggregate device, file player stopping....
Nope, still works the way I expect it to on my machine. Is there any
context info you might be leaving out?
Actually HALLab File player seems to handle correctly when SR change
are done directly on the aggregate device (not on the sub-device
which makes sense). But iTunes for example stops playing, and has to
be stopped/started again after a SR change, GarageBand refuses to
switch to the new SR (probably forcing back its own SR) but transport
keeps moving, but without sound.
In our application the SR change listerner is called but IOProc is
not called aymore. Setting the new SR in the AUHAL converters and
starting again the AUHAL (AudioUnitStart) works only in some cases like
- we start the application at 44.k ==> switch SR to 48k in AMS ==> SR
change listerner called ==> use AudioUnitStart ==> AUHAL start again
- we start the application at 48k ==> switch SR to 44.1k (or 96) in
AMS ==> SR change listerner called ==> use AudioUnitStart ==> AUHAL
does not start...
- we start the application at 96k ==> switch SR to 44.1k (or 48) in
AMS ==> SR change listerner called ==> use AudioUnitStart ==> AUHAL
does not start...
So if SR change is so problematic, maybe the best is to stop spending
too much time on that...
Stephane Letz
_______________________________________________
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