Why is Sample Rate sometimes double and sometimes integer?

4 Messages

Richard Ash (audacity-help)

Reply Threaded

I'm looking at the code of WaveTrack.cpp. WaveTrack.mRate is declared to
be int. So why are it's access functions double? I know floating point
sample rates are possible and even valid, but currently we silently
round them whilst pretending we know what to do with them. This doesn't
seem a good idea.

double WaveTrack::GetRate() const
{
return mRate;
}

void WaveTrack::SetRate(double newRate)
{
mRate = (int) newRate;
for (WaveClipList::Node* it=GetClipIterator(); it; it=it->GetNext())
it->GetData()->SetRate((int) newRate);
}

Should I be changing to use doubles throughout or integers? My instinct
says integers because it avoids round errors, and I've never yet needed
fractional sample rates, but we could use doubles. Could even have our
own typedef for Audacity_SampleRate_t and use that ...

Richard

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Audacity-devel mailing list
Audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Martyn Shaw-2

Re: Why is Sample Rate sometimes double and sometimes integer?

Reply Threaded

Richard

I've never seem a non-integer rate, so I'd be happy if you set them
all to integer.

Martyn

Richard Ash wrote:

> I'm looking at the code of WaveTrack.cpp. WaveTrack.mRate is declared to
> be int. So why are it's access functions double? I know floating point
> sample rates are possible and even valid, but currently we silently
> round them whilst pretending we know what to do with them. This doesn't
> seem a good idea.
>
> double WaveTrack::GetRate() const
> {
> return mRate;
> }
>
> void WaveTrack::SetRate(double newRate)
> {
> mRate = (int) newRate;
> for (WaveClipList::Node* it=GetClipIterator(); it; it=it->GetNext())
> it->GetData()->SetRate((int) newRate);
> }
>
> Should I be changing to use doubles throughout or integers? My instinct
> says integers because it avoids round errors, and I've never yet needed
> fractional sample rates, but we could use doubles. Could even have our
> own typedef for Audacity_SampleRate_t and use that ...
>
> Richard
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Audacity-devel mailing list
> Audacity-devel@...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
audacity-devel mailing list
audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Jan Kolar

Re: Why is Sample Rate sometimes double and sometimes integer?

Reply Threaded

Thinking about it second time,
I would vote to make it double - just not to close a door to some
applications.
I can think of two or three cases one could appreciate non-integral
sample rate (if fully supported)

1. very slow sample rates if ever "wave" track would be used to
*control* an effect
Slow sample rate "sounds" are used in nyquist this way
(and Audacity uses envelope to control "mix-effect" now in the same
spirit).
(Is the standard midi rate an int?)
2. *Synchronization* of records from two or more sound devices
(integers are not really enough: 44100 versus 44101 is off by 100ms
after 441s= 7minutes21seconds)
3. *Technical signals*: best to edit at natural rate even if recorded
(and silently played) at higher project rate.

BTW, I tried to check and if I am correct (and gdb's double here is a
usual one),
the difference between 44100 and its double representation should not
make one sample error until after about 400 hours.
(This is so-so, we should not switch often between ints and doubles
unless we want to crash with 10 hours export.
And, is FPU arithmetics so much reliable ? )

If done with typedef for Audacity_SampleRate_t,
and SAMPLERATE_TO_LLLLINT, SAMPLERATE_TO_DOUBLE and reverse macros (unfortunately more typing everywhere)
a change of typedef could help with testing and debugging.
Behaviour simply should not change with typedef change (until 400 hours etc.)

Jan

Martyn Shaw napsal(a):

> Richard
>
> I've never seem a non-integer rate, so I'd be happy if you set them
> all to integer.
>
> Martyn
>
> Richard Ash wrote:
>
>> I'm looking at the code of WaveTrack.cpp. WaveTrack.mRate is declared to
>> be int. So why are it's access functions double? I know floating point
>> sample rates are possible and even valid, but currently we silently
>> round them whilst pretending we know what to do with them. This doesn't
>> seem a good idea.
>>
>> double WaveTrack::GetRate() const
>> {
>> return mRate;
>> }
>>
>> void WaveTrack::SetRate(double newRate)
>> {
>> mRate = (int) newRate;
>> for (WaveClipList::Node* it=GetClipIterator(); it; it=it->GetNext())
>> it->GetData()->SetRate((int) newRate);
>> }
>>
>> Should I be changing to use doubles throughout or integers? My instinct
>> says integers because it avoids round errors,

In case the resampling code computes ratio, it should be casted to
doubles in that point etc.

>> and I've never yet needed
>> fractional sample rates, but we could use doubles. Could even have our
>> own typedef for Audacity_SampleRate_t and use that ...
>>
>> Richard
>>
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> Audacity-devel mailing list
>> Audacity-devel@...
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> audacity-devel mailing list
> audacity-devel@...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

Richard Ash (audacity-help)

Re: Why is Sample Rate sometimes double and sometimes integer?

Reply Threaded

On Mon, 2008-07-07 at 23:59 +0200, Jan Kolar wrote:

> Thinking about it second time,
> I would vote to make it double - just not to close a door to some
> applications.
> I can think of two or three cases one could appreciate non-integral
> sample rate (if fully supported)
>
> 1. very slow sample rates if ever "wave" track would be used to
> *control* an effect
> Slow sample rate "sounds" are used in nyquist this way
> (and Audacity uses envelope to control "mix-effect" now in the same
> spirit).
> (Is the standard midi rate an int?)
> 2. *Synchronization* of records from two or more sound devices
> (integers are not really enough: 44100 versus 44101 is off by 100ms
> after 441s= 7minutes21seconds)
> 3. *Technical signals*: best to edit at natural rate even if recorded
> (and silently played) at higher project rate.

Valid ideas - I think the most critical ones are likely to be 1 and 3.
>
> BTW, I tried to check and if I am correct (and gdb's double here is a
> usual one),
> the difference between 44100 and its double representation should not
> make one sample error until after about 400 hours.
That sounds promising, and helps with one of the things that was
worrying me. In many places we end up calculating the number of samples
from the duration and the rate, or other combinations (a WaveClip knows
it's rate and it's duration, it seems)

> (This is so-so, we should not switch often between ints and doubles
> unless we want to crash with 10 hours export.
> And, is FPU arithmetics so much reliable ? )
Integer multiplication should be both quicker and more stable than
floating point instructions, because they are always done on the main
CPU, not with (hard/soft/simd) FPUs with variable accuracy (80-bit mmx,
etc).

> If done with typedef for Audacity_SampleRate_t,
> and SAMPLERATE_TO_LLLLINT, SAMPLERATE_TO_DOUBLE and reverse macros
> (unfortunately more typing everywhere)
> a change of typedef could help with testing and debugging.
> Behaviour simply should not change with typedef change (until 400 hours etc.)

Hadn't thought of that. I was thinking about simply declaring variables
holding rates to be of type Audacity_SampleRate_t, so that the data type
change propagates through the program. I'm not sure either is a good
idea however, because it makes testing harder (and we already have a
very big possible test matrix). In other words, I don't think your
proposed test facility would get used, and it would mean more work. If
we can write a test case that illustrates the 400 hours limit it would
be a good start!

Unless anyone else chips in I'll see about shifting to all doubles for
sample rate (so we do the minimum number of conversions of the value).

Richard

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
audacity-devel mailing list
audacity-devel@...
https://lists.sourceforge.net/lists/listinfo/audacity-devel