On Wed, 7 Oct 2015, Dave Mielke wrote: > [quoted lines by Nicolas Pitre on 2015/10/06 at 19:42 -0400] > > >With those few patches I sent you separately to improve PCM code > >efficiency, the above test case is now more difficult to trigger. So > >those patches don't completely fix it but they apparently help. > > Please give the tune-thread branch a try. It needs more work, but it should > work well enough to test the problem.
Yes, problem entirely gone while using that branch. Good work! And that is with the original PCM generator code in place. I also forced every note to be 500ms long to exacerbate the issue to be sure. With this hack it was easy to bring brltty in a loop where the bounce tune took all the CPU's attention which prevented it from seeing the release key event and therefore auto-repeat kicked in which generated yet more bounce tunes. With the threaded tune this doesn't happen anymore. Another nicety: the braille cursor does not stop blinking while a tune is playing. BTW, I instrumented the code to see the effect of those PCM efficiency patches I sent you. Generating 100000000 samples and discarding them from within writePcmData() takes 14 seconds on my PC. Doing the same with my 2 patches applied brings that down to 9 seconds. I suspect the relative difference would be even bigger on portable devices. Nicolas _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://mielke.cc/mailman/listinfo/brltty
