Strange issue with Sound Component with variable based duration

[frankgasking]

Testing on PsychoPy 3.1.0 Win 32 Py2.7 edition (Running on Windows 10, 64-bit)

I've found a very strange and critical bug with the Sound Component which has been introduced in the 3.1.0 release (as detailed above).

Basically, if you set the actual duration of the sound as an actual number, then everything works fine. But if you attempt to set the duration with a variable/python code, then it seems to not generate the "frameRemains" attribute and check against this to see if the sound should stop. It just checks against the duration, which means if the duration and start is the same, then it seems to start and stop the sound at the same time.

It's not noticeable if the sound starts from 0 seconds, as the calculation works fine and has enough time to play before stopping, but if you bump it up to 2 on the start time - then you'll notice it.

Attached is a demonstration - first part is with the variable and a 2 second starting point. Second part shows the same, but with the duration hard-coded.

AudioTest.zip

[peircej]

OK, digging around and this dates back to pull request #1710

Briefly, some code was added by @dvbridges to not force-stop sounds at very brief durations (I believe there was an issue with stopping sounds before they were started, or shorter than the hanning window?) but inserted a fix to check this duration at compile time not during the run. Then in #1858 this was fixed so that you could at least use a duration without an error (by excluding the stop command again at compile time.

The better solution is that we check the duration value at run time not compile time. I'll try and make that fix

[peircej]

Fixed in commit 825bfdb

[frankgasking]

Awesome, thanks Jon! Will keep an eye out for the next release.

[frankgasking]

Apologies Jon, unfortunately its still broken in release 3.1.1 Py2 Win32.

I realised my demo didn't start at 2 seconds, so attached is an updated copy
AudioTest.zip
. The sounds don't play on the first loop, only a bit of the first sound plays towards the end of the second trial.

If you compile the code, and compare "play_sound" (Line 302) to "playing_sound_two" (Line 499), you'll see the latter has the frameRemains calculation added in correctly, but it hasn't been for the first part.

[peircej]

Sorry Frank. My bad. I found the fix and applied it to the master branch but failed to copy it over to the release branch for 3.1.1

I have now included it for 3.1.2 which is currently building (and fixes some additional problems with the new Keyboard class). So should be there for you this afternoon.

[frankgasking]

No worries Jon - and thanks! I'll test out the build tomorrow and will let you know if there are any problems.