• 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: Native Device Formats
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Native Device Formats


  • Subject: Re: Native Device Formats
  • From: Jeff Moore <email@hidden>
  • Date: Mon, 16 Jun 2008 12:06:11 -0700


On Jun 14, 2008, at 4:34 AM, Mikael Hakman wrote:

Thanks Bill - this sounds very interesting.

I understand that if a device driver provides (exposes) its native (wire) format as one of its client formats then that format could of course be used by clients. The problem is, not many devices do this, probably because vendors think that this "only 32 bit floats for clients" misconception is true. Either because of how this topic is described in documentation, including IOKit docs, and/or because many devices use system supplied class drivers that don't support integer formats for clients. Apple's own built-in device (driver) does not expose such integer formats to clients.

Some of our drivers do and some don't. For example, the built-in driver on my Mac Pro does not provide a non-mixable integer formats. But the USB Audio class driver does.


Note that the HAL won't show a process the non-mixable linear PCM formats (which would include any integer formats) in the format list until your process owns hog mode for the given device.

While you can ask a device (driver) what physical formats it supports/uses, I cannot find any way to force that format to be used as IOProc buffer format unless, as described above, the device provides this format also as its client format.

Yes, this is true. Support for this feature is contingent on the driver.

When using digital audio devices there is an option to use one of the encoded audio formats, which would (hopefully) output/input the exact bits you have/get. The problem with this is however that such format sets (should set) also the non-audio flag on the transport stream which would either make the receiving device to mute (according to AES/EBU spec) or try decoding it resulting in either static or silence or plain error.

This is generally why drivers need to know the difference between AC-3 data packed into 16 bit stereo samples and real 16 bit stereo samples.


That said, not all SPDIF devices I've run into over the years do the right thing in this regard. Many will send AC-3 without also setting the data bit in the SPDIF payload. I always test new hardware with the volume down at first =)

Therefore, could you please be a little more specific - which properties do you mean and which comments in the header file do you refer to? Even better, a simple example of requesting integer format to/from IOProc of e.g. built-in device would be extremely appreciated.

The easiest way to see this feature in action is to plug in a USB Audio spec compliant device and then open HALLab. You can use the device info window for the output side of the device to see the different versions of the available format lists (in the "Streams" tab) that show up when you take and release hog mode using the button in the "Info" tab.


--

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
  • Follow-Ups:
    • Re: Native Device Formats
      • From: "Mikael Hakman" <email@hidden>
References: 
 >Native Device Formats (From: email@hidden)
 >Re: Native Device Formats (From: Jeff Moore <email@hidden>)
 >Re: Native Device Formats (From: "Mikael Hakman" <email@hidden>)
 >Re: Native Device Formats (From: Jeff Moore <email@hidden>)
 >Re: Native Device Formats (From: "Mikael Hakman" <email@hidden>)
 >Re: Native Device Formats (From: Brian Willoughby <email@hidden>)
 >Re: Native Device Formats (From: "Mikael Hakman" <email@hidden>)
 >Re: Native Device Formats (From: William Stewart <email@hidden>)
 >Re: Native Device Formats (From: "Mikael Hakman" <email@hidden>)

  • Prev by Date: Re: Inconsistencies in getting kAudioObjectPropertyName
  • Next by Date: Re: Runaway clock?
  • Previous by thread: Re: Native Device Formats
  • Next by thread: Re: Native Device Formats
  • Index(es):
    • Date
    • Thread