Subject: Re: [ecasound] 2.2 problem
From: William Goldsmith (bill_AT_radioparadise.com)
Date: Tue Feb 18 2003 - 02:37:54 EET
OK - dumb question. I rarely use CVS, but most other packages include a
'configure' script & are compiled with the usual configure, make, make
install.
There's no configure script in my ecasound-cvs dir, and using the one that
came w/ the tarball produces a zero-length Makefile.
thanks
-bg
----- Original Message -----
From: "Kai Vehmanen" <kai.vehmanen_AT_wakkanet.fi>
To: <ecasound-list_AT_wakkanet.fi>
Sent: Sunday, February 16, 2003 6:31 AM
Subject: Re: [ecasound] 2.2 problem
> On Sat, 15 Feb 2003, William Goldsmith wrote:
>
> > OK - I tracked it down. fades (both directions) on v2.2.1 break with
> > durations of < 1 sec. Those work fine on v1.9
>
> Now this was a very interesting problem. The sampling rate is one very
> problematic variable for large audio applications like ecasound. It is
> needed in all kinds of places (it's needed to calculate audio position and
> lenght, filter coefficients, delay lines, opening audio devices, audio
> files, etc, etc), but on the other hand no valid value is available at all
> times.
>
> In ecasound 2.0 (and older) I used a default of 44100. This worked quite
> well, but if there actually were any bugs related to sampling rate
> changes, they were difficult to find (filter frequency response slightly
> wrong if srate was different from 44100, loops wrong in ewf files if
> srate!=44100, delay length errors, etc, etc -> very hard to track down).
>
> In ecasound 2.1/2.2 I decided to finally attack these bugs and set the
> default to -1. Now this turned out to be an excellent way to flush out the
> various small bugs still present. If some components didn't correctly
> handle the -1->valid change, it would fail horribly (and there were quite
> a few of these).
>
> Now back to our current problem. It seems that although ecasound can now
> handle the -1->44100 conversions (i.e. the change is correctly propagated
> to all objects and subsystems that depend on srate), we lose in precision.
> I've now changed the default from -1 to 384000 (8*48kHz). This solves the
> precision problem, while still allows for somewhat easier bug hunting
> (i.e. scaling error in filters/audio-position calculations will usually be
> large as srates higher than 192kHz are not used anywhere at the moment -
> and considering the physical limitations of our hearing, this situations
> is not likely to change anytime soon).
>
> Anyway, Bill, big thanks for tracking this down! This change might also
> fix some other subtle bugs that are triggered by certain specific
> parameter values.
>
> PS I've put the fix to CVS.
>
> --
> http://www.eca.cx
> Audio software for Linux!
>
> --
> To unsubscribe send message 'unsubscribe' in the body of the
> message to <ecasound-list-request_AT_wakkanet.fi>.
This archive was generated by hypermail 2b28 : Tue Feb 18 2003 - 02:29:46 EET