From: Raymond Yau <superquad.vortex2@gmail.com>
To: alsa-devel@alsa-project.org
Subject: Re: Latency of mixer reconfiguration
Date: Mon, 22 Feb 2010 16:50:40 +0800 [thread overview]
Message-ID: <4f3252891002220050n6198d49dn61ab6f1c0720c78e@mail.gmail.com> (raw)
In-Reply-To: <20100221192621.GC30380@tango.0pointer.de>
2010/2/22 Lennart Poettering <mznyfn@0pointer.de>
> On Sat, 20.02.10 11:59, Raymond Yau (superquad.vortex2@gmail.com) wrote:
>
> >
> > 2010/2/19 Lennart Poettering <mznyfn@0pointer.de>
> >
> > >
> > > On Thu, 18.02.10 10:01, Mark Brown (
> broonie@opensource.wolfsonmicro.com)
> > > wrote:
> > >
> > >
> > > 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.
>
> > PA 's watermark is already 20 ms if you want to do any software
> adjustment
> > by PA server
>
> It's not necessarily 20ms. That's just the default (which we
> unfortunately had to pick very large, since ALSA right now does not
> inform us about transfer block granularity).
>
I think ALSA did inform the appliication the the granularit is period size,
it is the responsibilty of the application which use timer scheduling to
find out the optimum granularity which may varies with different sound card,
different CPU speed
>
> But anyway, whatever the watermark is: this is a latency we know
> about, which means that we can delay the hw mixer updating
> accordingly. But that works correctly only if the hw mixer updating is
> immediate. WHich it most likely is not.
>
do you mean PA server will perform snd_pcm_rewind when the user change the
mixer volume ?
>
> So we now the software volume adjustment latency. We don't know the
> hardware volume adjustment latency, and assume it is 0. If we knew
> both we could sync up both changes perfectly, but this way our model
> has a weakness.
>
I have doubt there is any benefit if you even know those hardware volume
adjust ment latency which varies even when using the same chipset by
different OEM vendor sound card
>
> Lennart
> lsa-devel <http://mailman.alsa-project.org/mailman/listinfo/alsa-devel>
>
prev parent reply other threads:[~2010-02-22 8:50 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
2010-02-20 3:59 ` Raymond Yau
[not found] ` <20100221192621.GC30380@tango.0pointer.de>
2010-02-22 8:50 ` Raymond Yau [this message]
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=4f3252891002220050n6198d49dn61ab6f1c0720c78e@mail.gmail.com \
--to=superquad.vortex2@gmail.com \
--cc=alsa-devel@alsa-project.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).