This patch does the following:
- Introduces an owned_critical_section object to be able to assert that a
current thread owns a critical section
- Change the auto_lock to use the above, add auto_unlock (basically like the
Gecko AutoEnter/AutoExit things)
- Fix an issue during audio output device switch where the clock would use the
old sample rate. Apparently I did not notice this because my headset and the
sound card on this laptop have the same rate
- Check that we could acquire a device_enumerator in the ctor before
deallocating in the dtor, as that can happen if a ton of streams are running at
once (I had this issue running the full mochitest suite)
- Stop getting another device_enumator in unregister_notification_client, fixing a leak
- Assert that setup_wasapi_stream and close_wasapi_stream are called with the lock held, this was the cause of the crash for this bug
- Make close_wasapi_stream clear out its state to make sure setup_wasapi_stream
and close_wasapi_stream are called in the right order (especially, not two
setup_wasapi_stream without close in between, since that would leak stuff)
- In wasapi_stream_destroy, unregister the notification client before destroying
the CRITICAL_SECTION (this was the cause of a crash I duped against this bug)
This patch does the following:
- Introduces an owned_critical_section object to be able to assert that a
current thread owns a critical section
- Change the auto_lock to use the above, add auto_unlock (basically like the
Gecko AutoEnter/AutoExit things)
- Fix an issue during audio output device switch where the clock would use the
old sample rate. Apparently I did not notice this because my headset and the
sound card on this laptop have the same rate
- Check that we could acquire a device_enumerator in the ctor before
deallocating in the dtor, as that can happen if a ton of streams are running at
once (I had this issue running the full mochitest suite)
- Stop getting another device_enumator in unregister_notification_client, fixing a leak
- Assert that setup_wasapi_stream and close_wasapi_stream are called with the lock held, this was the cause of the crash for this bug
- Make close_wasapi_stream clear out its state to make sure setup_wasapi_stream
and close_wasapi_stream are called in the right order (especially, not two
setup_wasapi_stream without close in between, since that would leak stuff)
- In wasapi_stream_destroy, unregister the notification client before destroying
the CRITICAL_SECTION (this was the cause of a crash I duped against this bug)
