• 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: Questions about HAL API.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions about HAL API.


  • Subject: Re: Questions about HAL API.
  • From: David Duncan <email@hidden>
  • Date: Tue, 9 Nov 2004 10:40:07 -0500

On Nov 9, 2004, at 09:33 AM, Tobias Rundström wrote:

Hello.

I have written a native CoreAudio outputdriver for XMMS2. The output is working fine but I have some questions.

I hear a quite loud *bang* when I init a song. I thought that is was related to the fact that I am not sure if I fill the buffer fully, I can't see a way for telling CA that my buffer isn't entierly full. Let me show you the code:

There isn't any way, CoreAudio tells you how much it wants and you give it. If you don't have a full buffer, you have to pad it out to silence yourself.


As you see there are other questionmarks arising when reading this code.

* Do we know that the buffersize that CA is requesting will stay the same between the requests? In that case I don't have to re-alloc the bufferpointer each time.

As long as a reconfiguration isn't signaled, the buffer should stay the same size.


* Is there someway to let CA accept 16bit signed int PCM data instead of 32bit float. There are some things about this in the headerfile but it doesn't seem to work when I try to use them.

You would have to discover if that is a format for the device and change the device format, but this isn't really what you want...


All input on this is appriciated.

It's great that you figured out how to write to the HAL for all this. But you made your life too difficult. Most of us don't write to the HAL directly, instead we use Audio Units. Basically code chunks that you can chain together to do lots of nifty things. In your case, you can create a Default Output Unit and an Audio Converter, connect them together, feed the Audio Converter 16-bit int (and interleaved, because I bet that is what your producing) and live an easier life. Because you are writing to the HAL, there are all manner of notifications that you need to be aware of and track to be a good client -- with an Output audio unit that is handled for you. And if you ever want to provide special effects it's only a few lines of code to add any number of filters to the rendering chain.


If your going to switch to Audio Units, just make sure that you use V2 units (requires 10.2+). There are more of them, they are easier to configure and use and they are the future. The AudioUnit framework and it's headers should point out the functions that work with/return V1 AUs so you can avoid them. Good luck!
--
Reality is what, when you stop believing in it, doesn't go away.
Failure is not an option. It is a privilege reserved for those who try.


David Duncan

_______________________________________________
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: 
 >Questions about HAL API. (From: Tobias Rundström <email@hidden>)

  • Prev by Date: Re: Coreaudio-api Digest, Vol 1, Issue 66
  • Next by Date: Re: Coreaudio-api Digest, Vol 1, Issue 66
  • Previous by thread: Questions about HAL API.
  • Next by thread: A word of advice on using AUParameterListener and AUEventListener with UI
  • Index(es):
    • Date
    • Thread