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

[Peter Stokes]

On 5 Aug 2010, at 12:51, ryan patterson wrote:

> On Sat, Nov 7, 2009 at 4:42 PM, MythTV <mythtv at cvs.mythtv.org> wrote:
>> #7517: Separate Volume control from Audio Output
>> -----------------------------------+----------------------------------------
>>  Reporter:  mythtv@…               |       Owner:  jyavenard
>>     Type:  enhancement            |      Status:  new
>>  Priority:  minor                  |   Milestone:  unknown
>> Component:  MythTV - Audio Output  |     Version:  unknown
>>  Severity:  medium                 |     Mlocked:  0
>> -----------------------------------+----------------------------------------
>> 
>>  With the exception of the software volume control implementation all
>>  interfaces target system level volume controls. Normally such controls
>>  should not be modified by an application, however as the primary intention
>>  of MythTV is to take control of the whole PC, these implementations
>>  provide the best results.
> 
> I just want to comment on the one bit I quoted above.  In my case I do
> _not_ want MythTV to take control of the whole PC.  Yes mythfrontend
> is the application I interface with the most on that PC.  But  I use
> <alt><tab> to switch to different applications while leaving
> mythfrontend running in the background.  I do this several times every
> day.
> 

There are generally two types of volume control implementation, attenuation, and amplification. Attenuation is generally applied in software by multiplying individual sample values by a factor less than unity. Whilst such an implementation has the affect of reducing the volume it also has the undesirable side effect of reducing the dynamic range and therefore the audio quality. Amplification is applied in the analogue domain, after the digital-to-analogue conversion, and whilst quality is highly dependant upon the amplifier's components and implementation it is not inherently limited.

Whilst it is certainly not the case that all soundcard system volume controls are implemented using amplification, it is at least a possibility. It is upon this understanding that I assert that system volume control implementations are favourable, in order to achieve the best audio quality and "provide the best results".

Another important distinction to make is that between "mixing" and "volume" control. The implementation I have proposed is aimed solely at providing "volume" control, that is adjusting the overall output audio level. This is in contrast to "mixing" which seeks to adjust the relative audio levels between multiple sources. Traditional soundcard mixers provide a means of adjusting the relative levels of inputs and outputs of the soundcard (e.g. PCM/Wave, Midi, Mic, etc.) and software mixers seek to adjust the relative audio levels of multiple applications potentially running simultaneously.

The case you describe, of having mythfrontend running in the background, is the common case for most audio applications. Such circumstances are best served by a "mixer" implementation, where the user can control the relative audio levels of multiple audio applications. It is upon this understanding that I assert that "normally such controls [system level volume controls] should not be modified by an application". However, due to the audio quality trade-offs outlined above and the fact that MythTV is intended more to "take control of the whole PC" I feel the exception to this rule is justified.

> Care should be taken to ensure mythfrontend doesn't adversely affect
> other applications the user might want to run in parallel
> (mythfrontend using operating system global volume controls does
> this).  

I entirely agree that the usage scenario you describe should be catered for. The implementation I am proposing provides two main features that support such usage:

Firstly, I propose to eliminate all volume level initialisation. The existing implementation stores the volume in the database and applies it upon initialisation. Whilst this approach works in a scenario where the PC is only used to run MythTV it fails for more general purpose usage, for example:

* Run MythTV
* Set volume to high
* Exit MythTV
* Run another music player
* Reduce volume to a comfortable level
* Launch MythTV
* Blow up speakers :-(

Clearly, MythTV should simply use the volume as it is currently set, and provide a means of adjusting the volume should the current value not be the desired one, the volume should not be set it to an arbitrary value that just happens to be the value from the previous invocation of MythTV. Additionally, the implementation I have proposed does not store "current" volume, instead it queries the underlying audio interface whenever necessary. This approach, in conjunction with the implementation of adjustment callbacks means that any changes made to the volume may be reflected within MythTV (via video overlays etc.) whenever the volume is adjusted irrespective of whether the adjustment was instigated by MythTV.

The second feature is provided by the "software" volume control. Whilst it results in potentially lower quality audio, software volume control is generally favourably to no volume control at all and is therefore provided as a fallback. The software volume control is implemented within the MythTV application so when configured to use it the application behaves as more common audio applications.


I appreciate that everyone has different preferences, but my requirements fall into two modes of operation:

* MythTV as a "device" controlling the PC's system volume
* MythTV as an application, where I disable MythTV's volume control and use a separate mixer application


> For instance the old mythfrontend audio code that disabled
> pulseaudio and grabbed control of ALSA even when there was no audio
> playing was a major annoyance.  using <alt><tab> and playing a video
> in a different application didn't work (and didn't give an error
> message or explanation saying why it didn't work).
> 

Agreed. It is also worth noting that volume controls are not "exclusive" in the same way audio outputs tend to be. A correctly implemented volume interface, using adjustment notification callbacks, can support many simultaneous clients.

Peter

> -Ryan
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev