Re: audio2

2019-06-04 Thread Tetsuya Isaki
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

Re: audio2

2019-05-29 Thread Andreas Gustafsson
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 :)

Re: audio2

2019-05-28 Thread Valery Ushakov
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

Re: audio2

2019-05-27 Thread Taylor R Campbell
> 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

Re: audio2

2019-05-27 Thread Tetsuya Isaki
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

Re: audio2

2019-05-25 Thread Valery Ushakov
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,

Re: audio2

2019-05-24 Thread Tetsuya Isaki
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

Re: audio2

2019-05-24 Thread 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.

Re: audio2

2019-05-24 Thread maya
we don't have anyone using the non-__GNUC__ case

Re: audio2

2019-05-23 Thread Valery Ushakov
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

Re: audio2

2019-05-23 Thread Tetsuya Isaki
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-

Re: audio2

2019-05-21 Thread Tetsuya Isaki
DCTL_DSP_SETDUPLEX: > idat = 1; > error = ioctlf(fp, AUDIO_SETFD, ); I think there is no problem. In the past, AUDIO_SETFD used to call hw_if->setfd() in the internal but there was no driver which implemented setfd(). That is, it was available but did nothing. In audio2, AUD

Re: audio2

2019-05-21 Thread Jared McNeill
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

Re: audio2

2019-05-21 Thread Tetsuya Isaki
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 *

Re: audio2

2019-05-09 Thread Jared McNeill
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

Re: audio2

2019-05-08 Thread maya
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-

Re: CVS commit: [isaki-audio2] src/sys/dev/usb

2019-05-02 Thread Tetsuya Isaki
At Thu, 02 May 2019 10:46:14 +1000, matthew green wrote: > > Committed By: isaki > > Date: Wed May 1 13:09:34 UTC 2019 > > > > Modified Files: > > src/sys/dev/usb [isaki-audio2]: uaudio.c > > > > Log Message: > > Don't re

re: CVS commit: [isaki-audio2] src/sys/dev/usb

2019-05-01 Thread matthew green
"Tetsuya Isaki" writes: > Module Name: src > Committed By: isaki > Date: Wed May 1 13:09:34 UTC 2019 > > Modified Files: > src/sys/dev/usb [isaki-audio2]: uaudio.c > > Log Message: > Don't release sc_lock and sc_intr_lock in trigger_{