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

Peter Stokes mythtv at dadeos.co.uk
Mon Aug 2 17:06:14 UTC 2010


On 2 Aug 2010, at 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.
> 
>> 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

Thank you for your feedback Stuart.

Sorry, "anon" was me, I simply forgot to fill out the form correctly.

Best regards

Peter Stokes





More information about the mythtv-dev mailing list