[mythtv] [mythtv-commits] Ticket #7517: Separate Volume control from Audio Output

[Ed W]

  On 02/08/2010 16:28, Stuart Morgan wrote:
> On Wednesday 30 Jun 2010 21:06:14 MythTV wrote:
>>   Replying to [comment:1 jyavenard]:
>>   >  I'm not sure what you are trying to achieve here, or what problem you
>>   The ultimate problem that I am wishing to fix is that of being unable to
>>   modify the volume when no audio is being played. The frequent problem of
>>   listening to music or video with the volume high, exiting, and then some
>>   time later listening to audio only to be blasted with the previous volume.
>>   Consumer electronics and other software applications rarely impose the
>>   restriction that it is only possible to change the volume when sound is
>>   being emitted.
> This is something I wanted to look at, there are already places where we want
> to be able to control volume but no AO instance exists notably MythNetVision
> and as noted by 'anon' when switching between music and video (The relative
> volume difference can be significant). There are still further instances where
> a global, always accessible volume control would fix UI annoyances e.g.  The
> current implementation of the 'background' music player prevents changes to
> music volume when the miniplayer UI is not on-screen.
>
> I won't comment on the solution in the patch, I've not looked at it, but it
> would be nice to have _a_ solution.

I'm all for this in principle!  In fact it's something that Isaac 
previously specifically stated as desirable...

Another thing that I added (way back when) with a hope that someone 
would pour sauce on it was the "AudioOutputSource" param when you open 
the audio device (TV/Video/Music/Phone/etc)?  The idea was that the 
volume control might have a per application memory and make use of this 
when different applications open the audio device?  I think it's been 
treated as a dead parameter since then, but it would be really nice if 
someone would pick it up and consider using it for something?  (there 
seem to be some tentative re-implementations of this feature starting to 
happen already causing some code duplication?)  See audiooutputsettings.h

The second issue I see with our current volume code is that it's got 
fledgling support for control of each channels level individually, but 
actually we never use this anywhere (useful).  This leads to often very 
awkward apis where sometimes we are trying to use per channel volume and 
at other times set a total level (and in the case of single channel or 
expanding left/right channel to both channels it gets even more 
awkward).  I think the answer here is that individual level controls 
belong in the specific audio driver only and the public interface needs 
to just have a single level, plus some special api to handle the single 
channel/upsample single channel case?

With regards to your patch it seems:

- Longer than I might have anticipated?  I guess there is a lot of 
shuffling around of code?
- Might need some testing by the maintainers of the individual audio 
drivers?  I can help out with the Jack testing?
- Seems like a few bits of cruft have crept in?  eg search for "<<<<"?


However, in general separating the volume control from the main audio 
layer seems like a great plan!

Good luck

Ed W