Re: WaveIn notification methods
From: Chris P. [MVP] (msdn_at_chrisnet.net)
Date: 10/15/04
- Next message: Chris P. [MVP]: "Re: ACM driver unique idendification"
- Previous message: Denis Maidykovsky: "ACM driver unique idendification"
- In reply to: Grant Schenck: "WaveIn notification methods"
- Next in thread: Grant Schenck: "Re: WaveIn notification methods"
- Reply: Grant Schenck: "Re: WaveIn notification methods"
- Reply: Alexander Grigoriev: "Re: WaveIn notification methods"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 15 Oct 2004 09:18:17 -0400
Grant Schenck wrote:
> "Are you using waveInOpen( )? If so, have you tried with different
> callback modes, such as CALLBACK_FUNCTION, or CALLBACK_THREAD?"
>
> I looked at the docs and CALLBACK_THREAD seems to involve a windows
> message. Searching on goggle the opinions I saw seemed to recommend
> against using it. What to you folks think? Is there any point in
> replacing CALLBACK_EVENT with CALLBACK_THREAD if I'm trying to achieve
> high performance audio?
>
> What about CALLBACK_FUNCTION? I assume that is better then
> CALLBACK_THREAD but is there any reason to think it would be better
> then CALLBACK_EVENT?
Many many many many years back I was having the same dilemma as you trying
to decide what to use. So many choices! I wrote a test program that
implemented all the different methods to see what would work best. Here
were my discoveries:
CALLBACK_WINDOW - Seemed ok at first, but fell apart when there were many
window messages flying about. Perhaps the simplest method to implement.
CALLBACK_FUNCTION - Essentially useless because you can't do any audio
handing in the callback. You're choices are to signal an event or post a
window message, why created this method beats the **** out of me.
CALLBACK_THREAD - Didn't work much better than CALLBACK_WINDOW. Makes the
code a little cleaner and allows you to elevate the thread priority of the
worker thread for a slight performance improvement.
CALLBACK_EVENT - Worked well on the NT systems. Requires a dedicated worker
thread to operate at full potential. The worker thread must be using
WaitOnSingleObject() or WaitOnMultipleObjects(), using any function call
that generated or processed messages such as MsgWaitForMultipleObjects()
seemed to have a negative impact on performance.
Now the method you probably didn't think about - CALLBACK_NULL. Yes you
might be suprised to find out that the lowest latency solution in many cases
is not to use any callback method at all but rather to poll the buffer
flags. Polling at a rate of 100 to 200 times a second can get you latency
in the 20ms range at the expense of a little CPU power. It really doesn't
use much if you throw a Sleep(5) into the loop. Obviously this requires a
dedicated thread and ideally the thread should be set to
THREAD_PRIORITY_TIME_CRITICAL. Make sure there is absolutely no code in
this high priority thread that can block or you will bring the system to
it's knees. That means no disk I/O, network etc.
Which one to use for lowest latency? CALLBACK_EVENT is typically the best,
and with special audio drivers can achieve latency down in the 5ms range.
Second best, if CALLBACK_EVENT doesn't work out is polling. It's not really
worth trying to get the latency too low with WaveIn/Out unless the
manufacturer of the audio device has supplied special drivers as your going
to be hit by the kmixer 30ms delay anyway.
-Chris
- Next message: Chris P. [MVP]: "Re: ACM driver unique idendification"
- Previous message: Denis Maidykovsky: "ACM driver unique idendification"
- In reply to: Grant Schenck: "WaveIn notification methods"
- Next in thread: Grant Schenck: "Re: WaveIn notification methods"
- Reply: Grant Schenck: "Re: WaveIn notification methods"
- Reply: Alexander Grigoriev: "Re: WaveIn notification methods"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|