GoogleCodeExporter
commented
8 years ago I discussed this issue with Michael Coffey in private email before I posted this
issue and he asked me to include the texts of our conversations in this thread.
Here
are the messages:
Michael Coffey:
Are you sure that you need to put it in a separate thread? As far as I knew,
thread
priority is only relative within a process and it's the process priority that
really
matters. If another process is higher priority and is hogging the CPU, there
is not
much you can do about it. The active scheduler doesn't have much to do with
this.
If the audio was skipping due to things we are doing in our thread then I could
see
that it could be an active scheduler usage problem, but our problem is because
of
another process.
Have you tried giving the main thread a priority of real time without changing
anything else? Maybe this thread priority has some special properties.
Having said this, if it works, it works. I'm just trying to make sure we don't
make
things too complicated unnecessarily.
Steve Punter (pbextreme):
>Are you sure that you need to put it in a separate thread? As far as I knew,
>thread priority is only relative within a process and it's the process priority
>that really matters.
I couldn't find anything in the documentation to suggest that the priority of a
THREAD was affected by the priority of its spawning process. This isn't the
case any
other operating system I've programmed for, nor does it appear to be case with
Symbian either.
>Have you tried giving the main thread a priority of real time without changing
>anything else? Maybe this thread priority has some special properties.
The API call to change the priority of a PROCESS (I.E you running application)
is
restricted to no higher than EPriorityHigh. The documentation says that if you
try to
apply a value higher than this, it will panic. I proved that by attempting to
set the
priority of the application to EPriorityRealtimeServer, but like they said, a
panic
occurred and the application closed. There is NO restriction on the priority of
a
thread, and you can set that priority INDEPENDENTLY of your application's
priority.
>If another process is higher priority and is hogging the CPU, there is not much
>you can do about it. The active scheduler doesn't have much to do with this.
That's true, but the explanation of the problem was that because the stream
engine
used Active Objects to schedule its access to the hardware it was at the mercy
of
other Active Objects running in your SYSTEM. Here's an excerpt from a message I
found
on this subject:
>> If you want latency free streaming audio with no glitches due to other
active objects
>> running on your system, then you absolutely MUST implement the audio
streaming in
>> a high priority (preferably real-time priority) worker thread ... trust me,
it
does work,
>> I'm currently doing real-time multi-threaded audio on multiple platforms.
>> It is totally necessary.
>Having said this, if it works, it works. I'm just trying to make sure we
don't make
>things too complicated unnecessarily.
It DOES work, like a charm. As for the complexity, that's mostly locked up in
the
classes I've written. The modifications to your existing code are relatively
minor by
comparison. That's why I created the CAudioControl class. It does all of the
necessary work to interface with the thread (such as using Mutexes to serialize
access to shared data).
Michael Coffey:
Each thread has its own active scheduler, so other active objects in the
"system"
don't matter. It's just whether your thread gets to run or not.
I guess that the benefit of putting this in another thread is that if another
process
hogs the CPU, when our process get its time slice, that time will be spent on a
thread that is dealing only with audio playback rather than a thread that is
dealing
with downloading mp3 data or updating the screen, etc as well.
Steve Punter (pbextreme)
Original comment by pbextreme@gmail.com on 20 Dec 2008 at 6:18
Original issue reported on code.google.com by
pbextreme@gmail.comon 20 Dec 2008 at 6:13