GNOME Bugzilla – Bug 140083
sound server must not grab non-shared audio from text-to-speech service
Last modified: 2018-05-22 12:53:03 UTC
This error occurs when using Festival with Gnopernicus on RH9: 1. Start gst-recorder 2. Record your voice 3. Select stop 4. Play recording and receive an error: OSS device "/dev/dsp" is already in use by another program. The error message is not spoken by gnopernicus and the user can not hit Esc to exit. Expected result: The recording to play or the error message to be spoken and the user directed on what to do next.
This isn't a bug. You're trying to play back an audio file when something else is already using the sound device. Use a sound daemon like esd if your card is not capable of hardware mixing and make sure gstreamer uses esd for output.
This is a bug if the error message isn't accessible or spoken by gnopernicus.
Bill, seriously, this isn't a bug. At least not in gnome-sound-recorder. It's a design bug with gnopernicus conflicting with the audio device's capabilities. User has a choice between a) not using sound applications if he wants to use gnopernicus b) get a soundcard that supports hardware mixing c) use esound d) get a second soundcard dedicated to gnopernicus.
Reopening bug. I understand your comments above. However the end result is not acceptable. It is essential that the speech engine take precedence over the sound application in this case - and we must do something to ensure that the sound application doesn't grab control of the audio device if it cannot be shared (if gnopernicus is already using it). Whether the fix (i.e. detection of this condition, and interception) needs to be in gnome-sound-recorder/gst, gnome-speech, or elsewhere, is not clear yet. But a fix (i.e. detection of this condition, and prevention of speech "lockout") is essential.
Thomas/all: What's your suggestion for dealing with this? (other than upgrading hardware, switching to esound, etc.)? Can we detect non-sharing audiocards, and post (and read) a warning dialog in gnopernicus? Is there a way to detect the conflict (real rather than potential) in gnome-sound-recorder, and post a warning there? "ideal" behavior IMO would be for the user to get a warning dialog from the non-text-to-speech audiodev client warning them that the audio device is already in use. Perhaps this means the text-to-speech engines need to be modified so that if they aren't using/can't use esound, and are using a non-sharable audio device, they grab the audiodevice and don't release it at all (thus blocking other audio clients) ?
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
you need a sound server (like esound) to be able to use an audio device by two or more apps simultaneously. accessing OSS device or alsa (without using dmix) would always bring this kind of error.
Stephane/all: The bug is that the audio device remains grabbed by the sound recorder when the message is posted. The correct behavior would be for the sound recorder to post the same error, but in such a way that the screenreader/TTS system can continue to access the audio device so that the error text can be spoken. It's not 100% clear to me from the bug reports why the TTS output fails once the error dialog is posted, since it appears that the /dev/dsp wasn't successfully opened by the sound recorder. This is the behavior that we want to avoid - I am not suggesting that there is a magic way to multiplex sound on a non-multiplexing platform, I am just pointing out that the failure mode currently locks the user out even when the sound is not played. That's the broken part.
severity is major for impacted users.
Bill, any idea? As far as I understand, this is a problem of resource sharing and policy. As a maemo developper, I can till we use some internal APIs to deal with that kind of conflicts automatically. Would that make sense to discuss the proper way to solve this or what should we do? If we suppose that we are all switching to PulseAudio, there should not be any problem anymore, hopefully. What's your opinions today? Thanks
gnome-media has been obsolete since the release of GNOME 3, nearly 4 years ago. Furthermore, the gnome-sound-recorder program in gnome-media has been replaced by the stand-alone, rewritten, gnome-sound-recorder program which has a different interface. The new program should not be affected by the bugs you filed, however, please verify whether the problems still exist and mark the bug as UNCONFIRMED when you have done so.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-sound-recorder/issues/1.