Tie Stoffi's volumn to per-application volumn mixer in global sound applet

[GoogleCodeExporter]

Describe the feature you want implemented.
Some programs with volume controls tie their own internal volumn to the 
per-applications volumn control mixer in Windows 7. This would be a good thing 
for stoffi to do

Describe why you think that this feature is needed.
It reduces complexity. Currently, for many applications, Stoffi included, there 
are 3 locations to control the output volumn of music. Stoffi itself, Stoffi's 
per-application level mixer, and the overall volumn of the machine.

Are there any other projects that inspired you?
Windos Media Player 12

Do you have any screenshots or mockups to show a concept of this feature?

Original issue reported on code.google.com by zeigl...@gmail.com on 29 Jan 2012 at 12:58

• Blocking: #275

[GoogleCodeExporter]

We had our volume control being in sync with the global volume before. But we 
changed this since it just didn't feel right. Users wanted to have a different 
volume in Stoffi than they might have in the system as a whole.

However, we should sync with the per-app volume of Windows. Going from 3 volume 
locations to 2.

I am not sure how to approach this, though. I found this on CodeProject:
http://www.codeproject.com/Articles/18520/Vista-Core-Audio-API-Master-Volume-Con
trol

We should perhaps turn to MSDN and ask people there. We might also find a way 
to solve issue #291 then as well.

Original comment by ephracis on 29 Jan 2012 at 11:47

• Changed state: Accepted
• Added labels: Milestone-Han

[GoogleCodeExporter]

I think we just need to subscribe to the OnVolumeNotification provided by the 
MMDevice to adjust Stoffi's slider and adjustments to Stoffi's slider should in 
turn adjust the MMDevice volume. 
Additionally, 
http://msdn.microsoft.com/en-us/library/windows/desktop/aa511278.aspx
suggests that if we go this route with CoreAudio we should set playback 
internally to 100% gain.

Original comment by zeigl...@gmail.com on 29 Jan 2012 at 5:35

[GoogleCodeExporter]

I think it would be better to just do the MMDevice and perhaps look at their 
code for inspiration. We should do our best to make sure the code is as cross 
platform as possible. So we should keep SettingsManager.Volume as our main 
volume level and then just hook some code up to SettingsManager.PropertyChanged 
and do the volume changing.

Essentially what this means is that we have to move our volume code from 
MediaManager into the Platform folder (and set the volume to 100% in 
MediaManager on both BASS and YouTube). Perhaps this is good since volume 
control can differ between platforms and we should tailor to that.

Original comment by ephracis on 29 Jan 2012 at 8:31

[GoogleCodeExporter]

I have started work on this. It looks like the MMDevice API also exposes logic 
to show when the default playback device has changed, so wrapping the COM api 
(if only it came with a type lib :-() should allow progress on Issue #275.

Original comment by zeigl...@gmail.com on 29 Jan 2012 at 8:35

• Changed state: Started

[GoogleCodeExporter]

Great work! :D

Original comment by ephracis on 29 Jan 2012 at 10:01

[GoogleCodeExporter]

Original comment by zeigl...@gmail.com on 29 Jan 2012 at 10:03