10-15ms main thread startup optmization in Windows AudioSession

NEW
Unassigned

Status

()

7 years ago
5 years ago

People

(Reporter: bbondy, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
Created attachment 595487 [details] [diff] [review]
Patch v1.

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

7 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

7 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

7 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

5 years ago
Assignee: netzen → nobody
You need to log in before you can comment on or make changes to this bug.