Re: Performance differences between AudioFileWritePackets() and FSWriteFork()
Re: Performance differences between AudioFileWritePackets() and FSWriteFork()
- Subject: Re: Performance differences between AudioFileWritePackets() and FSWriteFork()
- From: William Stewart <email@hidden>
- Date: Fri, 23 Feb 2007 11:20:05 -0800
On 22/02/2007, at 11:39 PM, Roni Music wrote:
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.
AudioFileWritePackets doesn't do any encoding - its responsibility is
to write the data to the disk - the data that you provide it.
If I check the file size during encoding (writing?), it's zero
bytes untill AudioFileClose() is called, then it seems the data is
written.
This is a quirk of the implementation of MP4 and M4A files in Tiger.
All of the other file types will write their data to disk when this
is called. In Leopard, these file types (MP4, etc) will also behave
in the proscribed manner
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.
if you want to actually see the writes (and their durations, etc),
run a tool called fs_usage (it has to be run as root:
% sudo fs_usage
check the man page for details of the various options you can use
with this.
Bill
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
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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