On Sun, 12 Aug 2012 18:02:59 +0200 Tom Gundersen <teg@jklm.no> wrote:
On Sun, Aug 12, 2012 at 5:27 PM, Fons Adriaensen <fons@linuxaudio.org> wrote:
On Sun, Aug 12, 2012 at 04:00:47PM +0200, Tom Gundersen wrote:
You have showed that it is unnecessary in one particular (very simple) case. However, you have not showed that it is unnecessary in all cases, so this is not really relevant (had we been talking about a human doing this, you'd have a point of course).
I suspect that mathematical thinking is not your thing - no problem. For otherwise it would be clear that the 'simple' example I provided covers the general case.
Let me try again. I write a PA-aware sound app X that
* always sets its volume to 0 dB (max). * always outputs silence (zero valued samples).
As soon as that app runs, PA will set the master gain to 0 dB and use software scaling on all other apps. Now there are two possibilities:
* Either everything is OK (it will be), and we have shown that you can always leave the master gain at 0 dB,
* or everything is not OK, and we have shown that PA fails.
Your argument was clear (I'm ok with maths :) ). I was just pointing out that the case where the hardware can always be set to 0dB is not the interesting one.
You clearly want to avoid setting the hardware to >0dB if possible,
Correct me if I'm wrong but I don't think that's possible, because dB is normalized to max power (in watts = intensity).
but sometimes it is not possible (because you can't hear anything ;) ) so you have to have an algorithm to do it in the best way. Imagine you have two streams (A) which needs no software nor hardware gain, had it been played alone, and (B) which forces the hardware gain to be >0dB (and (A) to be scaled down in sw). If (B) goes away you clearly want to set the hw volume back to 0 and (A) to stop being scaled in sw.
The second case, where the total gain should be <0dB, I would have thought intuitively that doing this purely in software (especially on very faint signals) would be less ideal than doing it in hw (you'd be throwing away the resolution, wouldn't you?), but I'll admit that I don't have the experience to talk about that with any authority.
-t
-- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D