GNOME Bugzilla – Bug 419123
Modified speech settings do not change immediately in preferences dialog
Last modified: 2009-03-10 14:25:36 UTC
From private e-mail to me: "In the preferences dialog speech-tab the changes to rate and pitch were not spoken. So you need to make your changes without any feedback. The changes to the rate and pitch vallues were changed after pressing ok or apply. I noticed this a few days ago. A few months ago this worked fine."
*** Bug 562307 has been marked as a duplicate of this bug. ***
stack.push(419123) .. or should it be list.append(419123) :) please assign to me.
Created attachment 127734 [details] [review] rev 1 I couldnt get my head quite around the localization+speech rate/pitch things, so here is a small patch that changes the pitch/rate/volume while the orca prefs window is open. We change rate/pitch/vol for the default voice, even if the user is changing the upper case voice, this is so that they can hear the right pitch/rate/volume. As soon as they press apply/ok/cancel we save their settings, and the default voice is returned to its requested settings. Note now we reload user settings on cancel button as well, to ensure that the user playing around in the gui has not done anything with the rate/pitches. Will, is this reasonable? Thank you
Created attachment 127735 [details] [review] rev 1 Looked at this today, I couldnt get my head quite around the localization+speech rate/pitch things, so here is a small patch that changes the pitch/rate/volume while the orca prefs window is open. We change rate/pitch/vol for the default voice, even if the user is changing the upper case voice, this is so that they can hear the right pitch/rate/volume. As soon as they press apply/ok/cancel we save their settings, and the default voice is returned to its requested settings. Note now we reload user settings on cancel button as well, to ensure that the user playing around in the gui has not done anything with the rate/pitches. Will, is this reasonable? Thank you
sorry for the duplicated posts, bugzilla timed out and gave a 500 error, so hit refresh.
Jon, I will be looking the patch tomorrow. Attila
Created attachment 127814 [details] [review] rev 2 This removes the need of reloading the user settings on pressing cancel. Thanks Atilla for your testing!
Jon, I applyed morning the last patch. When I tryed opening Orca preferences Window, the preferences window is not displayed. Now I looking this patch with my Debian system and latest Orca version. Your machine works correct the patch? If yes, I looking tomorrow the last patch with fresh installed Jaunty system. Attila
Created attachment 127850 [details] [review] Patch to do a deep copy and restore In testing, I found two problems: 1) There was an assumption that the gain, pitch, and rate values were in the settings. This isn't always the case and can cause a stacktrace that prevents the preferences UI from appearing. The attached patch just does a deep copy/restore on the voices dictionary, setting things back to the way they were when the user hits cancel. 2) If I change a voice other than the default voice (e.g., the uppercase voice), those impact the default voice as well. :-( The attached patch doesn't address this problem.
Tested the last patch. found some problems, I using 2.0 and 0.0 pitch: 1. The speech rate when trying change, lot of different with final reloaded rate. For example: When trying change speech rate with 70, the speech is faster with real 70 rate (final reload). 2. If not changing pitch only the rate, the pitch slider shows 5.0 value. 3. If not changing the pitch and rate, the pitch slider showing 5.0 value (Espeak spokening this value), but I using 0.0 pitch with realy. Interesting, but for example if I setting pitch to 9.0, this problem is not present after the preferences is reloaded. Attila
Created attachment 127869 [details] [review] rev 4, solves the bug that Will found. (In reply to comment #10) > Tested the last patch. > found some problems, I using 2.0 and 0.0 pitch: > 1. The speech rate when trying change, lot of different with final reloaded > rate. For example: > When trying change speech rate with 70, the speech is faster with real 70 rate > (final reload). Atilla, are you using gnome-speech? I am using alsa and speech-dispatcher, and I am not seeing this. Unfortunately i can not use gnome-speech (easely), so cant test at the moment. Is the diffrance in the rate very large? > 2. If not changing pitch only the rate, the pitch slider shows 5.0 value. Yes, i believe that is the default pitch value? .. or did i not understand the problem. > 3. If not changing the pitch and rate, the pitch slider showing 5.0 value > (Espeak spokening this value), but I using 0.0 pitch with realy. > Interesting, but for example if I setting pitch to 9.0, this problem is not > present after the preferences is reloaded. Sorry i do not understand. > Attila The attach patch also solves the bug that Will describes. Thanks Will :) Thanks. P.S. Thanks again to Will, you should not have any problems with the lost focus.
I looked the last patch my Debian Lenny system. The speech rate setting works fine, I tested with gnome-speech. Jon, possible doing no set the patch the pitch slider with 5.0 value automaticaly, if possible keep the prewious setted pitch with pitch slider value? Now this method owerwrite the prewious pitch setting (now my machine is 2.0). If I not back change the slider value with 2.0, my Orca setted up 5.0 pitch when final reload the settings. Interestin, but speech sinthesis pitch not changing 5.0 when I tabbing the pitch slider, speeching my originaly 2.0 value. When I press left or right arrow, the pitch is correct changed, but increasing or decreasing 5.0 value. Attila
Hi Atilla: I still can not reproduce what you are experiencing (probably because i dont quite understand). I did the following: 1. before patch, changed pitch from 5.0 to 2.0, pressed ok button 2. opened up preferences again, varified pitch slider displays 2.0. closed preferences. 3. applied the patch. 4. opened preferences, pitch slider says 2.0 (correct) 5. changing pitch slider, i can hear the pitch change as the slider changes. 6. If i press cancel, the pitch is set back to my setting (2.0). 7. instead of pressing cancel, i press ok or apply, the pitch gets saved to the new value. Please give me step by step (with numbers) on what to do, so hopefully i can reproduce the problem). Also, can you see your problem without this patch? Mike, since you are running gnome-speech, could you please have a little test of this? Thank you.
I'm finding a couple issues with this patch. My configuration is open Solaris, gnome-speech and espeak. 1. for both rate and pitch the home and end keys make a noticable difference but when using the arrow keys no change is heard other than when going from 4.6 to 4.7 in the pitch and from 45 to 46 in the rate. 2. When I pressed cancel my settings remained at the new values instead of reverting to the settings I had prior to opening the orca prefs. I did not get my correct settings back until I reloaded orca.
Hello! Before applying the patch, I doing: 1. Press Capslock+Space (I using laptop layout my notebook). 2. Press right arrow, navigate with speech page. 3. Press 7 tab key (you see the pitch slider). The correct value is spoken with espeak (2.0 the right value my system because setted up already). This is the right. When applying the patch: 1. Press Capslock+Space. 2. Press right arrow, navigate the speech page. 3. Press 7 tab key, you see the pitch slider. Espeak says 5.0 value (this is not right because the pitch already setted up 2.0 my system). Next comment I attaching full debug.out file. Attila
Created attachment 128018 [details] This is full debug.out. I setted up the language for english, and tfour tryed the prewious comment steps. The last trying Orca produce the problem (5.0 pitch spokening with Espeak). Previous I setted pitch to 0.0 value, after producing Orca the problem. I hope help this debug.out. Attila
Created attachment 128115 [details] [review] rev 5. (In reply to comment #9) > 1) There was an assumption that the gain, pitch, and rate values were in the > settings. This isn't always the case and can cause a stacktrace that prevents > the preferences UI from appearing. The attached patch just does a deep > copy/restore on the voices dictionary, setting things back to the way they were > when the user hits cancel. Sorry, the deepcopy doesnt seem to do the trick for me, it doesnt seem to be that deep. > 2) If I change a voice other than the default voice (e.g., the uppercase > voice), those impact the default voice as well. :-( The attached patch > doesn't address this problem. Fixed. (In reply to comment #14) > I'm finding a couple issues with this patch. My configuration is open Solaris, > gnome-speech and espeak. > 1. for both rate and pitch the home and end keys make a noticable difference > but when using the arrow keys no change is heard other than when going from 4.6 > to 4.7 in the pitch and from 45 to 46 in the rate. I believe what you are describing is due to the way we are converting from general values, to gnome-speech rates, (gnomespeechfactory.py is not even touched in this patch). Gnome-speech with speech-dispatcher output behaves as you describe, wheras directly talking to speech-dispatcher we are observing a linear scale. So its actually a diffrent bug, just that we are seeing it now. (In reply to comment #15) Sorry Attila, I don't know what is going on. Can you try the patch on ubuntu or opensolaris? The patch always restores the slider values from the settings. Will, could you please have a look at Attilas debug file? pylinted to 10.00
Jon, when I attached the debug.out file, I forgotted say I tryed the revision 4 patch with Ubuntu Jaunty. Now, looking the last patch, and writing comment. Attila
I tryed the last patch with Jaunty. My problem is present (pitch slider showing 5.0 default value not the right setted up value). Interesting, the slider shows 5.0 value, but Espeak speak the right 0.0 value. Next two comment, I sending thwo screen picture with speech page. First picture the hungarian speech page (the hangmagasság part of interesting), the second picture is the english screen picture witth speech page. Attila
Created attachment 128155 [details] This is the hungarian speech picture for speech page. This is the hungarian speech page picture. I not changing any value, only navigating the speech page the right arrow key, and pressing one tab. The hangmagasság (pitch) slider showing 5.0 value, not 0.0 (prewious setted up value with wednesday.
Created attachment 128156 [details] This is the english picture for speech page. I not changing any value, only press one right arrow (navigating with speech page with Orca preferences), and press one tab. The pitch slider showing 5.0 value, not the wednesday setted up 0.0 value.
(In reply to comment #21) > I not changing any value, only press one right arrow (navigating with speech > page with Orca preferences), and press one tab. The pitch slider showing 5.0 > value, not the wednesday setted up 0.0 value. I think the issue being seen here revolves around the value 0.0. In orca_gui_prefs.py:_setVoiceSettingsForVoiceType, there are these lines: rate = self._getRateForVoiceType(voiceType) if rate: self.get_widget("rateScale").set_value(rate) pitch = self._getPitchForVoiceType(voiceType) if pitch: self.get_widget("pitchScale").set_value(pitch) volume = self._getVolumeForVoiceType(voiceType) if volume: self.get_widget("volumeScale").set_value(volume) Changing the if's to use "!= None" ends up resolving the problem. I've got one more thing to chase down, which is that pressing the Escape key instead of the Cancel button does not reset the voice parameters.
Will, thank you for pointing that one out, will get it (the escape button thing)
Created attachment 128328 [details] [review] Patch This patch builds upon the previous patch to: 1) Put each rate/pitch/volume assignment in a separate try/except block. With them in a single block, the absence of any key would cause all keys to be set to the default value. 2) Does the "!= None" thing to make sure 0.0 values work. 3) Adds support for closing the dialog via "Escape" It pylints to a 10.0 and seems to test pretty well.
Created attachment 128329 [details] [review] rev 6. fixes the escape button, and implements Wills suggestion for Attilas problem.
Wills patch is the one to use, rev 6 is obsoleet
Tryed the rew 5 patch with my Jaunty test system. My main problem is solved (the pitch slider shows right 0.0 value my machine), but: 1. When changing pitch values with arrow keys, the speech rate changing (the speech is more fast with 75.0, but the rate slider value is not changing). 2. I not hear differences with pitch values under 0.0 to 5.0 (1.0, 2.0, 3.0 etc). Try pressing down arrow key for example, the pitch changes when the slider get up 5.1 value. Home and end key works correct. 3. When I changing pitch value and after this I pressing esc key, Orca speaks more fast with 75.0 value, but I not changing rate. Only solving the problem when I rerun Orca. I using gnome-speech espeak driver and 1.39 version (original Jaunty release). Anybody confirm this problems? Attila
> I using gnome-speech espeak driver and 1.39 version (original Jaunty release). > Anybody confirm this problems? I think I see what the problem is -- the UI is telling gnomespeechfactory.py to create a new speaker for each change in value. This was OK in the world where we didn't do live updates, but is kind of expensive and error prone when we do. When asked to create a new speaker, gnomespeechfactory.py gets the min/current/max values and saves those away, with the belief that current=default. The problem is that current != default when we have already created a speaker and have changed it's value. I'll look into a fix....
Created attachment 128399 [details] [review] Rev. 7 This patch fixes the problem identified in the previous comment by only saving the min/current/max values the first time a particular GNOME-speech speaker is created.
(In reply to comment #29) > Created an attachment (id=128399) [edit] > Rev. 7 > > This patch fixes the problem identified in the previous comment by only saving > the min/current/max values the first time a particular GNOME-speech speaker is > created. Note also that the pitch problem that Attila was noticing was a bug in gnome-speech. The espeak driver was giving nonsensical values. See bug #571217.
Will I have one question before testing the last attached patch: I looking linked gnome-speech driver bug (bug 571217). Upgrade my gnome-speech driver with svn trunk? Pulseaudio not producing problems when compiling gnome-speech driver from source? Attila
(In reply to comment #31) > Will I have one question before testing the last attached patch: > I looking linked gnome-speech driver bug (bug > 571217). Upgrade my gnome-speech driver with svn trunk? > Pulseaudio not producing problems when compiling gnome-speech driver from > source? The gnome-speech driver bug fix will be mostly noticeable with the pitch range. In particular, it will allow the pitch difference to be more apparent when you go below 4.0 on the scale in Orca and will also give you finer granularity when you go over 5.0. I'm not sure about what will happen with PulseAudio. But, you might try taking a look at the output of 'file /usr/bin/espeak-synthesis-driver'. If it's a shell script, then Ubuntu has put a wrapper in place and probably puts the real binary in /usr/bin/espeak-synthesis-driver.bin. If that's the case, you might want to save the /usr/bin/espeak-synthesis-driver* files somewhere, build/install gnome-speech, mv the new /usr/bin/espeak-synthesis-driver to /usr/bin/espeak-synthesis-driver.bin and then copy the old /usr/bin/espeak-synthesis-driver shell script back in place.
How is this patch working for everyone? Given the reliance upon a fixed gnome-speech espeak driver, I don't feel good about it for gnome-2-24, but I would like to get it into GNOME 2.25.91 if people are OK with it.
Will, I looked the last patch and last gnome-speech trunk. Works fine with Jaunty, i see one problem: When press Esc key, Orca speak volume bigger with original speak volume. Anybody confirm this? I not changed volume value or any values. How can implement this patch with Orca 2.24.4 release? Because in Ubuntu the required components does'nt upgraded (gnome-orca is 2.24.1 for example). I have got a personal ppa repository, i always put the maintained versions (now I putted gnome-orca 2.24.3 release). I known, this is not right, but some hungarian Hardy user like this. Attila
Created attachment 128741 [details] [review] Rev 8 (In reply to comment #34) > Will, I looked the last patch and last gnome-speech trunk. > Works fine with Jaunty, i see one problem: > When press Esc key, Orca speak volume bigger with original speak volume. > Anybody confirm this? I not changed volume value or any values. Ah, yeah. The problem is that the default volume/gain level is 5.0, but the new GUI preferences code ends up making it 9.0 if it hasn't been set yet. So, the volume is jumping from 5.0 to 9.0. I propose that we fix the scales so they go from 0-10 and 0-100 (I never understood why we went 0-9 and 0-99), make the default pitch and rate be 5.0 and 50 and the default volume be 100. The attached patch does this. > How can implement this patch with Orca 2.24.4 release? With the issues that keep cropping up with this, I don't feel comfortable putting this in 2.24.4. But, we can shoot for 2.25.91. Will
Patch committed to 2.25.91. Many thanks to Jon for his work on this and for Hammer for testing. Much good teamwork all around. Closing.
Created attachment 128936 [details] [review] Patch to fix problem with not being able to set uppercase voice settings There was an additional problem reported on the Orca list: http://mail.gnome.org/archives/orca-list/2009-February/msg00268.html. This patch hopefully resolves it. This patch seems to fix the problem for me and I tested with it a bit. Committed to trunk so more people can test.
I will be looking new patch few hours. But yesterday after updated my system (libgnomespeec7 updated apt-get), I found an interesting problem, this problem is not present with revision 7 fix: 1. The pitch value drastical changed. If I would like using original 0.0 pitch value, I must set pitch to 4.0 value. 0.0 pitch value very low now. This is right? 2. Another Orca user sayd me Orca volume is very low (10.0 volume value), lower with old 9.0 value. Anybody comfirm this problems? Attila
This is my friend letter, he writing hungarian for me, so sorry the automatic translation (Babilon): "Hi! When I tryed the new gnome-speech, simply I saw him, that it has been much sank, as far as it was not Orca dialog also , I looked at only after your letter. Svn updated Orca from the changes do not operate with me, at least they went so far has not, it is now work correct, when reinstalled my Ubuntu Jaunty system. I also, I am glad that lower may be taken into account the voice , but do not like that sank was, like the old version. Thus it is now a music player max volume much sank, and even the speakup-espeakup joint volume is much something louder. Orca just as I can hear, so that the pleasant, while speakup talking, must turn down volume when using the howl of." So, i think he's problem only low Orca volume levels, but he like the new lower pitch values. I not see this problems with revision 7 fix, only see this problem with last patch (looked yesterday. I going looking the new fix with uppercase voices. Attila
(In reply to comment #38) > I will be looking new patch few hours. > But yesterday after updated my system (libgnomespeec7 updated apt-get), I found > an interesting problem, this problem is not present with revision 7 fix: > 1. The pitch value drastical changed. If I would like using original 0.0 pitch > value, I must set pitch to 4.0 value. 0.0 pitch value very low now. This is > right? This is right. The gnome-speech driver for eSpeak had an issue with not exposing the pitch range correctly. The new driver exposes is correctly. The result is that the voice can be even lower than before. > 2. Another Orca user sayd me Orca volume is very low (10.0 volume value), lower > with old 9.0 value. If the user resets the volume to 10.0 in the preferences dialog and saves their settings, does it work better?
Will, you wroted: "This is right. The gnome-speech driver for eSpeak had an issue with not exposing the pitch range correctly. The new driver exposes is correctly. The result is that the voice can be even lower than before." Ok, I agreed, thanks the pitch fix. I wroted e-mail my friend with your 10.0 volume suggestion. I using 10.0 value and don't see he's problem when I using Totem with Internet radio station for example. When he answer my letter, I paste he's answer. Attila
I looked 9.0 and 10.0 volume levels, and I not hear big differences. Will, what value setted up oldest Orca versions when the user setting up 9.0 value? I looked capital setting up with following steps, and found problems: 1. Pressed up Capslock+Space (laptop mode). 2. Navigating speech tab and search default person combo box. 3. Setted up capital or hiperlink (both are tested). When this happens, Orca shows the default person settings (my machine rate is 80.0, pitch is 3.0, volume is 10.0). 4. After this I changing the pitch for example 6.0, the pitch is changed. 5. Reload Orca settings with Ok button. Orca owerwrite my default person pitch setting to 6.0 (replaces 3.0 value). I think this is bug. When I setted up default person pitch to 3.0 again, the hiperlink or capital person pitch was changed to 3.0 (prewious we setted up 6.0 with capital person pitch for example). I using latest gnome-speech trunk version (updated this day), and latest Orca (updated this morning). Attila
(In reply to comment #42) > I looked 9.0 and 10.0 volume levels, and I not hear big differences. > Will, what value setted up oldest Orca versions when the user setting up 9.0 > value? In the older version, 9.0 was the maximum allowed, which is kind of a puzzling number since most people count to 10. The newer version goes to 10.0, but the net effect on the maximum volume *should* be the same. That is, the maximum is the maximum, regardless of what number you want to put on it. We could make a special Nigel Tufnel version that goes to 11.0, for example, but it really won't be 1 louder. > I looked capital setting up with following steps, and found problems: This sounds like what we've been discussing on the orca-list: http://mail.gnome.org/archives/orca-list/2009-February/msg00292.html
Will, now I read your last letter with Orca mailing list. After read your letter I tested up the problem functions (capital and hiperlink person settings) with english locale. All works succesfuly, this is good news for english persons, but not any other locale users. :-(:-( Prewious I tested up this function with hungarian locale, when I using hungarian locale, all problems are reproducable (see my prewious comment). Jose Vilmare Stacio have same problems? Possible solving any method this problem? For example in hungarian the default person value we translated "Alapértelmezett", the capital value translated "Nagybetűs", and the hiperlink value translated "Hiperlink". Attila
(In reply to comment #44) > After read your letter I tested up the problem functions (capital and hiperlink > person settings) with english locale. > All works succesfuly, this is good news for english persons, but not any other > locale users. :-(:-( Thanks for confirming. I'm looking at the problem now.
Created attachment 128981 [details] [review] Patch to reduce sensitivity to translations This patch reduces the sensitivity to the translations. Prior to this patch, the translated strings for "Default\nUppercase\nHyperlink" and "Default", "Uppercase", and "Hyperlink" had to match. In the event the translations were incomplete or did not match, the preference settings wouldn't always work. This patch modifies the preferences code to use the integer value instead of the string value for the combobox. Seems to work nicely and pylints, so I committed it to trunk.
Will, last trunk fix works perfect with hungarian and us english locales. Tested gnome-speech and Espeak. What your openion? must do anything my friend Orca volume problem? If not, I not found any problem with this bug. Attila
(In reply to comment #47) > Will, last trunk fix works perfect with hungarian and us english locales. > Tested gnome-speech and Espeak. Thanks! > What your openion? must do anything my friend Orca volume problem? > > If not, I not found any problem with this bug. I cannot seem to be able to reproduce or understand the volume issue described. If the volume problem is really an issue that has a repeatable test case that can be be clearly described, please open a separate bug. Thanks!