Hi

My application has many automatic features because it is designed to
run without any user interfering.
In fact, my app will work on a system without a keyboard or a mouse.
Anyway, from time to time, the app will perform some tasks. When
running certain critical tasks I need to play some speaker sounds while
they are processing. The sound should be a sequence of beeps. Just a
single beep could be anoying for the human listener.
On the other hand, the tasks will be performed on a random basis and
will take an impossible to determine period of time.
Should I use threads to play these sounds? I so, I fall in another
problem. What if 2 or more tasks will be started at the same time? Is
API's Beep() function thread safe?
It's a problem of design, too.

Any ideea will be appreciated
Thanks.

adi wrote:
> Should I use threads to play these sounds? I so, I fall in another
> problem. What if 2 or more tasks will be started at the same time? Is
> API's Beep() function thread safe?
> It's a problem of design, too.

Make one thread that handles the various beep sequences. This thread takes
the beep commands from a *protected* queue. The other threads send their
beep commands to this queue.

- Beep sequences will not interrupt each other.
- It is easy to make a pause between them - just add a silent period after
each sequence
- Since the queue is protected, two or more tasks will never "tread on each
others' toes", the one that comes last will just have to wait a bit until
the first one has finished adding its beep command to the queue.
- Once a beep command has been queued, the task thread can go on doing its
work.

Ebbe

Hi,


"adi" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi
>
> The sound should be a sequence of beeps.

You can use the Beep function fron the win API

>Just a
> single beep could be anoying for the human listener.

So, you want to annoy somebody?

> On the other hand, the tasks will be performed on a random basis and
> will take an impossible to determine period of time.
> Should I use threads to play these sounds? I so, I fall in another
> problem. What if 2 or more tasks will be started at the same time? Is
> API's Beep() function thread safe?
Yes it should be


btw, is your app running as a win service?

Hi Ignacio

No, I don't want to annoy anybody, that's why I poited out I need to
play a *sequence of beeps* rather than simply playing a *single beep*
while the tasks are running
That's why I think I should use a separate thread to play the
sequences.
I aggree with Ebbe. I should implement a queue of beep commands. The
only thing is that if several tasks produce such commands in the same
time, the human listener will hear a scrambled sound, something like a
noise, wich also may be annoying.
One solution could be to grant acces to this queue only to one task at
a time. This is fine with me. Anyway, if somebody has another solution,
that it is welcome.

No, my app will not work as a windows service. It's a "simple" win app.

Thanks.



Ignacio Machin ( .NET/ C# MVP ) a scris:
> Hi,
>
>
> "adi" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > Hi
> >
> > The sound should be a sequence of beeps.
>
> You can use the Beep function fron the win API
>
> >Just a
> > single beep could be anoying for the human listener.
>
> So, you want to annoy somebody?
>
> > On the other hand, the tasks will be performed on a random basis and
> > will take an impossible to determine period of time.
> > Should I use threads to play these sounds? I so, I fall in another
> > problem. What if 2 or more tasks will be started at the same time? Is
> > API's Beep() function thread safe?
> Yes it should be
>
>
> btw, is your app running as a win service?

adi wrote:
> I aggree with Ebbe. I should implement a queue of beep commands. The
> only thing is that if several tasks produce such commands in the same
> time, the human listener will hear a scrambled sound, something like a
> noise, wich also may be annoying.

Not necessarily.

Let the beeper thread be the place where the beep sequences are defined. The
threads that need to signal the user enter a simple code in the queue that
tells the beeper thread which sequence to play (i.e. 1 = bip beeep bip, 2 =
beeep beeep etc.).
Thus a beep command in the queue will not be played until the beeper thread
takes out of the queue. And that will not happen before it has finished
playing the previous one. Also, since the beeper thread is in full control,
it can also add a pause between beep sequences.

Ebbe