mythtv at cvs
Jun 30, 2010, 1:06 PM
Post #3 of 6
(196 views)
Permalink
|
|
Re: Ticket #7517: Separate Volume control from Audio Output
[In reply to]
|
|
#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
_______________________________________________
mythtv-commits mailing list
mythtv-commits [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-commits
|
