On Mon, Mar 12, 2012 at 11:52 PM, malc wrote:
> 1 << 32 = 1.0 in 64(32.32) fixed point... the type of l/r is int64_t
Ok, I'll leave it as is then if it is on purpose.
--
Marc-André Lureau
On Mon, 12 Mar 2012, Marc-Andr? Lureau wrote:
> On Mon, Mar 12, 2012 at 10:42 PM, malc wrote:
> > nominal_volume.[lr] is int64_t... i don't get where you take this ^32
> > from.
>
> from where it is defined, audio/audio.c:
>
> const struct mixeng_volume nominal_volume = {
> .mute = 0,
> #if
On Mon, Mar 12, 2012 at 10:42 PM, malc wrote:
> nominal_volume.[lr] is int64_t... i don't get where you take this ^32
> from.
from where it is defined, audio/audio.c:
const struct mixeng_volume nominal_volume = {
.mute = 0,
#ifdef FLOAT_MIXENG
.r = 1.0,
.l = 1.0,
#else
.r = 1ULL
On Mon, 12 Mar 2012, Marc-Andr? Lureau wrote:
> On Mon, Mar 12, 2012 at 10:11 PM, malc wrote:
> >> AUD_set_volume_out (SWVoiceOut *sw, int mute, uint8_t lvol..)
> >>
> >> sw->vol.l = nominal_volume.l * lvol / 255;
> >>
> >> So the range was [0..2^8-1] and then it becomes [0..2^32], which looks
>
On Mon, Mar 12, 2012 at 10:11 PM, malc wrote:
>> AUD_set_volume_out (SWVoiceOut *sw, int mute, uint8_t lvol..)
>>
>> sw->vol.l = nominal_volume.l * lvol / 255;
>>
>> So the range was [0..2^8-1] and then it becomes [0..2^32], which looks
>> wrong to me.
>
> It actually becomes [-2^63..2^63-1] nomin
On Mon, 12 Mar 2012, Marc-Andr? Lureau wrote:
> On Mon, Mar 12, 2012 at 10:00 PM, malc wrote:
> > I really do not understand your point at all, mixeng_volume fields
> > are int64_t's it's irrelevant what you initialize them with, they
> > are still 64bit integers, and UINT_MAX as i already said i
On Mon, Mar 12, 2012 at 10:00 PM, malc wrote:
> I really do not understand your point at all, mixeng_volume fields
> are int64_t's it's irrelevant what you initialize them with, they
> are still 64bit integers, and UINT_MAX as i already said is not even
> correct, it's 1/(2**32-1) less than one in
On Mon, 12 Mar 2012, Marc-Andr? Lureau wrote:
> On Mon, Mar 12, 2012 at 9:29 PM, malc wrote:
> >> So what I meant is rather G_MAXUINT32.
> >
> > Just leave it as is, it's perfectly fine.
>
> But it's not convenient to fit into a regular integer, as the number
> of steps is 2^32 + 1. Why is it pr
On Mon, Mar 12, 2012 at 9:29 PM, malc wrote:
>> So what I meant is rather G_MAXUINT32.
>
> Just leave it as is, it's perfectly fine.
But it's not convenient to fit into a regular integer, as the number
of steps is 2^32 + 1. Why is it preferrable this way rather than a
MAXUINT? I must be missing s
On Mon, 12 Mar 2012, Marc-Andr? Lureau wrote:
> On Mon, Mar 12, 2012 at 9:03 PM, malc wrote:
> > How's putting UINT_MAX into int64_t more appropriate? UINT_MAX is
> > even one less than one in 32.32 fixpoint... I must be missing something
> > here.
>
> Right, the patch series used to have 2^32 -
On Mon, Mar 12, 2012 at 9:03 PM, malc wrote:
> How's putting UINT_MAX into int64_t more appropriate? UINT_MAX is
> even one less than one in 32.32 fixpoint... I must be missing something
> here.
Right, the patch series used to have 2^32 -1, so it can fit in a
16bits or 32bits integer.
So what I
On Mon, 12 Mar 2012, Marc-Andr? Lureau wrote:
> It's more appropriate to set the maximum value into a fitting integer.
> ---
> audio/audio.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/audio/audio.c b/audio/audio.c
> index bd9237e..06c2384 100644
> --- a/audi
It's more appropriate to set the maximum value into a fitting integer.
---
audio/audio.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/audio/audio.c b/audio/audio.c
index bd9237e..06c2384 100644
--- a/audio/audio.c
+++ b/audio/audio.c
@@ -110,8 +110,8 @@ const struct
13 matches
Mail list logo