Open
Bug 725444
Opened 13 years ago
Updated 2 years ago
10-15ms main thread startup optmization in Windows AudioSession
Categories
(Core :: Widget, defect)
Tracking
()
NEW
People
(Reporter: bbondy, Unassigned)
Details
Attachments
(1 file)
7.84 KB,
patch
|
khuey
:
review-
|
Details | Diff | Splinter Review |
The COM function that adds the audio controls to the Windows Volume Mixer gets called at startup on the main thread and takes 10+ms.
We can instead offload this to a LazyIdleThread and continue on with normal startup work on the main thread.
For the parts of failure conditions that are being moved to the thread, they are non critical and also we don't check the return value anyway. The critical stuff still happens sync.
We currently call this init in nsAppShell::Run() and ignore the return value...
> // Ignore failure; failing to start the application is not exactly an
> // appropriate response to failing to start an audio session.
> mozilla::widget::StartAudioSession();
Attachment #595487 -
Flags: review?(jmathies)
Comment on attachment 595487 [details] [diff] [review]
Patch v1.
Per MSDN, an IAudioSessionControl object must be Release()d on the same thread it's created on (http://msdn.microsoft.com/en-us/library/windows/desktop/dd368246%28v=vs.85%29.aspx).
Note that it's not sufficient just to move the Release to the LazyIdleThread, because the physical thread may have gone away.
Attachment #595487 -
Flags: review?(jmathies) → review-
Reporter | ||
Comment 2•13 years ago
|
||
> When releasing an IAudioSessionControl interface instance, the client must
> call the interface's Release method from the same thread as the call
> to IAudioClient::GetService that created the object.
I'm not fully sure if this makes a difference but we don't call IAudioClient::GetService. We use GetAudioSessionControl to obtain an interface to an existing session.
> Alternatively, a client can obtain the IAudioSessionControl interface
> of an existing session without having to first create a stream
> object and add the stream to the session. Instead, the client
> calls the IAudioSessionManager::GetAudioSessionControl method
> with parameter AudioSessionGuid set to the session GUID.
(In reply to Brian R. Bondy [:bbondy] from comment #2)
> > When releasing an IAudioSessionControl interface instance, the client must
> > call the interface's Release method from the same thread as the call
> > to IAudioClient::GetService that created the object.
>
> I'm not fully sure if this makes a difference but we don't call
> IAudioClient::GetService. We use GetAudioSessionControl to obtain an
> interface to an existing session.
Yeah, I'm not sure, but I expect that the difference doesn't matter.
> > Alternatively, a client can obtain the IAudioSessionControl interface
> > of an existing session without having to first create a stream
> > object and add the stream to the session. Instead, the client
> > calls the IAudioSessionManager::GetAudioSessionControl method
> > with parameter AudioSessionGuid set to the session GUID.
Reporter | ||
Comment 4•13 years ago
|
||
We could perhaps do a timer for a few seconds after initialization is done on the main thread. But I'm not sure if it's worth the trouble for 10ms.
Reporter | ||
Comment 5•13 years ago
|
||
Actually I think it would be worth it to set a timer to do this after startup, but I'll wait a day to do that in case someone has objections.
Reporter | ||
Updated•11 years ago
|
Assignee: netzen → nobody
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•