#110 ReZound stops responding while paused and shuttling

[comex]

Sometimes, when a file is paused, and I hold down
the '1' or '3' keys (shuttle), ReZound's GUI will
completely stop responding. However, the file, at
the shuttled speed, will continue to play
indefinitely (regardless of whether I let go of the
key or not). Commenting out this line from
CSoundPlayerChannel.cpp appears to keep it from
happening: (line 478)

if(paused && seekSpeed!=1.0 && origSeekSpeed==1.0)
{
// CMutexLocker
l(prebufferThread.waitForPlayMutex);
prebufferThread.waitForPlay.signal();
}

[Simon]

Logged In: YES
user_id=962
Originator: NO

I have the same problem whether I use the keyboard or the mouse. I've tried with the patch commex suggested, without effects.

Here's the exact symptom and how to reproduce:

1) Open a sound file
2) Press play
3) While the sound is playing, play with the speed jog wheel (mouse or keyboard)
4) After a dozen of jog play, rezound interface will stop to respond. Also, if you use the mouse, the mouse click will be unavailable in this workspace, but if you change the active workspace (with the keyboard), you can use your mouse buttons again. Going back to the rezound workspace and the mouse buttons don't respond.
5) After some time (which at least depend on the input event queue), the interface respond again.

You can obtain the same results if you play with the loop begin/end points while loop-playing. The loop then go on and will play with sometimes what can seem arbitrary begin/end loop points.

Tested with rezound 0.12.2beta and 0.12.3beta, on Ubuntu 6.10 i386 and amd64.

[Gundolf Kiefer]

Logged In: YES
user_id=316858
Originator: NO

I took a look at the code and tried to figure out what is going wrong.

Obviously, the problem is related to the invocation of 'prebufferChunk()' in 'CSoundPlayerChannel::setSeekSpeed()'. It performs various blocking 'TMemoryPipe::write ()' operations. The write accesses to memory pipes are mutally exclusive, so that parallel invocations of 'prebufferChunk()' from different threads exclude/block each other. Hence, the UI thread can be blocked out by the prebuffer thread ('CSoundPlayerChannel::CPrebufferThread'), which also continuously invokes 'prebufferChunk()' in parallel. Probably, this is a classical starvation problem, maybe there is another issue also related to parallel invocations of 'prebufferChunk()'.

My patch removes all dangerous 'prebufferChunk()' calls from the UI thread, so that parallel invocations are avoided. According to my understanding, they are not really necessary anyway, since the buffers are quickly (= immediately, if no other CPU-consuming tasks are running in parallel) filled by the prebuffer thread anyway.

Patch:
http://sourceforge.net/tracker/index.php?func=detail&aid=1896573&group_id=5056&atid=305056

[zinger919]

All hail gundolfk! I was having the same problem described here & was about to pull my hair out. Applied gundolfk's patch & joy has returned! For me, problem was most evident when using "play selection once" & left mouse to jump to various points in a file. Seemed worse on a) larger files b) amd64x2 system. I wish the developers & pkg maintainers would look into this patch. I was about ready to rip & replace hardware or just give up on rezound altogether. No ill effects from patch that I can discern.

[Olivier HUMBERT]

Maybe this patch have been applied to trunk. I'm unable to reproduce the problem here (Debian Jessie).