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

[MythTV]

#7517: Separate Volume control from Audio Output
-----------------------------------+----------------------------------------
 Reporter:  mythtv@…               |       Owner:  jyavenard     
     Type:  enhancement            |      Status:  infoneeded_new
 Priority:  minor                  |   Milestone:  unknown       
Component:  MythTV - Audio Output  |     Version:  unknown       
 Severity:  low                    |     Mlocked:  0             
-----------------------------------+----------------------------------------

Comment(by anonymous):

 Replying to [comment:1 jyavenard]:
 > I'm not sure what you are trying to achieve here, or what problem you
 are trying to *fix*...
 >
 The outcomes that I wish to achieve with these modifications are to reduce
 code complexity and increase end user friendliness and experience.

 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.

 > Moving volume control from within the sub AO class, only to have to
 retest externally which framework is to be used , IMHO only adds
 complexity , extra code, more files, all of those without solving
 anything...
 >
 I appreciate the reasons behind the existing behaviour based upon the
 current implementation, which is why I am proposing a separation of
 concerns between the audio output objects and separate volume control
 objects. I hope that if you consider the volume control more in terms of a
 user interface component and less in terms of the affect it has on the
 audio then this separation of concerns may become clearer.

 One aspect of the proposed implementation is that volume change
 notifications be event driven. This approach allows for further
 simplification of code by allowing multiple volume control objects to be
 instantiated all referencing the same underlying hardware. So, for
 example, a volume control object may be instantiated purely to access
 volume change events in order to drive the graphical aspects of presenting
 a volume level overlay; But it may be advantageous to instantiate a
 separate object within the key-press handling code that drives the
 adjustment of the volume. Such an approach elegantly follows the model-
 view-controller paradigm and is felt to be of particular importance in the
 ideal scenario where the volume is controlled “globally” from the main
 menu key-press handler but MythMusic and TV playback wish to present
 graphical feedback of the changes.

 > Also, a requirement on OSS >= 4 is unlikely to ever be committed

 The requirement for OSS >= 4 stems from the desire to present user-
 friendly textual descriptions of audio hardware as opposed to the rather
 cryptic machine-friendly mechanisms used internally, as OSS 3 does not
 offer such a capability. My rationale is that if anyone wishes to use OSS
 over ALSA, then they are likely to already be using version 4. Personally,
 I feel that we should either support OSS 4 or not support OSS. The OSS 4
 implementation is provided purely for completeness, I have no intention of
 ever using it.

 I am happy to add a similar user-friendly enumeration implementation for
 audio output classes (although I notice that this is an area you have
 already made improvements to recently) and to make the modifications
 necessary to realise my goal of a “global” volume implementation. I have
 not developed such an implementation to date due to the relatively
 invasive nature of such a change and the challenges associated with
 maintaining such changes over a prolonged period of time. Simply removing
 the volume control functionality from existing audio output objects is the
 first step along this road and has been relatively easy to maintain.
 Although the number of updated patches attached to this ticket are
 testaments to the fact that it is not entirely trivial.

 If there is any further information I may provide you with then please do
 not hesitate to ask. I appreciate the time you have spent in consideration
 of these modifications.

-- 
Ticket URL: <http://svn.mythtv.org/trac/ticket/7517#comment:2>
MythTV <http://www.mythtv.org/>
MythTV