• 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: User-land CoreAudio driver and Leopard
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: User-land CoreAudio driver and Leopard


  • Subject: Re: User-land CoreAudio driver and Leopard
  • From: Stéphane Letz <email@hidden>
  • Date: Wed, 14 Nov 2007 21:37:35 +0100


While I should be the last to bring up error code usage, this usage of kAudioHardwareIllegalOperationError is probably not following the spirit of it's meaning. It would be better to use kAudioHardwareIllegalOperationError or to make up your own error code if you don't feel the standard ones quite match your semantics.

OK.



	3) it seems that the "coreaudiod needs to access the JackRouter
plug-in" to see it as a possible default input/output device can be
solved by just having the JackRouter plug-in check which process
loads it: if it is "coreaudiod" than we don't do the "jack server
running" step explained in 2) . Doing that and implementing
CanBeDefaultDevice allows the JackRouter to correctly be available
as a default input/output device.

Hmm. Can a user of the JackRouter plug-in inside the coreaudiod process, like the SSS, still talk to the jack server to do IO?

Note that if this can't happen because "it is more difficult to have
it running in the global context", you should be sure to say that your
devices cannot be the system default output device at minimum because
that's the device that the SSS uses to play it's sounds on from inside
of coreaudiod.

That is the case. The plug-in cannot be system default (but input/ ouput default yes). I don't think it is a real problem for us.


You need to make your device disappear from the device list in this
case using the standard methods available to you. If the device can't
be used, it should not be presented to the user. When the server gets
relaunched, then you can make your device re-appear on the system.

Actually I'm not even speaking of trying to update a device list for a given application *while* the applications is running!
Let me explain in another way with teh following sequence of actions:


- start the jack  server:

- open AMS, or Sound Preferences (or HALLab)

- since our jack server is running, the JackRouter plug-in will see that and thus appears as an available device for the application.

- select JackRouter as the default  input/output

- quits AMS:

- stops jack server

- open AMS: AMS tries to "restore" JackRouter as the defaut input/ output, but since the jack server does not run, the JackRouter plug- in throw this kAudioHardwareIllegalOperationError and thus is not available as a possible device

- AMS does display the list correctly: the list is even completely unsable (grayed)

Since this is the responsability of AMS to access the device list and display correctly, what can be done?


That's a fine idea. Note that you'll be overriding HP_Device::StartCommandExecution and HP_Device::FinishCommandExecution to lock and unlock that guard when API calls that affect the IOProc list are made.

Yes I did that also.

I'm not sure it matters, but it may be helpful if you described how this callback mechanism works. At the very least, I'll have a fuller picture of how your engine works and can provide better guidance on mapping the SDK onto it.


In StartHardware: a duplex audio callback is started: this callback use the mIOProcList object to retrieve all IOproc that have been added. Its uses the state of the IOproc and the stream usage to do only what audio processing is really needed.


Remember, the HAL makes the guarantee that the app can call any API
function from any thread context at any time and the right things will
happen. This guarantee has to be lived up to by your plug-in too.

If your engine can't deal with that, then you need to put in place the
proper thread synchronization stuff to protect your engine. Note that
it is expected that most (and possibly all, I haven't thoroughly
checked recently) HAL API calls will probably block. Further, most of
the API calls don't have any particular guarantees about timing. You
can exploit this to your advantage when mapping the API onto your
engine.

Well since SampleHardwarePlugin does not suffer this weird behaviour when used with DVD Player ot QuickTime Broadcaster, I'll have to follow all code path to see was is lacking in our code.


Stpehane 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


  • Follow-Ups:
    • Re: User-land CoreAudio driver and Leopard
      • From: Jeff Moore <email@hidden>
  • Prev by Date: Re: User-land CoreAudio driver and Leopard
  • Next by Date: Re: User-land CoreAudio driver and Leopard
  • Previous by thread: Re: User-land CoreAudio driver and Leopard
  • Next by thread: Re: User-land CoreAudio driver and Leopard
  • Index(es):
    • Date
    • Thread