Re: Audio glitches during playback thru Remote IO unit (iPhone)
Re: Audio glitches during playback thru Remote IO unit (iPhone)
- Subject: Re: Audio glitches during playback thru Remote IO unit (iPhone)
- From: "Zhiye (Sterling) Li" <email@hidden>
- Date: Thu, 13 Aug 2009 16:28:55 -0500
Hi Bill and Steve,
Thanks a lot for replying. I wish it was not a complicated problem. I guess I should study more on the threading chapter. So Bill, do you mean using p-thread is the solution to my problem? Sorry, I am new to all theses... So the idea is to lock the rendering thread while doing file i/o ?
hi steve, I saw the examples from the link in your reply, however, his code only works for short files, because he pre-loads the entire audio file to memory before playback, which will not work for long files, especially on iPhone. But still thanks a lot!
-Zhiye
On Wed, Aug 12, 2009 at 4:55 PM, William Stewart
<email@hidden> wrote:
Reading from the file system can take locks, and it does so unconditionally, so you can block and you will miss your deadline, and you hear gaps. So, you don't do this.
The render callback from an audio unit that is attached to an audio device (AURIO or AUHAL on the desktop) is running within the context of a deadline driven thread. The deadline is the time represented by a particular request to produce some amount of audio data - say 512 frames at 44.1KHz, means that you have to provide that full amount of data (no more, no less) within that time period (which is approx 11msec)
Things that take locks, so you don't do it in the render thread:
- reading or writing to the file system
- malloc or free (also operator new / delete that would to a "normal" memory allocation pool)
- unconditional lock aquisition (in this case you can do a try, and be prepared to NOT obtain the lock - CAMutex has some examples of the difference between Lock and Try using p-thread constructs)
Then of course, there's the general problem of just taking too much time (ie, running computations that take more time than you have available)
Welcome to core audio :)
Bill
On Aug 12, 2009, at 12:02 AM, tahome izwah wrote:
I think it is discouraged to do synchronous reads within a render
callback. You should have a separate reader thread and queue up your
audio buffers in memory until they are needed for playback.
--th
_______________________________________________
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
sterling.li@
gmail.com
_______________________________________________
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