Open Bug 725444 Opened 9 years ago Updated 7 years ago

10-15ms main thread startup optmization in Windows AudioSession

Categories

(Core :: Widget, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

People

(Reporter: bbondy, Unassigned)

Details

Attachments

(1 file)

Attached patch Patch v1.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-
> 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.
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.
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.
Assignee: netzen → nobody
You need to log in before you can comment on or make changes to this bug.