• 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: Recommended way to setup a timer in a CoreAudion application
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Recommended way to setup a timer in a CoreAudion application


  • Subject: Re: Recommended way to setup a timer in a CoreAudion application
  • From: Stéphane Letz <email@hidden>
  • Date: Fri, 18 Jan 2008 09:07:49 +0100


Message: 2 Date: Wed, 16 Jan 2008 12:24:54 -0800 From: Jeff Moore <email@hidden> Subject: Re: Recommended way to setup a timer in a CoreAudion application? To: CoreAudio API <email@hidden> Message-ID: <email@hidden> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes

As I've said previously, the IsRunning notification is probably the
most reliable notification the HAL provides. It doesn't lie. If it
reports that it is running. The IO thread is up and running because it
is supposed to be up and running. Note that this doesn't not
necessarily mean that IOProcs will be getting called as IO could have
been started by passing NULL as the IOProcID to AudioDeviceStart()
which just starts the hardware and the device's timing services.

The HAL also will stop and restart the IO thread (yielding appropriate
IsRunning notifications) across large scale driver state changes as
well as when the driver sends pause/resume messages which normally
bracket things like format changes. This is especially true of
aggregate devices which stop and then start again when any state
change that might affect the make up of an aggregate device happens
(for example, when the sample rate changes on one of the sub-devices).

Throw in the fact that you've had numerous misunderstandings about how
things work on the very basic level and I'd say that until you fully
debug this, you don't really know what is going on. I really encourage
you to drill down and find out more about the problem. I suspect that
you have made some faulty assumption again somewhere.


So maybe a "Technical Note" about how an "Apple following guidelines" application should behave/recover when the user (or another application) messed up the devices... (in particular the so "easy to understand case" of "aggregates" ones) would help? Written by the guys who know for the poor but many ones that have "numerous misunderstandings"?


Thanks

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


  • Prev by Date: Re: How to programmatically change the default sound output device?
  • Next by Date: Re: How to programmatically change the default sound output device?
  • Previous by thread: Re: Quick converter question from a CA newbie
  • Next by thread: the format flag kLinearPCMFormatFlagIsPacked
  • Index(es):
    • Date
    • Thread