683184 - Make @mozilla.org/sound;1 an XPCOM service instead

Status: NEW

(Core :: Widget, defect)

Description

[Brian R. Bondy [:bbondy]]

nsSound (@mozilla.org/sound;1) is currently implemented as an XPCOM object and so a new nsSound gets instantiated every time a sound MAY get played.

Because of bugs like Bug 498079 and Bug 504670, async sound and threading is currently being done in Windows, and needs to be added to Linux.  Alternatively all threading might be moved to the xpwidget layer in Bug 520417.

The problem is that every time we click the menu button in Firefox in Windows (and eventually Linux once Bug 504670 gets implemented), we spawn a new thread. Most users use the defaults of no sounds in Windows, yet we still spawn a new thread and shut it down each time a sound may be played.  

It would be better to have nsSound as as a singleton XPCOM service.  nsISound represents a way to play sounds and not individual sound clips as per the methods of the interface.  We would simply dispatch a new event to the sound player thread for each method that is called.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Sounds good.

At some stage we should reimplement nsSound::Play() to use libcubeb (see bug 623444). Then that part can be cross-platform code.

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Although another option is to deprecate nsISound::Play() and try to get clients to just use <audio> elements instead.

Comment 3

[Brian R. Bondy [:bbondy]]

I was just looking at libsydneyaudio, thanks for the tip on libcubeb  :)

Comment 4

[Brian R. Bondy [:bbondy]]

:roc, I posted regarding your Comment 1 and Comment 2 here: Bug 683263

Comment 5

[[e-mail]]

(In reply to Robert O'Callahan from comment #2)
> try to get clients to just use <audio> elements instead.
How do you get an <audio> element without a document?

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

You don't, but most code can probably get a document.