• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Problems when changing sample rate on a aggregate device
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems when changing sample rate on a aggregate device


  • Subject: Re: Problems when changing sample rate on a aggregate device
  • From: Jeff Moore <email@hidden>
  • Date: Wed, 5 Dec 2007 13:42:36 -0800


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.



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?


--

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
References: 
 >Re: Problems when changing sample rate on a aggregate device (From: Stéphane Letz <email@hidden>)

  • Prev by Date: Re: Problems when changing sample rate on a aggregate device
  • Next by Date: Re: Quick question on configuring an AU for a certain channel config
  • Previous by thread: Re: Problems when changing sample rate on a aggregate device
  • Next by thread: Re: Problems when changing sample rate on a aggregate device
  • Index(es):
    • Date
    • Thread