Re: Audiofile buffering
Re: Audiofile buffering
- Subject: Re: Audiofile buffering
- From: Philippe Wicker <email@hidden>
- Date: Wed, 9 Jul 2003 22:33:48 +0200
On Wednesday, July 9, 2003, at 03:11 AM, Brian Willoughby wrote:
[ > Why is it a bad thing to use the VM as a buffer?
[
[ This is not a "bad thing" per se. This is just not an efficient
[ use of the memory.
Efficiency depends upon your usage patterns.
For playback of audio, which is nearly always sequential, VM is
inefficient.
There is no point in keeping around data which has already been played.
Besides not needing old data (unless you loop), playback is highly
unforgiving
of random delays in access time.
For display of audio waveform data, which is often random access, VM
is highly
efficient. The absolute best way to find a happy balance between
memory
allocation and speed of access is to allow the VM system to page
things in and
out based on your usage. Display of audio data for human visual
consumption is
quite accepting of the occasional delay in access time associated with
VM.
I believe that the trouble would be in trying to use the same
buffering and
caching techniques in you playback engine as your display engine.
They're two
vastly different beasts, although it is understandably tempting to
share the
data since it starts out the same.
Another thing to consider is that playback audio wants to be float (in
CoreAudio), while waveform data wants to be in screen resolution
(which is
often much less detailed than the 25-bit audio). So, you really
should be
buffering float samples for playback, and pixel coordinates for
display.
This is certainly true if you use QuickDraw, but if you rely on Quartz,
then using the float samples is Okay because pixel coordinates are
expressed as float in that case.
[ If you had to load several huge files such as the one you mention
[ (88MB after conversion to Float32), you would have a lot of page
[ faults (the system would be swapping all the time) and likely
[ audio drops while playing.
Are you sure?
Yes. I'm sure ... to be wrong :-/
My remarks about the drawback of "loading" huge files come from a total
misunderstanding of how file mapping works. I thought - shame on me
(please don't throw the first stone ...) - that the system will attempt
to load as much as it can. Hence my words about swapping, etc...
Fortunately, the system designers have chosen a much more clever
solution which is - as you say - to differ the load until you actually
need the data. Which makes it a good solution for the display.
The whole point of VM is that it does not page anything in
unless you touch the data. The page faults will not cause any *more*
disk
access than any other method of touching the data.
[ ... Besides, the mapping of the file to the memory does not
[ guarantee that all pages are resident in the physical memory (at
[ least that's what I believe but I may be wrong). They may be
[ loaded from disk only when data are accessed (after a page fault).
[ Here again, you may experience audio drops.
Ah, here you contradict yourself. I think you're right, though. All
those
88MB files won't be paged in unless needed.
Then again, if the program is designed to read an entire audio file and
convert it to float by saving in a new, temporary file, then you're
going to
thrash the disk unnecessarily.
I agree with you. I was actually arguing against this choice.
My advice to Mark was to buffer for playback using a completely
different
scheme than caching for display. Playback buffering can be designed to
eliminate dropouts, while display buffering can speed screen updates by
reducing redundant calculations.
The only question that remains for me is: if you're already using VM
to access
the source audio data when creating the display cache, you might as
well use
it to fill the buffers. If your playback buffering is sufficient to
protect
CoreAudio from starving in the event of a busy disk, then the
unpredictable
access time of VM should not pose a problem. Sure, if you are not
displaying
waveform data, you really should not use VM to access the audio file,
because
you have no need for random access. I'm only saying that when
combining random
access display with sequential access playback, you might want to
simplify
your code by using VM to access the file.
This may be indeed the good choice.
Brian Willoughby
Sound Consulting
Philippe Wicker
email@hidden
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.