Inaccurate beep generation algorithm causes lags on netbooks

[nvaccessAuto]

Reported by aleksey_s on 2009-08-21 15:06
Tried on intel atom 1.6 ghz.

[nvaccessAuto]

Comment 1 by aleksey_s on 2009-08-21 15:08
I was really surprised by time measurements i made after receiving this report.
Proposed implementation see in bzr branch: http://bzr.nvaccess.org/nvda/tonesRewrite

[nvaccessAuto]

Comment 2 by jteh on 2009-08-22 02:04
To clarify, does this actually fix the problem on said Netbooks or do you suspect that it fixes the problem?

We've considered moving the tone generation stuff into another thread. This would allow for smoother movement between tones when many tones occur in close succession.

Btw, for your interest, I suspect the reason the Python code is so slow is that it keeps appending to a string. Strings are immutable, which means that the whole string is probably regenerated each time we add a byte. If we were using Python 3, we'd use a bytes array, which is mutable and therefore probably much faster when appending a single byte at a time. It may be faster to use a list rather than a string in Python 2 and then join it at the end of the loop.

[nvaccessAuto]

Comment 3 by aleksey_s (in reply to comment 2) on 2009-08-22 04:15
Replying to jteh:

To clarify, does this actually fix the problem on said Netbooks or do you suspect that it fixes the problem?

Yes, tested on my girlfriend's Aspire One.

We've considered moving the tone generation stuff into another thread. This would allow for smoother movement between tones when many tones occur in close succession.

Do you mean new thread for each beep or one thread for all? Anyway, current implementation can generate as many beeps at a time asw you want without any lag. :) And as far as i know we already are playing audio in another thread.

Btw, for your interest, I suspect the reason the Python code is so slow is that it keeps appending to a string. Strings are immutable, which means that the whole string is probably regenerated each time we add a byte. If we were using Python 3, we'd use a bytes array, which is mutable and therefore probably much faster when appending a single byte at a time. It may be faster to use a list rather than a string in Python 2 and then join it at the end of the loop.

I suspect native code will be faster here anyway. Of course i am not about accuration for accuration, here i saw really lags and made time measurements. Well, since, we aren't on python 3 i believe a couple linesof c++ code will do the job.

[nvaccessAuto]

Comment 4 by aleksey_s on 2009-10-02 17:55
Any chances this will be included in main?

[nvaccessAuto]

Comment 5 by jteh on 2009-10-02 23:09
Mick, tested this just now and it works fine for me. No l10n impact. Are you happy to include in 2009.1 given the performance improvement on netbooks?
Changes:
Milestone changed from None to 2009.1

[nvaccessAuto]

Comment 6 by mdcurran on 2009-10-02 23:51
I am certainly happy for this to go in to main.
While I was reviewing I did commit a small optimization to the generateBeep function, which I had been meaning to do in tones.py for a while anyway. That is to calculate some of the sine frequency stuff outside the for loop, as the only real variable there is the position with in the sine wave.

I do have another question about coding, which is more probably a lack of understanding on my part:
Why is it that for all your unsigned int constants you don't actually declare them as int? e.g.
const unsigned sampleRate=44100;

Is there a rule in c++ that states these are automatically int?

However, the code works and is understandable, so I'm happy if it goes in to main.

[nvaccessAuto]

Comment 7 by jteh on 2009-10-03 00:51
Merged in r3305. Thanks for your work.
Changes:
State: closed