Re: [Jack-Devel] query jack scaling factor?

PrevNext  Index
DateMon, 30 May 2011 22:27:18 +0300
From Dan Muresan <[hidden] at gmail dot com>
ToDan Muresan <[hidden] at gmail dot com>, Paul Davis <[hidden] at linuxaudiosystems dot com>, [hidden] at jackaudio dot org
In-Reply-Totorbenh Re: [Jack-Devel] query jack scaling factor?
Follow-UpPaul Davis Re: [Jack-Devel] query jack scaling factor?
>> Which is part 1 of my point -- unless Jack promises *never* to change
>> this scaling strategy, it should be available for those apps that need
>> bit-exactness.
>
> and how would you treat dithering then ?
> (which applications need bit exactness anyways ?)

What does dithering have to do with the scaling factor applied to
incoming PCM, **which is a constant** as Paul pointed out?! This is an
API issue.

I want to know what factor to use when converting back from floats to
PCM so that I get exactly what the sound card has given. If I apply a
constant test signal and measure it via Jack and via ALSA, I want to
be able to get the same results.

If you are against bit-exactness, that's your opinion. Perhaps you've
never worked on a DSP or implemented / tested standardized codecs
(which depend on bit-exact patterns).

> what if you record from another jack client ?

I was talking about preserving bit-exactness FOR DATA CAPTURED FROM
THE CARD. It's a DRIVER CONSTANT. No matter how many clients the
captured data passes through, the scaling factor is the same.

> while connected to -ddummy ?
> what should that report ?? zero bits ?

Irrelevant -- I was talking about physical drivers which apply
scaling. For the dummy driver, any common number of bits would do (16,
24).

> i think your trying to cripple your app. dont do that.
> people like using stuff in ways your didnt expect before.

I think you have no idea what I'm talking about, and you seem to be
quick to judge at the same time. It's a bad combo. Again, have you
ever worked on a DSP or implemented codecs whose test-suites specify
bit-exact data? Not that I'm doing that *right now*, but it would give
you the required perspective.

All I'm saying is that either the scaling factor applied to ALSA PCM
data should be guaranteed to be fixed in the API, or query-able via
the API. As a matter of principle. Now, I don't expect 0x7fff to
change, and I can use that (it's actually convenient with libsndfile),
but I stated what I consider to be "the ideal".


-- Dan
PrevNext  Index

1306783661.25665_0.ltw:2,a <BANLkTi=GHtJWiw2Yc0kSntvopg_sp-Wfaw at mail dot gmail dot com>