[pulseaudio-discuss] [PATCH v2 5/5] alsa-mixer: Improve volume handling for Terratec Aureon Dual USB

[Tanu Kaskinen]

On Sat, 2015-04-18 at 11:08 +0500, Alexander E. Patrakov wrote:
> 18.04.2015 01:26, Tanu Kaskinen wrote:
> > This card can be used in analog or digital mode, and in the digital
> > mode there's no hardware volume or mute support. With the default
> > configuration PulseAudio only sees a single "speaker" port, and
> > assumes that controlling the Speaker element has some effect, which
> > is not true in the digital mode. To work around this, let's add a
> > special path configuration for this card to disable hardware volume.
> >
> > It would be better to disable hardware volume only in the digital
> > mode, but I believe there's no way to automatically figure out which
> > mode is in use, and requiring the user to tell which mode is in use
> > at any given time would not be user-friendly.
> 
> I have one concern with this plan. You are going to always use software 
> volume on a high-end card,

I wouldn't call this high-end:
http://terratec.com/details.php?artnr=10542#.VTI0u-Sxpz0

> and default to 30%, which is around -30 dB. 
> So you have just robbed 5 bits out of the DAC resolution. Due to the 
> fact that internal processing in PulseAudio is most likely based on 
> 16-bit samples in this use case, the DAC effectively becomes only 
> 11-bit, and without proper dithering. I am not sure whether owners of 
> the said card will appreciate that.
>
> So effectively, you are trading one bug for another. Sorry, I don't have 
> any easy and constructive suggestions.

You're right, but in my opinion the trade is beneficial.

One idea would be to make it configurable in some better way than via
profiles. The problem with card profiles in this case is that it's
impossible to properly explain to the user what are the pros and cons of
the different profiles. I'd like to make it possible for various device
backends to somehow expose non-standard options in UIs, with associated
help text. This use case alone probably doesn't warrant such extra
complexity, but there might be other use cases too that would benefit
from that.

> Does the card support 32-bit input samples? [that was the solution to 
> the same kind of problem in the plug+softvol+dmix era that was 
> implemented on my request in 2008]

Unfortunately, the card only supports 16-bit samples.

-- 
Tanu