Re: Performance differences between AudioFileWritePackets() and FSWriteFork()
Re: Performance differences between AudioFileWritePackets() and FSWriteFork()
- Subject: Re: Performance differences between AudioFileWritePackets() and FSWriteFork()
- From: "Roni Music" <email@hidden>
- Date: Fri, 23 Feb 2007 08:39:59 +0100
Sounds to me like you are hitting the system buffer cache in the
FSWriteFork case. I'll bet that the code that uses
AudioFileWritePackets is passing true for the inUseCache argument
while FSWriteFork code is forgetting to or in kFSNoCacheMask to the
mode argument.
I'm using the kFSNoCacheMask as a mode argument with FSWriteFork().
The buffer being filled is allocated with vm_allocate() so it's alligned to
a page boundary
and the position being written to in the file is on a page boundary and the
number of bytes is always
a multiple of 4096.
Even though this is "by the book" some writes takes about 50-100
milliseconds.
When I time AudioFileWritePackets() it's very stable (on my machine 12
milliseconds)
but it seems it only encodes the data and don't write it to disk.
If I check the file size during encoding (writing?), it's zero bytes untill
AudioFileClose() is called, then it seems the data is written.
The call to AudioFileClose() take longer and longer the longer the recording
is which seems to verify this assumption.
Also if I look in Activity Monitor, I can see how my program allocates more
and more memory for each "write"
and eventually releases it when AudioFileClose() is called.
So to me it seems that AudioFileWritePackets() caches the data and write
everything to disk once AudioFileClose() is called.
Is that the way it works?
It's not really a problem for my app that some calls to FSWriteFork() take a
long time, the data is written correctly
and the recording sound perfect. But it's an interesting why the file system
does what it does.
Rolf
One other possiblity is that even with kFSNoCacheMask, the request
might still hit the buffer cache if the buffer being filled doesn't
start on a page boundary or if the position being written to in the
file is not on a page boundary or if the amount being written is not
an even multiple of pages. From what you've said, it doesn't sound
like the last condition is a problem but the first two might be if
you're not careful.
On Feb 20, 2007, at 5:39 AM, Roni Music wrote:
My audio recorder application which is loosely based on the afrecord
example from the AudioFileTools example either uses
AudioFileWritePackets() to write the data
or, when I'm encoding an mp3 file with the Lame mp3, encoder it uses
FSWriteFork().
Everything works fine but when I'm timing the file writes,
AudioFileWritePackets() always takes very little time and always the
same amount but when
using FSWriteFork() now and then (quite seldom) it takes a very long
time, say 100 milliseconds.
I'm always writing chunks that are 4096*4 bytes and the offset in
the file is also always an even multiple of 4096*4 bytes and I have
the noCacheMask set.
From "gooogling" at lot about the best performance for file writes
on OS X this seems to be what should be done.
So my question is, how come that AudioFileWritePackets() works so
good, eventually it also have to write the data to disk with
FSWriteFork()
The writing is done in a secondary thread (as in the afrecord
example) and I'm on OS X 10.4.8 with a Intel iMac, same behavior on
a dual 1 GHz G4.
Any hints for improvements?
--
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