Re: audio computation and feeder threads
Re: audio computation and feeder threads
- Subject: Re: audio computation and feeder threads
- From: Kurt Bigler <email@hidden>
- Date: Sat, 01 Mar 2003 12:55:57 -0800
on 2/28/03 8:24 PM, Lionel Woog <email@hidden> wrote:
>
Typically, an IOProc will be called with a 512 frames request. If you can
>
generate that much in or close to real time you are fine. If you cannot
>
always do it (i.e. You generate 8K frames at a time, so the lag to provide
>
the first 512 frames is large), then you need a feeder thread that
>
pre-computes and buffers the data.
The code can generate as many frames as you like at a time. As it stands,
the synthesis code runs in each IOProc thread, and generates all the frames
requested. So this kind of lag is not the issue currently.
The issue is that I can use up an arbitrary amount of CPU time in the
synthesis. The better the synthesis the more CPU time it takes. I want to
have the best synthesis possible that allows an adequate number of
simultaneous oscillators, and I don't want any part of the process to be
avoidably "wasteful", nor do I want to be using any less than the maximum
fraction of the total CPU that is conceivably available. Other apps running
is not an issue, because this the system is dedicated to the application,
except to the extent that there are processes that I can not stop which will
always be using up a little bit of the cpu.
So for example, doing all my synthesis without any special effort to "make
use of" the 2nd cpu in my own code leaves me able to syntesize 300 or so
voices (oscillators) simultaneously, at a quality level that I have
currently chosen as "adequate". This is "ok" but 500 voices would be much
better. So I want to rethread my synthesis so the scheduler will be more
likely to run it in whatever time might otherwise be idle on both CPUs.
Doing the synthesis for 2 devices in their respective 2 ioprocs did not end
up giving me a significant advantage, and I need to find out if there is
something I can do to improve this, or if for example I have hit some limit
of memory/cache bandwidth for the algorithm I am using. (The answer is not
to buy a new computer, because there is no fixed limit on what is enough.
Any efforts to improve things now will greatly improve the value of the next
computer I would buy.)
So in short, I need to use all of the CPU I can get hold of to optimize my
current situation given the equipment I currently have. There are several
possible target areas for improvement, and one of them is to make better use
of threads. Any efforts put there that "solve the problem" in a general way
make it possible to avoid doing specific optimizations of specific synthesis
methods that I might abandon next month.
I figure getting the thread management right is part of getting my basic
development platform right - it opens up all the other possibilities.
The other main point in using a feeder thread approach is to smooth out the
rough spots. If I can generate X oscillators in real time "on the average"
but various "random" factors (such as scheduler behavior, and other running
processes) make it impossible to achieve that rate continuously, then I have
to add some buffering slop so that the potential "average" rate can be
realized in a glitch-free way.
Come to think of it, that kind of buffering can be done without introducing
another thread (i.e. still within the IOProc), so the compelling reasons for
a feeder thread may be the the issues of multiple cpus, multiple IOProcs,
and the HAL 90% issue.
Hope that clarifies some.
-Kurt Bigler
>
>
I believe that you will find core audio very able at keeping itself fed.
>
>
> I am trying to glean from all the information which has gone by on this list
>
> what I need for a general plan for thread design in my app. I would like to
>
> focus for the moment on the case of audio output only, when the audio is
>
> being synthesised algorithmically. I would specifically like to include the
>
> possibility of multiple IOProcs being active to support multiple output
>
> devices running at once.
>
>
[snip]
>
>
>
>
>
> Thanks,
>
> Kurt Bigler
>
> _______________________________________________
>
> 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.
_______________________________________________
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.