How to check if a sound is playing before playing another?

[Tarnarmour]

I want to be able to play a sound continuously when a switch is activated. My first attempt at this was to just use the simple "play sound file VI" tool, placed inside a case structure to activate when the switch is pulled. However, this causes the sound to be played once each iteration of the loop, so very quickly the sound is basically a mash of hundreds of instances of the same sound overlapping.

There may be a much easier way to solve this, but what I tried to do was use the "Sound Output info VI" to check the task ID and see if it was playing. If it was, I'd just skip through the loop. If it wasn't, I'd start playing it. I know this is likely not the proper way to go about this, because from the start I had to ignore the errors that would happen when it tried to check an invalid task ID, but I thought if it worked I didn't really care.

However, something else is going wrong, and I'm not sure what. When the "play sound file VI" is activated for the first time it plays properly, and the sound info VI works to prevent overlapping plays. The next time the play sound file VI activates, however, LabVIEW freezes so thoroughly that I need to end the process to escape.

What's weirder is that when I debug it and step through slowly, it never has any errors. I actually stepped through past where it freezes in normal operation, then set it to finish the loop at normal speed, and still never saw any errors. When I went to run it normally again, labVIEW froze once more. I'm a bit baffled by that.

What is wrong with this, and more relevantly what is the right way to do something like this?

[altenbach]

Read the help on the timeout input of "Play Sound file".

[Tarnarmour]

I want the timeout to stay the default 0, I don't want to wait for the sound to finish playing. My goal is to have an alarm that can activate if conditions are met and stay on until turned off.

I need the VI to be able to check if the sound is finished yet so that it doesn't overlap the sounds, but it can't block the execution of the VI.

[altenbach]

Your sound file is probably quite short (else it the problem would also show in highlight execution mode).

If it is not short, maybe it is repetitive so one period might be sufficient, giving you finer control. How complicated can a beep.wav be???))

If you don't want to block the main loop, play the sound file in a parallel loop whenever a certain condition is met.

Can you attach your sound file?

[Tarnarmour]

I'm not able to attach .wav files to these messages, but it is quite short (about 0.75 seconds long).

When I tried the step by step debugging mode, I encountered no errors. When I told the debugging mode to step until it stepped out of the while loop (basically letting it run normally until the while loop finished) the problem went away. It is only when I start the VI normally that this problem occurs.

---

If you don't want to block the main loop, play the sound file in a parallel loop whenever a certain condition is met.

 I don't understand what you mean. How do I set up a parallel loop? Also, the main problem is not the sound blocking the loop (the play sound VI doesn't block the execution of code if timeout is set to 0), the problem is that an additional call to play the sound will be sent every time the loop executes, which causes the sounds to overlap.

[altenbach]

(You can attach anything if you place it inside a zip file.)

If the sound duration is 0.75s, the loop will spin at slightly more than 1Hz if you set timeout = -1 and it is guaranteed that only one play instance is running. Maybe that's fast enough.

(Yes, in single stepping or execution highlighting, the loop will take longer than the sound file duration, so you won't get any errors.)

You really should do a few basic tutorials.

[Tarnarmour]

I may need some help with the sound file VI's but I don't think this is a basic problem.

When I used execution highlighting to see if I could find the problem, I first stepped through slowly looking for which VI was having the error. When I didn't find any problems, I used the "run till end of while loop" step, which let the VI run at at least 30 Hz, and saw no errors. The VI was running at full speed, and didn't have any errors. When I then tried to run the VI normally, the error occurred again.

I understand what you mean by having a 0.75 second pause each iteration, however for the application I need to use this for I need at least 30 Hz and a delay of more than a few ms is too much.

In a previous post you mentioned running another loop in parallel, but what you are describing with the play sound file VI timeout set to -1 seems more like a loop in series with the main loop; it is not running alongside the main loop but inside the loop.

[Tarnarmour]

The sound file in question

[Tarnarmour]

I have found a solution, though I am sure there is a neater way to do this (and I'd love any corrections or advice still!). Basically, I have a variable in a shift register that tracks if the sound has been played at least once in the past. If it hasn't, and if the switch is active, then the sound is played and I store the task ID in a shift register. If the sound has been played at least once I first check the now valid task ID to see if the sound has finished playing. If it has, I play it again and update the task ID. If it hasn't, I pass the existing task ID along. Then an event case takes care of stopping the sound when the switch is flipped off.

In retrospect this doesn't seem too difficult, though I still have no idea what was causing the VI to freeze so completely before. Thanks for the help!

[altenbach]

Wow, you are way overcomplicating things. You don't need an event structure and Aztec (or Mayan) pyramids of case structures.