how to measurewaveIn staggering

Hello,

I am developing a HAM radio digital modes chat-like software, which
uses sound input and output as a modem.
The application is for free at http://pocketdigi.sourceforge.net

Some of the digital signal processing methods are quite CPU intensive.
User may select mode, for which the CPU power is not sufficient. In
worst case the waveIn messages are processed first, there will be no
idle times so WM_PAINT will never be sent and the application will
respond to user interaction extremely slowly if at all. I would like
to detect this case and offer the user to switch to a less CPU
intensive mode.

My application is pure Win32 written in C. My first attempt was to
detect cases when the main message loop does not idle for a long time.
This seems to work quite well, but fails when I open a message box.
System function DialogBox creates its own message loop and my
detection of Idle state does not work anymore. I believe writing a
custom replacement of DialogBox will work, but I am a bit worried that
some dialog functions like common accelerators will not work. I expect
troubles with Smartphones. On Desktop there are message hooks, but on
Windows CE they are not officially supported.

The other idea was to measure time the messages (mainly the waveIn
messages) spend in application message queue. MSG structure contains
time member. The idea was to compare MSG.time with GetTickCount().
This solution has the same problem. DialogBox creates its own message
loop, over I have no control. After the messages are dispatched,
MSG.time is no more available at window functions.

The other idea is to use GetIdleTime(). Unfortunatelly this function
is not officially supported by Windows CE. I know the function is
there in coredll.dll, but I do not want to risk that my application
will not work on some devices.

Thanks in forward for any hint.
Vojtech

---
Mon Apr 28 06:44:20 CDT 2008

When you respond to a MM_WIM_DATA message, I assume that you are checking for
multiple buffers ready. If more than one buffer is ready by the time your
MM_WIM_DATA message processing gets control, you know you are falling behind.

Another method is to define a timer and repond to the WM_TIMER message. This
works for dialog boxes as well and regular windows. In that WM_TIMER message
you could check GetTickCount to see if you are falling behind.


Robert Scott
Ypsilanti, Michigan

bubnikv
Sat May 03 12:43:04 CDT 2008

Hi Robert.

> When you respond to a MM_WIM_DATA message, I assume that you are checking for
> multiple buffers ready. If more than one buffer is ready by the time your
> MM_WIM_DATA message processing gets control, you know you are falling behind.

Good idea. This will work, if I have control over the message loop,
but not when a dialog or menu is active.

> Another method is to define a timer and repond to the WM_TIMER message. This
> works for dialog boxes as well and regular windows. In that WM_TIMER message
> you could check GetTickCount to see if you are falling behind.

This is a good idea. At least it works now when a dialog is open. But
it seems the WM_TIMER is not dispatched when menu is active.

In my message loop I measure time since the last WM_TIMER message was
received. After I close menu, my message loop resumes, finds out that
the idle timer was not received for an extended time and an error is
displayed. I know there is a windows message sent after menu is
closed, but it is not implemented on my Pocket PC. Any other idea how
to solve the menu problem?

Thanks a lot,
Vojtech

---
Sat May 03 12:53:55 CDT 2008

On Sat, 3 May 2008 10:43:04 -0700 (PDT), bubnikv <bubnikv@seznam.cz> wrote:

>This is a good idea. At least it works now when a dialog is open. But
>it seems the WM_TIMER is not dispatched when menu is active.

Are you absolutely sure about that? It has been my experience that WM_TIMER is
dispatched to a dialog whether or not it has the focus.


Robert Scott
Ypsilanti, Michigan