• 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: RemoteIO glitches - cured by propListener audio route change?!
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RemoteIO glitches - cured by propListener audio route change?!


  • Subject: Re: RemoteIO glitches - cured by propListener audio route change?!
  • From: Gregory Wieber <email@hidden>
  • Date: Fri, 7 Jan 2011 21:19:04 -0800

The advice isn't conflicting: stick to c/c++ for remote io procedures.


Sent from my iPhone

On Jan 7, 2011, at 6:41 PM, Morgan Packard <email@hidden> wrote:

Your post has scared me a bit, since I've been using Objective-C extensively. I've been getting some conflicting bits of advice regarding whether it's appropriate to call objective-c code from the RemoteIO callback. Do you have more specific ideas about what was causing your glitches? Was it the non-cached selector calls described here http://lists.apple.com/archives/cocoa-dev/2006/feb/msg01735.html, or perhaps something else involving locks?

thanks,

-Morgan

On Mon, Jan 3, 2011 at 3:48 AM, jhno <email@hidden> wrote:
I cured my mysterious audio glitches, by switching the objects used by my RemoteIO perform() callback from Objective C to C++.

I saw a reference to this phenomenon from James McCartney in the archives. Apparently Objective C selectors can invoke housekeeping tasks that can cause unexpected execution time.

In my case, the result was reliable and inexplicable audio glitches.

There was nothing fancy about the Objective C code. So this is something to keep in mind - !

jhno


---

On Dec 15, 2010, at 2:11 PM, jhno wrote:

> Greetings,
>
> I have an iPad app with an audio engine based very closely on the AurioTouch code example.
>
> When I start the app, the synthesized audio is interrupted by glitches - which seem to be comprised of unprocessed signal vectors that contain the microphone input instead of my synthesized output. In other words there are bursts about every second where the perform() callback is not invoked.
>
> The glitches go away completely when I plug headphones into or out of the iPad. My propListener is invoked, it calls SetupRemoteIO, makes a new RemoteIO, and everything is fine - !
>
> However, if I manually try to call my propListener by another mechanism (NSTimer, UIButton), the audio still glitches.
>
> Does anyone have any idea what could be causing this behavior?
>
> I have been looking into this for a long time now and am totally flummoxed.
>
> thanks,
> jhno
>
>

 _______________________________________________
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



--
================================
Web:
http://www.morganpackard.com

Mobile Phone:
(646) 206-8337

Music/Art:
Album Moment Again Elsewhere available Oct 11.
iOS app Thicket available on iTunes store.
================================

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: 
 >Re: RemoteIO glitches - cured by propListener audio route change?! (From: jhno <email@hidden>)
 >Re: RemoteIO glitches - cured by propListener audio route change?! (From: Morgan Packard <email@hidden>)

  • Prev by Date: Re: RemoteIO glitches - cured by propListener audio route change?!
  • Next by Date: Re: RemoteIO glitches - cured by propListener audio route change?!
  • Previous by thread: Re: RemoteIO glitches - cured by propListener audio route change?!
  • Next by thread: Re: RemoteIO glitches - cured by propListener audio route change?!
  • Index(es):
    • Date
    • Thread