Re: What AudioFileWritePackets() caching means?
Re: What AudioFileWritePackets() caching means?
- Subject: Re: What AudioFileWritePackets() caching means?
- From: Jeff Moore <email@hidden>
- Date: Tue, 26 Apr 2005 14:13:48 -0700
The "inUseCache" argument is there to provide a hint to the AudioFile
API that the data being read/written should not be run through the
file system's caches.
Basically, it has the same effect as setting kFSNoCacheBit in the
positionMode argument to FSReadFork or FSWriteFork.
On Apr 26, 2005, at 1:38 PM, Lubor Prikryl wrote:
Hi,
I have meanwhile written a standard swapping buffers in an
independent thread, but disk Write still takes so much CPU with
such a priority, that it can disturb my high priority thread.
I think, that caching write and caching read operations to/from
slow media is a big difference, but there is an option for both of
these operations in Audio File API, so I am still interested what
it means.
Lubor
On 26.4.2005, at 11:22, philippe wicker wrote:
On Apr 26, 2005, at 11:01 AM, Lubor Prikryl wrote:
Hello,
I am recording to an aiff file using AudioFileWritePackets(). I
expected that with inUseCache set to true I can write data in the
audiothread (= they are cached and written in another thread).
But actually CA thread is interrupted by writing to disk.
Do you mean from time to time or at each render callback?
inUseCache - true if it is desired to cache the
data upon write, else false
Please, could someone explain what this caching really means?
I think, not absolutely sure though, that this is an indication to
the underlying FileManager layer. I dont know how this hint is
actually used by the FileManager (ie if the FileManager just
relies on the disk cache managed by the OS or if it has its own
one). Usually, a write cache is used to temporarily save data
until they are flushed e.g. because the cache is full, or because
a size threshold has been reached. In that case the flushed data
are written to the disk. I'd tend to think that this is done
within the calling thread context (the audio thread in your case)
and not delegated to a worker thread, which could explain your
interrupts.
Philippe
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40centrum.cz
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
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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