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)
This is implemented by detecting when the default audio output device changes,
stopping the current stream, and starting a new one using the new default audio
output device.
--HG--
extra : rebase_source : 94df344aecca0f940ba7216275176763336beb96
waveOutSetVolume adjusts the system (or app, on Vista up, but we only use
WinMM on XP) "PCM Volume" rather than a per-waveOut volume, which means any
audio stream we adjust the volume on has an undesirable higher-level effect.
Fix this by dropping the support for waveOutSetVolume and always using the
soft volume support.
While here, fix a bug in the soft volume code where float32 samples are
handled.
There are, sadly, many combinations of linkage in use throughout the tree.
The main differentiator, though, is between program/libraries related to
Gecko or not. Kind of. Some need mozglue, some don't. Some need dependent
linkage, some standalone.
Anyways, these new templates remove the need to manually define the
right dependencies against xpcomglue, nspr, mozalloc and mozglue
in most cases.
Places that build programs and were resetting MOZ_GLUE_PROGRAM_LDFLAGS
or that build libraries and were resetting MOZ_GLUE_LDFLAGS can now
just not use those Gecko-specific templates.
