User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/20070309 Firefox/184.108.40.206 Build Identifier: version 220.127.116.11 (20070326) Any custom alert (.wav-file) does not play. The default system sound doesn't output any sound either. Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: No sound output Expected Results: Sound output Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsISound.play]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://messenger/content/preferences/general.js :: anonymous :: line 141" data: no]
Joona, do you still see this? similar to bug 415752, 18.104.22.168, also linux
This problem can be resolved by installing the EsounD package appropriate for your distribution. Installation of EsounD REALLY REALLY should be specified as a requirement in the release notes, as it seems to be a problem that pops up regularly, and not everyone installs this package by default
Don`t solve the problem.
None other ideas?
I think this is solved.
->INVALID ("FIXED" is used only when known code changes resolved the issue)
For me it is not fixed. I installed the EsounD-package for my distri an the sound don`t play.
Reopened due to request.
As mentioned previously, I had this EXACT same problem with an upgraded Gentoo build on a laptop. Once I installed the EsounD package, audio alerts started working again with the default binary distribution of Firefox 3.01. I don't recall making any other changes. Note that I did not actually have to run the esd daemon for sound to work. Here are the files that were installed for the version of EsounD that I installed, v0.2.38-r1. Hopefully this will be of some help if you can compare this to what was installed on your machine. You might want to run ldd on your EsounD shared libraries to make sure that something is not missing or broken. First, the contents of /etc/esd/esd.conf (the esd configuration file). The file contents are between the dashed lines, but do not include the dashed lines: ------------------- [esd] # autospawning is not recommended, since it can't really be done # right. If you want your login session to be using a sound daemon, # you should start it from the session controller, not some random # app inside. auto_spawn=0 spawn_options=-terminate -nobeeps -as 2 spawn_wait_ms=100 # default options are used in spawned and non-spawned mode default_options= --------------------------- The files that were installed (I have left out startup files, man pages, etc): file /usr/bin/esd-config file /usr/bin/esdcat file /usr/bin/esdctl file /usr/bin/esddsp file /usr/bin/esdfilt file /usr/bin/esdloop file /usr/bin/esdmon file /usr/bin/esdplay file /usr/bin/esdrec file /usr/bin/esdsample file /usr/bin/esound-esd file /usr/include/esd.h file /usr/lib/libesd.a file /usr/lib/libesd.la symlink /usr/lib/libesd.so -> libesd.so.0.2.38 symlink /usr/lib/libesd.so.0 -> libesd.so.0.2.38 file /usr/lib/libesd.so.0.2.38 file /usr/lib/libesddsp.a file /usr/lib/libesddsp.la symlink /usr/lib/libesddsp.so -> libesddsp.so.0.2.38 symlink /usr/lib/libesddsp.so.0 -> libesddsp.so.0.2.38 file /usr/lib/libesddsp.so.0.2.38 file /usr/lib/pkgconfig/esound.pc
so back to comment 7, this is not a thunderbird bug? i.e. invalid
Still having the same problem since upgrading to Fedora13 & Thunderbird 3.1.1
(In reply to comment #12) > Still having the same problem since upgrading to Fedora13 & Thunderbird 3.1.1 That should be fixed in 3.1.2 that was just released.
A similar problem occurred to me on a gentoo system as well. As noted in bug 529522, lightning did not want to play an alarm sound without esound installed. This also happens with Thunderbird 3.1.4! So this might not be fully resolved yet.
The problem is still there on Ubuntu with Thunderbird 3.1.6 and TB3.3a1. No default sound system can be heard, so I believe that the bug should be reopened.
I use KDE 4.6.3 and Mageia 1, and there is no Esound module available. Pidgin uses ALSA to play sounds, and Pulseaudio is also very popular. Thunderbird should use them when available. From what I know, Esound is obsolete. Should this bug be reopened, or is there another bug filed to use ALSA/Pulseaudio in Thunderbird?
In principle, it would be great if lightning would not depend on any sound framework on Linux. Maybe it is somehow possible to simply hand over the alarm WAV file to Thunderbird's basis (Gecko, right?) which then takes care of it? I am not a Mozilla expert, but a search on the Internet makes me believe it could be possible: - https://developer.mozilla.org/en/nsISound - http://www.geckofx.org/viewtopic.php?id=435 Also vote for REOPENING or filing a new bug
> In principle, it would be great if lightning would not depend on any sound > framework on Linux. > > Maybe it is somehow possible to simply hand over the alarm WAV file to > Thunderbird's basis (Gecko, right?) which then takes care of it? So I took a quick peek at the Lightning alarm code, and it looks like it's making use of the nsISound component interface already: http://mxr.mozilla.org/comm-central/source/calendar/base/src/calAlarmMonitor.js#143 I also took a look at the Linux implementation of nsISound: http://mxr.mozilla.org/comm-central/source/mozilla/widget/src/gtk2/nsSound.cpp#132 It seems that the implementation tries to connect to libesd, libasound, and libcanberra. Whichever one it finds, it uses. > In principle, it would be great if lightning would not depend on any sound > framework on Linux. So, from the looks of it, Lightning just relies on nsISound. It's Gecko that's relying on either libesd, libasound or libcanberra.
I had to install libesd0 on Ubuntu 10.10 to get it working although libcanberra is installed too...
Reopening per my comment 16. Installing EsounD is a workaround (which doesn't work e.g. in Mageia 1 as there is no such module), not a fix. All other applications I have which need to play sounds, including Songbird, Pidgin, Firefox, etc..., are able to play sound correctly. Thunderbird should be able to use the current active audio method, being PulseAudio, ALSA, or anything else installed on the system and shouldn't rely on one specific method. This problem still exists with Thunderbird 6.0.2. Comment 18 says that if EsounD cannot be found, Thunderbird should try with ALSA, but this is clearly not the case. If the bug is in Gecko, this bug should be moved to the appropriate component in the Core product, or be marked as depending on such a bug if it already exists.
We should just use HTML5 audio to play sounds.
It seems this bug is identical to bug 635918 which has patches to use libcanberra for nsISound::Play.