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