Inaccurate beep generation algorithm causes lags on netbooks #396
Comments
Comment 1 by aleksey_s on 2009-08-21 15:08 |
Comment 2 by jteh on 2009-08-22 02:04 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. |
Comment 3 by aleksey_s (in reply to comment 2) on 2009-08-22 04:15
Yes, tested on my girlfriend's Aspire One.
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.
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. |
Comment 4 by aleksey_s on 2009-10-02 17:55 |
Comment 5 by jteh on 2009-10-02 23:09 |
Comment 6 by mdcurran on 2009-10-02 23:51 I do have another question about coding, which is more probably a lack of understanding on my part: 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. |
Comment 7 by jteh on 2009-10-03 00:51 |
Reported by aleksey_s on 2009-08-21 15:06
Tried on intel atom 1.6 ghz.
The text was updated successfully, but these errors were encountered: