Hello! I'm using GCompris 0.97 based on Qt 5.12.8 on Ubuntu 20.04 LTS. Since after playing a while my nephew started to find narration voice annoying I disabled it by unchecking "Enable audio voices" in configuration. And as expected it didn't make any difference as the activities have text on the screen or a textual help menu (`?` icon). And this is expected as narration voice isn't/shouldn't be essential for the activity. But I found following 4 activities to be rendered completely unplayable with narration voices set to off: 1. Explore Farm Animals 2. Explore World Music 3. Audio memory game 4. Audio memory game against Tux I think this happens because the narration voice and the essential game voice for these 4 activities both are covered under single setting "Enable audio voices". (The voices from other activities also fall under the same setting but they aren't essential to play those activities thanks to the text on the screen and the respective help texts `?`) Please separate the narration voice from essential game voices so that the activities/games can be enjoyed without having to listen the constant narration voice. Thanks!
This is a bit tricky from our code architecture to do such separation... Another possibility would be to show a warning pop-up when starting those activities if the audio voices are disabled, telling the user he needs to enable audio voices for this activity. I'm marking this as "wishlist" as it's not technically a bug.
I found a way to force the audio voices in those activities that require it independently from the config. A little side effect is that voices for the bonus ("Good", "Check answer", ...) are always enabled for those 4 activities and the musical activities. But at least the intro voices are not played.
(In reply to animtim from comment #2) > I found a way to force the audio voices in those activities that require it > independently from the config. > > A little side effect is that voices for the bonus ("Good", "Check answer", > ...) are always enabled for those 4 activities and the musical activities. > But at least the intro voices are not played. Thank you!
Hi! Pardon me for commenting earlier without testing thoroughly. With this fix current situation is this: We disable audio voices ("Enable audio voices" setting), audio effects ("Enable audio effects" setting) and background music ("Enable background music" setting). Furthermore, we also set audio effects volume and background music volume to 0 thereby making sure that no sound is generated by the application. (Maybe because we're at the library or something) But now if we open any one of the above listed 4 activities we hear various voices from the speaker which is completely against the expectation. IMHO, the fix could be: Step a. Separate the narration voice from audio voices. Step b. Add new config option "Enable narration voice". And thus one can selectively disable narration voice (which gets annoying after a while) while keeping various audio voices from the activities enabled at the same time. This will also enable user to completely mute the application when all (narration voice, audio voice, audio effects and background music) are disabled. Step c. When audio voices is disabled ("Enable audio voices" setting) show "Enable audio voices to play" text for these 4 activities as they are unplayable without the audio voices (but like all other activities playable without the narration voice and hence the separation). Thanks!
Like I said before, your suggestion to separate "narration" audio voices from "necessary" audio voices is a little problematic. The reason is that to do this, we would need to add an extra audio player component to the whole application, which is not very good as it would make the application again heavier, just for a few activities.
Maybe the option of disabling the related level in explore games + showing a warning for all the activities if voices are disabled to tell that explore games will be degraded (one less level) and the memory ones are not playable without sound is a better solution then? Because, we can't really mute all sounds in configuration and still have sounds in the application... For sure, we can't also convert them to wav format, as they are already doing 1.2Mo for memory games...
(In reply to Jazeix Johnny from comment #6) > Maybe the option of disabling the related level in explore games + showing a > warning for all the activities if voices are disabled to tell that explore > games will be degraded (one less level) and the memory ones are not playable > without sound is a better solution then? Well for explore_music, it will also be totally not playable, it's only for explore_farm where we can bypass the "sound" level
Also, note that musical activities will always produce sound anyway, so in any case the only way to really have no sound at all from any activity is to mute the sound of the device.
> the only way to really have no sound at all from any activity is to mute the sound of the device. I'm sorry but imagine vlc generating sound even after muting vlc (press <key>m</key>) and then asking user to mute the device speaker as the only way to have no sound at all from vlc...
I don't remember the discussion that led to activating the sounds effects for musical activities when it's muted so I don't remember the pros/cons. Here was the commit: https://invent.kde.org/education/gcompris/-/commit/32e135c1d9988e21005c3d8683efe22f34b883fc (and the differential: https://phabricator.kde.org/D12862) but I don't find any discussion on the mailing list Would having a dialog for the musical activities when the effects are muted would be a solution asking for the user to unmute else it won't work?
> Would having a dialog for the musical activities when the effects are muted would be a solution asking for the user to unmute else it won't work? Yes, we should honor user choices (which are conveyed through configuration settings) wherever possible. If an activity is unplayable with the current configuration settings set by user then instead of directly changing or bypassing the settings i.e. user choices we should instead display the dialogue asking that specific necessary setting to be enabled/disabled. In fact, such a dialogue can offer the option to directly change that specific configuration setting right then and there itself instead of user has to close that dialogue then exiting the activity then opening the configuration window and then finally changing that necessary setting. But if the user doesn't make that required change by let's say clicking "cancel" on that dialogue then let's not exit that activity abruptly but let the user explore with degraded experience (by their choice of not enabling that necessary setting). Not letting user proceed sounds restrictive.
Your example comparing with VLC is very different, but ok, I see your point. I thought that bypassing the audio-voices configuration would be actually more user-friendly, as then users with audio-voices disabled can still use the activities that require audio without having to re-enable it, and then re-disable it after... I'm still not sure of what is best. Another option, would be to keep the config-bypass on activities that require audio, but then if the corresponding audio config is disabled, show a message at the beginning of the activity saying that this activity requires audio, and so it will play audio even if it is disabled in config... Then user has the choice to quit the activity or use it. Side-note: if we are to actually disable all audio from the configuration, then we also need to link the volume of the synthesizer used in piano and rhythm activities to the audio effects setting.
So I'm summarizing this issue for future reference. From a user's perspective: 1. All the activities should be playable with narration voices disabled. Activity help text (? icon) and text on screen while playing activity should be enough to get rid of narration voices. This demands a separate config option "Enable narration voices" in gcompris configuration. 2. When all the audio configs in gcompris configuration are disabled the application should produce no sound. Corollary, application should produce only the specific sound enabled by the respective specific audio config(s). Currently, gcompris produces sounds for above 4 activities + piano + rhythm etc. even when all the audio configs are disabled. 3. When an audio setting $foo is *essential* (must have) for an activity but is disabled in gcompris configuration, a dialogue asking $foo to be enabled should be displayed on clicking that activity. A sample dialogue here: https://i.ibb.co/QQ01wvm/IMG-20200725-213204.jpg 4. If the user chooses to not enable that essential conf (e.g. by clicking "Cancel" or by "Saving" disabled state) then the activity should exit. These are my personal views as a user. Please feel free to change/update/tweak them. Thanks!
Thanks for your feedback. Though, I still think it's more user-friendly to not ask the user to change the configuration just for a few activities, especially as then he would have to change it again... So, for me the best/most user-friendly solution is to keep always have the audio for the activities that require it, and just if the corresponding audio is disabled in the config, show a pop-up when starting the activity saying: "This activity requires audio effects/voices to be used, so it will play some sounds even if audio effects/voices are disabled in the configuration". I'll make sure to have this done before next release.
> just if the corresponding audio is disabled in the config, show a pop-up when starting the activity saying: "This activity requires audio effects/voices to be used, so it will play some sounds even if audio effects/voices are disabled in the configuration". I like this suggestion but please make this pop-up offer a choice to proceed or not. May be by appending the text "Proceed? Yes No". My use-case is user who has disabled all the audio configs as she is using gcompris in a silence-demanding environment (e.g. library, study room etc). If above suggested pop-up offers a choice then the user can safely click "No" if she indeed don't want any sound from gcompris or can press "Yes" and continue if she really wants to play that activity and the sound is not an issue.
OK, adding such buttons in the popup sounds good, I'll do like that.
Dialog added in all activities that require sound, with buttons to Quit the activity or Continue. Closing as fixed.