Le 2011-11-17 à 15:18:00, Roman Haefeli a écrit :
Matju directed me to the respective parts in the source code, but I was not able to make any sense out of it.
I said something wrong near the end because I spoke too quick. sched_tick is not a main loop, it's the common part between the big mainloop (ordinary mode), the short mainloop (-batch) and the big callback (-schedlib).
The top of that file defines :
#define TIMEUNITPERSEC (32.*441000.)
which is used by users of sched_tick.
That's 14112000 or pow(2,8)*pow(3,2)*pow(5,3)*pow(7,2).
44100 is pow(2,2)*pow(3,2)*pow(5,2)*pow(7,2).
48000 is pow(2,7)*pow(3,1)*pow(5,0)*pow(7,0).
Miller's idea was to have a fixed unit in which samples of both a 44100 Hz and a 48000 Hz stream correspond to whole numbers in that scale.
the lcm (aka ppcm or least common denominator) of 44100 and 48000 is half of TIMEUNITPERSEC. The last doubling is to also support doubled sampling rates like 88200 and 96000, even though people don't have the corresponding set of ears.
I split TIMEUNITPERSEC in prime factors because that's a good way to see common denominators. The other way is Euclid's method.
I doubt that the choice of TIMEUNITPERSEC makes that much of a practical difference though... unless the intent is to prevent drifting of the clock, but even careless counting is already lots more precise than some soundcards for which the sampling rate is just a suggestion...
In my first Pd years, I had a soundcard running at 44098 Hz on one of my computers.
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC