[mythtv] [mythtv-commits] Ticket #7517: Separate Volume control	from Audio Output
    Peter Stokes 
    mythtv at dadeos.co.uk
       
    Fri Aug  6 23:41:31 UTC 2010
    
    
  
On 5 Aug 2010, at 10:00, Ed W wrote:
> 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
I consider that problem to be more one of "mixing" rather than "volume" control. The implementation I propose solely aims to provide a "volume" control, namely a means of adjusting the overall audio output level. Balancing the levels of different audio sources, or channels is a relatively infrequent operation requiring a considerably more complex user interface that is best placed within the setup/configuration screens. The interface for controlling the volume should be as simple as possible (increase/decrease/mute). 
> 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?
It also adds asynchronous event callbacks and device enumeration support.
> - Might need some testing by the maintainers of the individual audio drivers?  I can help out with the Jack testing?
It is mainly removing code from audio drivers. The proposed implementation also allows for mix 'n' match audio/volume interfaces. So, for example, there is little benefit from using Jack's software volume implementation as MythTV already provides its own software volume control. 
> - Seems like a few bits of cruft have crept in?  eg search for "<<<<"?
Thanks, I've fixed that now.
> 
> 
> However, in general separating the volume control from the main audio layer seems like a great plan!
Well I thought so ;-)
Peter
> Good luck
> 
> Ed W
> 
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-dev/attachments/20100807/6334c41e/attachment.htm>
    
    
More information about the mythtv-dev
mailing list