Re: What sort of timer should I use for my sequencer?
Re: What sort of timer should I use for my sequencer?
- Subject: Re: What sort of timer should I use for my sequencer?
- From: Aran Mulholland <email@hidden>
- Date: Fri, 4 Feb 2011 08:37:12 +1100
The problem I have found with generating and queuing up audio on a separate thread on iOS devices is with thread priority issues. The render thread has a high priority level. It always gets fired. I don't know the reason for this, If it is hardware interrupt related or if the thread setup is done correctly. I find that if I create my own threads when there is heavy user interface interaction the user interface thread receives the priority and my thread might not get any run time. This happens when pushing a view controller or if the user was to do something like continuously move a UISlider back and forwards. If that user interface interaction continues and i have not queued up enough audio to play then i get glitches. I think on a multi core device, or one with a higher clock speed this would not be an issue or the problem might be that I do not know how to schedule threads correctly. The problem is a lot more pronounced on an iPod touch 3rd gen compared to the iPhone 4.
On a side note Morgan, I had a look at your code and the amount of audio you were queuing up on your background thread was just enough (i think) for only one render callback, If you queued up a lot more your code would run better using this system as your thread probably did not have the same priority and even one miss would result in glitches. However as I can not offer any solid advice on thread scheduling or priority this advice coming from me probably doesn't mean much.
If any knowledgable person out there can tell me how to set up the thread to fix these issues I would be very grateful.
Aran.
On Fri, Feb 4, 2011 at 3:46 AM, Garett Shulman
<email@hidden> wrote:
Has there been discussion of mach_absolute_time on this thread? Would that not be the correct solution for multimedia timing?
On Feb 3, 2011, at 9:28 AM, Morgan Packard wrote:
Tahome,
Here you go. This actually didn't work well for me. I also tried using a ring buffer, also didn't work well. In order to get glitch-free audio, I had to increase the latency by a noticeable amount. I wound up just going back to the old, "bad" way I was doing it before -- generating all of my audio data inside the render callback.
-Morgan
On Sun, Jan 30, 2011 at 5:23 AM, tahome izwah
<email@hidden> wrote:
I'd be interested to check it out, just for reference, if you don't mind...
Thanks
> I set it to highest priority -- 1. It's working well now, but not 100%
> perfectly. I'm pretty sure the last time I tested it, I got a few
> glitches as the app was entering the background.
>
> Here's my code relating to this threading stuff:
>
>
http://tinypaste.com/1ef85b
>
> Happy to share the entirety of my remoteIO callback / buffer /
> threading code if anybody asks. It ain't pretty, but it seems to be
> getting closer to the right way to do things.
>
> -m-
_______________________________________________
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
--
================================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)
This email sent to
email@hidden
_______________________________________________
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
_______________________________________________
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