Re: FLLR (compression ?) in AIFF file
Re: FLLR (compression ?) in AIFF file
- Subject: Re: FLLR (compression ?) in AIFF file
- From: "Stephan M. Bernsee" <email@hidden>
- Date: Thu, 14 Aug 2008 09:49:10 +0200
On 14.08.2008, at 09:00, Brian Willoughby wrote:
Bill offered a multi-threaded solution, saying that you can simply
create one ExtAudioFile object per thread.
I could also use AudioFile for this, which is multi threading savvy.
You dismissed this outright, with nothing more than a vague claim
that you cannot do this in your application for various reasons.
Would it be so difficult to mention the reasons?
No, not at all. In our TimeFactory application we have the ability to
play back the file that is being processed (offline), as well as the
destination file where the processed audio is written to. The render
callback of our AudioEngine happens in a separate thread, as does the
call that refills the playback buffer. Offline processing is done in
the main thread. Most of this is code has to stay cross platform,
hence we cannot change it and need the access to the actual files in a
way that is compatible with this mechanism and its classes.
I didn't mention it because this is not relevant (it is mostly due to
our code design which predates CA and OS X, and not due to CA itself)
- I mentioned the multi threading issue because this is a stumbling
block for someone who is new to CA.
Perhaps I should rephrase this: if the ExtAudioFile instance that I
create would keep track of the thread that it was created in and would
simply fail to access the file instead of crash that would be easier
for a developer to understand and debug.
Conversely, I'd like to know what you mean when you say that you
expect this to "just work."
What I meant was that it would be good if ExtAudioFile allowed file
access across multiple threads without crashing, or would at least
fail in a graceful way. I realize that there are complicated
conversions going on that need to set up and maintain state, though,
so this might not be easy.
...I don't see how Apple can improve the situation without more
information.
Like I said, I am totally happy with CA as it is and with the code
that I have that uses it. Bill asked me why I would feel compelled to
use something other than CA in the first place, and he also indicated
(at least that's how I interpreted his response) that he would be
interested to know the stumbling blocks that developers encounter. I
was just mentioning a couple of things that I could remember from the
time when I started using the API a couple of years ago and I
explained why I still use miniAIFF for some more recent projects
(cross platform compatibility).
Like I said before, you can work around the CA issues if you know
where to look, and you can and should spend time reading through the
documentation and the example code (which in some instances isn't very
good at explaining all of this, however). I see a lot of people asking
the same questions here which is no doubt because they're expecting
something that looks different. To me, this is always a sign that a
FAQ might come in handy (or that the documentation is insufficient),
or that the API might need to be improved.
Btw. The main reason for miniAIFF's existence is cross platform
compatibility, not my being unable or unwilling to use CA. This has
nothing (or I guess you could also say everything) to do with
Apple... ;-)
Best wishes,
Stephan
_______________________________________________
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