• 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: AudioDeviceRead failure
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AudioDeviceRead failure


  • Subject: Re: AudioDeviceRead failure
  • From: "Mikael Hakman" <email@hidden>
  • Date: Wed, 13 Aug 2008 11:57:56 +0200
  • Organization: Datakonsulten AB

On Wednesday, August 13, 2008 12:37, John Huan wrote:

Hi, Everyone,

I am trying to write a HAL Hardware Plug-In based on
SampleHardwarePlugIn code. I need to tap on the default sound output
and record any sample sent to the device.
The plugin can compile and load properly when any process uses HAL
starts up. But, the problem is, when I try to read the sample out of
the device using AudioDeviceRead, it always returns false.
According to the suggestions came from Jeff's answer on the other
mailing list item, I added a function call to register the buffer list
at first, like this:
AudioDeviceSetProperty(inDevice, NULL, 0, inIsInput,
kAudioDevicePropertyRegisterBufferList, sizeof(bufferList),
&bufferList);
But, it also returned failure with error code
kAudioHardwareUnknownPropertyError.

Does that means the default built-in output device doesn't support
direct sample reading?

Is there another way to do that?

One way to do it is to let your HAL Hardware Plug-in mirror your real device. It will have to pass all application calls down and all callbacks up. When doing this it will have to replace on-the-fly, both ways, all IDs, names, and UIDs (device, stream etc) with own IDs that it obtained from HAL when registering own things. Then you will have access to all BufferLists passed to and from your real device. As Jeff writes, this will be on a per process (application) basis. You will need some IPC design and code if you want to conceal input/output to/from all applications. I do things like this in my virtual device that provides volume control for devices/streams that do not expose/have own volume controls (such as built-in optical and others). It's a long way to go.


Another and perhaps simpler way, if you only consider built-in devices, is to connect another Mac digital input to your Mac digital output and then record on this second Mac everything output by the first Mac. This is why we do have both outputs and inputs :-) Output is for playing, input is for recording.

Regards/Mikael

_______________________________________________
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: 
 >AudioDeviceRead failure (From: John Huan <email@hidden>)

  • Prev by Date: REPOST : Conflict between Standalone Audio Apps not sharing the same audio device
  • Next by Date: QTMovie quality
  • Previous by thread: Re: AudioDeviceRead failure
  • Next by thread: REPOST : Conflict between Standalone Audio Apps not sharing the same audio device
  • Index(es):
    • Date
    • Thread