• 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
SPBRecord Interrupts in OSX - problem with returned parameters
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SPBRecord Interrupts in OSX - problem with returned parameters


  • Subject: SPBRecord Interrupts in OSX - problem with returned parameters
  • From: Mark Gilbert <email@hidden>
  • Date: Sun, 25 May 2003 13:52:07 +0100

Folks.

I am using an SPBRecord call to real-time analyse sound arriving at the sound input.

Because I am not interested in saving the sound, and I am interested in accurate timing, I setup SPBRecord with an interrupt handler which is called whenever the hardware buffer fills (typically after 2048 bytes).

Alternatively, I can use the completion callback, with a fixed length buffer, then my callback schedules the SPBRecord call again.

Either way, I am called regularly to process the sound. The Callback approach seems to be less tight in timing, as you might expect, so I prefer to use the interrupt.

On OS9, both mechanisms work fine, however, in OSX, the Interrupt approach does not work properly.

I am not 100% clear on exactly what _is_ happening, since it appears that there is some kind of audio data in the buffer supplied to the interrupt, however the 'size' parameter sent to the interrupt (which tells the routine how big the buffer is), is set to 1 (rather than 2048, as it is under OS9).

The peak level reporting in the interrupt DOES work as expected. So, the problem is the buffer size returned to the interrupt, and also the integrity of the data in the buffer.

Consequently the function doesnt work properly. Even overriding the 1 in the interrupt with 2048 doesnt yield a good buffer of data. I am not clear exactly what is in the buffer because my app has no way of storing it, but its not the same data I get in the completion callback (also on a 2048 byte record), or in the same interrupt under OS9.

I saw a post from some time ago where someone suggested that the SPB->HAL compatibility layer may be flawed, and this could be causing this type of problem.

Does anyone know anything about this problem. It would seems from web searches that I am not the only person to see OSX problems with this interrupt.

Of course, I could use CoreAudio instead in OSX, and I am definitely up for that, but this is a VERY VERY simple job, and the only code example I can find for Coreaudio recording is Daisy, which is a massive chunk of code to wade through. if anyone has a really simple core audio example to grab audio in real time from sound input for rapid processing, please direct me. The main target for this code is OSX, so I am not attached to SPBRecord in any way apart from convenience, and my prior experience with it. One of the main places I want to integrate this code is into a Mach-O app, I am also not sure if I can use SPBRecord from Mach-O. My current tests are all Carbon.

Any info would be appreciated.

Thanks

Mark Gilbert
--
email@hidden
Tel: +44 208 340 5677
fax: +44 870 055 7790
http://www.gallery.co.uk
Check out the **new** mtools site at:
http://www.mtools.info
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: SPBRecord Interrupts in OSX - problem with returned parameters
      • From: Kurt Revis <email@hidden>
  • Prev by Date: Shouldn't AudioUnitRemovePropertyListener() accept refcon also?
  • Next by Date: OT: Custom UI design tools
  • Previous by thread: Using CATink (was Re: Shouldn't AudioUnitRemovePropertyListener() accept refcon also?)
  • Next by thread: Re: SPBRecord Interrupts in OSX - problem with returned parameters
  • Index(es):
    • Date
    • Thread