Menu
▾
▴
linuxsampler-devel
|
From: Vladimir S. <ha...@so...> - 2004-05-27 12:21:51
|
Hi guys, I've checked out the latest from the CVS last night and i can only hear the left channel. It seems to sound OK, but nothing in the right ear at all. I have older version it sill sounds OK so this is not my hardware/drivers/etc. Anything i'm doing wrong? I could finish troubleshooting as it was getting late and i was going to get in trouble :) Perhaps something in voice.h? Regards, Vladimir. |
|
From: Christian S. <chr...@ep...> - 2004-05-27 15:41:29
|
Es geschah am Donnerstag, 27. Mai 2004 14:21 als Vladimir Senkov schrieb: > Hi guys, > > I've checked out the latest from the CVS last night and i can only hear > the left channel. Confirmed, same accounts to me. Not sure yet what the problem is. If your time allows it, maybe you try older versions to check when this problem was introduced. CU Christian |
|
From: <be...@ga...> - 2004-05-27 21:08:34
|
The offending code (probably due to a cut'n paste error) is in line 199 of Voice.h pOutputLeft[i++] += this->FilterRight.Apply(&bq_base, &bq_main, effective_volume * ((((a * pos_fract) + b) * pos_fract + c) * pos_fract + x0)); It should be pOutputRight[i++] += .... Stephane spotted this problem and told me about it on IRC, he said tried a patch that speeds up things a bit (reading pSrc[0]..pSrc[7] in one rush in variables and then use these variable for the stereo cubic interpolator. He said on PPC its faster. Perhaps it makes sense to commit it ? Christian ? (I sent a copy of the diff to Christian). cheers, Benno http://www.linuxsampler.org Scrive Vladimir Senkov <ha...@so...>: > Hi guys, > > I've checked out the latest from the CVS last night and i can only hear > the left channel. > It seems to sound OK, but nothing in the right ear at all. I have older > version it sill sounds OK so this is not my hardware/drivers/etc. > Anything i'm doing wrong? > I could finish troubleshooting as it was getting late and i was going to > get in trouble :) > Perhaps something in voice.h? > > Regards, > Vladimir. > > ------------------------------------------------- This mail sent through http://www.gardena.net |
|
From: <le...@rd...> - 2004-05-27 21:37:07
|
On 27 mai 04, at 23:08, be...@ga... wrote: > The offending code (probably due to a cut'n paste error) > is in line 199 of Voice.h > > pOutputLeft[i++] += this->FilterRight.Apply(&bq_base, &bq_main, > effective_volume * ((((a * pos_fract) + b) * pos_fract + c) * > pos_fract + x0)); > > It should be > pOutputRight[i++] += .... > > Stephane spotted this problem and told me about it on IRC, he said > tried a patch that speeds up things a bit > (reading pSrc[0]..pSrc[7] in one rush in variables and then > use these variable for the stereo cubic interpolator. > He said on PPC its faster. > > Perhaps it makes sense to commit it ? Christian ? > (I sent a copy of the diff to Christian). What really speedup is the use of float instead of double (3.0f instead of 3.0 and so on..) *if* computing in double is not required of course. But this must be tested on X86 before committing. I 'm not sure the other things really matter (reading in local variable ...) Stephane |
|
From: Christian S. <chr...@ep...> - 2004-05-28 13:30:05
|
Es geschah am Donnerstag, 27. Mai 2004 23:36 als St=E9phane LETZ schrieb:
> On 27 mai 04, at 23:08, be...@ga... wrote:
> > The offending code (probably due to a cut'n paste error)
> > is in line 199 of Voice.h
> >
> > pOutputLeft[i++] +=3D this->FilterRight.Apply(&bq_base, &bq_main,
> > effective_volume * ((((a * pos_fract) + b) * pos_fract + c) *
> > pos_fract + x0));
> >
> > It should be
> > pOutputRight[i++] +=3D ....
> >
> > Stephane spotted this problem and told me about it on IRC, he said
> > tried a patch that speeds up things a bit
> > (reading pSrc[0]..pSrc[7] in one rush in variables and then
> > use these variable for the stereo cubic interpolator.
> > He said on PPC its faster.
> >
> > Perhaps it makes sense to commit it ? Christian ?
> > (I sent a copy of the diff to Christian).
>
> What really speedup is the use of float instead of double (3.0f instead
> of 3.0 and so on..) *if* computing in double is not required of course.
> But this must be tested on X86 before committing.
What do you mean with "if" computing?
The patch looks ok, except:
inline void InterpolateOneStep_Mono(sample_t* pSrc, int& i,
[snip]
=2D float a =3D (3 * (x0 - x1) - xm1 + x2) / 2;
=2D float b =3D 2 * x1 + xm1 - (5 * x0 + x2) / 2;
=2D float c =3D (x1 - xm1) / 2;
+ float a =3D (3.0 * (x0 - x1) - xm1 + x2) * 0.5f;
+ float b =3D 2.0 * x1 + xm1 - (5.0 * x0 + x2) * 0.5f;
+ float c =3D (x1 - xm1) * 0.5f;
Intended? Why not:
+ float a =3D (3.0f * (x0 - x1) - xm1 + x2) * 0.5f;
+ float b =3D 2.0f * x1 + xm1 - (5.0f * x0 + x2) * 0.5=
f;
+ float c =3D (x1 - xm1) * 0.5f;
And the patch works of course for x86 and also fixes the 'only left channel=
'=20
bug.
CU
Christian
|
|
From: <le...@gr...> - 2004-05-28 13:37:55
|
Le 28 mai 04, =E0 15:28, Christian Schoenebeck a =E9crit : > Es geschah am Donnerstag, 27. Mai 2004 23:36 als St=E9phane LETZ = schrieb: >> On 27 mai 04, at 23:08, be...@ga... wrote: >>> The offending code (probably due to a cut'n paste error) >>> is in line 199 of Voice.h >>> >>> pOutputLeft[i++] +=3D this->FilterRight.Apply(&bq_base, &bq_main, >>> effective_volume * ((((a * pos_fract) + b) * pos_fract + c) * >>> pos_fract + x0)); >>> >>> It should be >>> pOutputRight[i++] +=3D .... >>> >>> Stephane spotted this problem and told me about it on IRC, he said >>> tried a patch that speeds up things a bit >>> (reading pSrc[0]..pSrc[7] in one rush in variables and then >>> use these variable for the stereo cubic interpolator. >>> He said on PPC its faster. >>> >>> Perhaps it makes sense to commit it ? Christian ? >>> (I sent a copy of the diff to Christian). >> >> What really speedup is the use of float instead of double (3.0f=20 >> instead >> of 3.0 and so on..) *if* computing in double is not required of=20 >> course. >> But this must be tested on X86 before committing. > > What do you mean with "if" computing? Using the 3 instead of explicit 3.0f cause float to double conversion=20= everywhere and consume some CPU. If double precision is not required,=20 then using float explicitely is better. > > The patch looks ok, except: > > inline void InterpolateOneStep_Mono(sample_t* pSrc, int&=20= > i, > [snip] > - float a =3D (3 * (x0 - x1) - xm1 + x2) / 2; > - float b =3D 2 * x1 + xm1 - (5 * x0 + x2) / 2; > - float c =3D (x1 - xm1) / 2; > + float a =3D (3.0 * (x0 - x1) - xm1 + x2) * = 0.5f; > + float b =3D 2.0 * x1 + xm1 - (5.0 * x0 + x2) *=20= > 0.5f; > + float c =3D (x1 - xm1) * 0.5f; > > Intended? Why not: > > + float a =3D (3.0f * (x0 - x1) - xm1 + x2) * = 0.5f; > + float b =3D 2.0f * x1 + xm1 - (5.0f * x0 + x2) = *=20 > 0.5f; > + float c =3D (x1 - xm1) * 0.5f; > A mistake.. Yes 2.0f instead of 2.0. > And the patch works of course for x86 and also fixes the 'only left=20 > channel' > bug. > > CU > Christian Stephane |
Thanks for helping keep SourceForge clean.
X