pgSoundLoader

[John Robin Dove]

Hi Clifton,
I have a new problem that I can’t seem to solve. I use pgSoundLoader to play recordings in two different contexts. 1) While the recording is playing, the words of a sentence are selected one by one and when all have been selected the next sentence is dealt with in the same way. 2) The same technique is used by for one sentence only which is displayed on a smaller field on page 2 in an iframe to allow the user to make changes to pause times after words have been selected (the times are stored in a 2 dimensional array).

I would have thought that context 1 would be the more challenging but surprisingly I can repeat this over and over again and there are never any problems.

If, however, I use pgSoundLoader in context 2 and then go back to context 1, the performance is affected and the file takes longer to play, sometimes slightly longer, sometimes considerably longer. This is catastrophic for my system which is based of the duration of the mp3 file.

What causes the deterioration in the performance? I have tried several things. I always unload the file before loading the next one and I use reload like this:

Code: Select all

tbfunction_pgSoundControl("reader", "unload");
        tbfunction_pgSoundLoader( "/programs/" + sharedActions.currentFolder + "/" + sharedActions.currentPage + "-" + sharedActions.ctr + ".mp3", "reader", "", "reload");     
        tbfunction_pgTimer(true, 100, "button_read") //timer in button_read gets duration

I have also tried using two different objects, one for each context but this does not solve the problem either. I wonder if the system for getting the duration could be the cause:

Code: Select all

<function name="myUser" event="user" params="evt,value" useTB="true">
  <![CDATA[
  let ready = tbfunction_pgSoundControl("reader", "duration");
    if (ready)
    {
    tbfunction_pgTimer("", "", "button_read", true);
    ready = Math.floor(ready);
    sharedActions.length = ready;
    }
  ]]>
  </function>
  </button_read>

I also wonder if using htmlVideoLoader for one context and pgSoundLoader for the other might help. Do you have any suggestions, please?
John

[Clifton]

I would try NOT using "unload" in this circumstance. Instead, use "stopAll" first if necessary and then just play the next file. "Unload" and "destroy" followed by reload does a lot more work than is necessary in this case.

If the above doesn't work, then you will need to debug what is happening.

1. (MOST LIKELY PROBLEM)
   This is a bad implementation of a periodic timer. If the browser delays even for a moment, the periodic timer will keep firing and gobble up CPU cycles. Instead, use a single timer, and restart it ONLY if your condition is not met. That should prevent multiple timers from firing on the user event and freezing the system. What is even worse is if multiple timers fire and you stop the timer while other notifications are firing, the rest of the notifications will still occur (and there could be hundreds of them), thus causing all sorts of lags and other anomalies. Generally, steer clear of periodic timers unless they are longer than 500ms (1000ms is even better). Short timers like you are using are best handled in their single state.
2. (Another possibility)
   I suspect your timer is looping at 100ms and causing the lag issue becaue the condition you are looking for cannot be met in some or most situations. You might have to check for "status" before "duration" because at 100ms you are trying to query a media file that the browser is still loading and maybe it is waiting for the duration to become available before releasing control back to the script. Generally, a media file must be loaded and buffered enough before the "duration" property becomes available. You may need to account for this in your script.
3. (Another suggestion)
   You might try removing the 100ms timer and see if you can get your system to work in both conditions. If it works in both conditions, then looking at the timer method is likely the culprit. Perhaps try a larger timeout value like 250ms and see what that does.
4. (Another recommendation)
   If you must use a 100ms timer, then consider also checking for the "audio end" user event value as the trigger to reload the next audio.

Basically, I think what is happening is the timer is firing and the script cannot verify a satisfying condition to exit the loop and load another file.
 

[John Robin Dove]

Thank you very much for your advice Clifton. I now have a system that seems to ensure that the performance of the soundLoader remains constant, although I can't quite believe that yet. After weeks battling with this problem I half expect it to come back again. I think it was caused by a combination of the factors you identified but particularly the use of the periodic timer. In fact this was unnecessary. I am now using a fixed timer of 500 ms. This fits into the system quite well because when you make a sound recording there is often a delay of about 500 ms before it starts anyway. I had made a system to compensate for this and shall adjust this accordingly. I don't think there are many more problems to solve now so I hope that the project may be finished in a month or two.