At Wed, 29 May 2019 10:20:38 +0300,
Andreas Gustafsson wrote:
> > Now, you omit the most critical bit: what would you name the thing? :)
> > From "the proper way to do audio scaling" I infer that AUDIO_SCALEDOWN
> > (or however that was spelled) should be ok, shouldn't it?
>
> I'm not fussy about
Valery Ushakov wrote:
> Now, you omit the most critical bit: what would you name the thing? :)
> From "the proper way to do audio scaling" I infer that AUDIO_SCALEDOWN
> (or however that was spelled) should be ok, shouldn't it?
I'm not fussy about the naming, just about the math :) AUDIO_SCALEDOW
On Tue, May 28, 2019 at 20:25:33 +0300, Andreas Gustafsson wrote:
> On May 23, Valery Ushakov wrote:
> > This feels inverted. The mathematically correct operation required
> > here is symmetric division (that rounds towards zero).
>
> Rounding towards zero is absolutely the wrong thing to do fo
On May 23, Valery Ushakov wrote:
> This feels inverted. The mathematically correct operation required
> here is symmetric division (that rounds towards zero).
Rounding towards zero is absolutely the wrong thing to do for audio,
because it introduces a discontinuity, which in turn causes
unnecess
> Date: Mon, 27 May 2019 22:28:37 +0900
> From: Tetsuya Isaki
>
> At Sat, 25 May 2019 18:01:11 +0300,
> Valery Ushakov wrote:
> > My point is exactly that you are confusing implementation detail that
> > uses right shift as a good enough implementation (which, I reiterate,
> > I don't object to h
At Sat, 25 May 2019 18:01:11 +0300,
Valery Ushakov wrote:
> Speaking in the abstract: The operation that happens here is
> rescaling, as far as I understand. Yes, the two-complement ranges are
> lopsided with an extra value on the negative side, but that is far
> less important, I think, than comm
On Fri, May 24, 2019 at 21:51:35 +0900, Tetsuya Isaki wrote:
> At Thu, 23 May 2019 17:08:42 +0300,
> Valery Ushakov wrote:
> > > +#if defined(__GNUC__)
> > > +/* gcc defines '>>' as ASR. */
> > > +#define AUDIO_ASR(value, shift) ((value) >> (shift))
> > > +#else
> > > +#define AUDIO_ASR(value, sh
At Fri, 24 May 2019 07:01:56 +,
m...@netbsd.org wrote:
>
> we don't have anyone using the non-__GNUC__ case
This is C specification matter. It's not important whether
such compiler really exist.
Thanks,
---
Tetsuya Isaki
At Thu, 23 May 2019 17:08:42 +0300,
Valery Ushakov wrote:
> > +#if defined(__GNUC__)
> > +/* gcc defines '>>' as ASR. */
> > +#define AUDIO_ASR(value, shift)((value) >> (shift))
> > +#else
> > +#define AUDIO_ASR(value, shift)((value) / (1 << (shift)))
> > +#endif
>
> This feels inverted.
we don't have anyone using the non-__GNUC__ case
On Thu, May 23, 2019 at 21:28:51 +0900, Tetsuya Isaki wrote:
> +/*
> + * AUDIO_ASR() does Arithmetic Shift Right operation.
> + * This macro should be used for audio wave data only.
> + *
> + * Division by power of two is replaced with shift operation in the most
> + * compiler, but even then roun
At Wed, 8 May 2019 18:14:28 +,
m...@netbsd.org wrote:
> Is there some scenario where this made a difference?
> it sounds like an optimization that a compiler should already do
>
> 5234:#if defined(AUDIO_USE_C_IMPLEMENTATION_DEFINED_BEHAVIOR) &&
> defined(__GNUC__)
> 5235-
At Tue, 21 May 2019 10:34:37 -0300 (ADT),
Jared McNeill wrote:
>
> You are correct, my mistake!
No problem, thank you.
---
Tetsuya Isaki
> On Tue, 21 May 2019, Tetsuya Isaki wrote:
>
> > At Thu, 9 May 2019 10:28:19 -0300 (ADT),
> > Jared McNeill wrote:
> >> With order of operations here, and t
At Sat, 11 May 2019 00:36:42 +,
m...@netbsd.org wrote:
> - ioctl AUDIO_GETFD/SETFD, AUDIO_GETCHAN/SETCHAN are obsoleted.
> ossaudio is still using this, although I don't know if it's critical.
>
> compat/ossaudio/ossaudio.c:779
>
> case OSS_SNDCTL_DSP_SETDUPLEX:
> idat
You are correct, my mistake!
On Tue, 21 May 2019, Tetsuya Isaki wrote:
At Thu, 9 May 2019 10:28:19 -0300 (ADT),
Jared McNeill wrote:
With order of operations here, and track->volume being in range 0...256, I
don't think this will work anyway. volume of 255 of less will cause the
sample to be 0
At Thu, 9 May 2019 10:28:19 -0300 (ADT),
Jared McNeill wrote:
> With order of operations here, and track->volume being in range 0...256, I
> don't think this will work anyway. volume of 255 of less will cause the
> sample to be 0, and 256 the original value.
(A * B >> C) is equivalent to ((A * B
- ioctl AUDIO_GETFD/SETFD, AUDIO_GETCHAN/SETCHAN are obsoleted.
ossaudio is still using this, although I don't know if it's critical.
compat/ossaudio/ossaudio.c:779
case OSS_SNDCTL_DSP_SETDUPLEX:
idat = 1;
error = ioctlf(fp, AUDIO_SETFD, &idat);
With order of operations here, and track->volume being in range 0...256, I
don't think this will work anyway. volume of 255 of less will cause the
sample to be 0, and 256 the original value.
On Wed, 8 May 2019, m...@netbsd.org wrote:
Is there some scenario where this made a difference?
it sou
Is there some scenario where this made a difference?
it sounds like an optimization that a compiler should already do
5234:#if defined(AUDIO_USE_C_IMPLEMENTATION_DEFINED_BEHAVIOR) &&
defined(__GNUC__)
5235- *d++ += ((aint2_t)*s++) * track->volume >> 8;
5236-#else
5237-
19 matches
Mail list logo
