All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lennart Poettering <mznyfn@0pointer.de>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: alsa-devel@alsa-project.org
Subject: Re: Latency of mixer reconfiguration
Date: Fri, 19 Feb 2010 16:03:30 +0100	[thread overview]
Message-ID: <20100219150330.GA25873@tango.0pointer.de> (raw)
In-Reply-To: <20100219095438.GM2032@sirena.org.uk>

On Fri, 19.02.10 09:54, Mark Brown (broonie@opensource.wolfsonmicro.com) wrote:

> > > I suspect that trying to offer additional resolution in this way is more
> > > trouble than it's worth if you're concerned about the artifacts that are
> > > introduced during updates.  Providing per-channel differentiation if the
> > > hardware has only mono control has much fewer problems, though.
> 
> > The current logic is to not do any software adjustment if the hardware
> > adjustment is "close enough" to the total adjustment we want to do,
> > tested against a threshold. Which I think is quite a reasonable
> > approach because it enables/disables this feature not globally, but
> > looks at each case and enables this logic only if it really has a
> > benefit.
> 
> That sounds reasonable, though it's kind of surprising to me that there
> is hardware out there which benefits from it - I'd have expected either
> adequate resolution or nothing at all there.

On my own hardware this mechanism proved useful in two cases: one card
had a single volume slider for both channels and with PA you can now
set their volume independantly. And one set of external USB speakers
has a volume slider that starts at a very high level, so that the
minimum volume setting is everything but silent. PA extends the scale
downwards so that this limitation of the hw does not become apparent.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

  reply	other threads:[~2010-02-19 15:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-17 18:15 Latency of mixer reconfiguration Lennart Poettering
2010-02-17 20:34 ` James Courtier-Dutton
2010-02-18 10:01 ` Mark Brown
2010-02-18 18:04   ` Lennart Poettering
2010-02-19  9:01     ` Jaroslav Kysela
2010-02-19  9:43       ` Mark Brown
2010-02-19  9:54     ` Mark Brown
2010-02-19 15:03       ` Lennart Poettering [this message]
2010-02-20  3:59     ` Raymond Yau
     [not found]       ` <20100221192621.GC30380@tango.0pointer.de>
2010-02-22  8:50         ` Raymond Yau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100219150330.GA25873@tango.0pointer.de \
    --to=mznyfn@0pointer.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.