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

[Stuart Morgan]

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.

From a UI perspective the volume key bindings are already used in so many 
places that they should be global bindings. The mythmusic port has already 
added a volume popup so that changes can be reflected visually to the user 
even when the volume is adjusted outside of mythmusic, this can be moved to 
mythfrontend instead.

>  > 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.

OSS4 support would be very welcome indeed, in my experience it's superior to 
ALSA in several respects, not least it's user-friendliness. I've threatened to 
add support myself on several occasions but it's one of those things that gets 
pushed down the list by high priority tasks.

-- 
Stuart Morgan