On Mon, Jan 02, 2006 at 01:24:59PM -0800, Bill Unruh wrote:
> >Even PLLs are often implemented using a VCXO (voltage controlled
> >xtal oscillator). You get the stability of the external reference,
> >and outside the loop bandwidth, the quality of an xtal. Standard
> >practice in all sorts of tele
Sure,
the bigger is the Q factor of an oscillator, the less tunable it is.
Its tunability depends also on the resonance mode number, actual
material, the way it was cut and G-d knows what else.
Look at the following analogy:
you have, say, parallel LC loop with VERY stable L and C.
Then you ar
On Mon, 2 Jan 2006, fons adriaensen wrote:
On Mon, Jan 02, 2006 at 06:09:17PM +0200, Sergei Steshenko wrote:
In other words, tunable xtal is a bad xtal by definition.
There are no such things as 'tunable' and 'untunable' xtals.
*Every* xtal behaves has a parallel or series LC circuit near
re
On Mon, Jan 02, 2006 at 06:09:17PM +0200, Sergei Steshenko wrote:
> In other words, tunable xtal is a bad xtal by definition.
There are no such things as 'tunable' and 'untunable' xtals.
*Every* xtal behaves has a parallel or series LC circuit near
resonance (depending on how it's used) and can b
"
Even X-tal oscillators
can be tuned over a small range by a voltage controlled capacitor.
"
one should remember that tunability is the opposite of stability/low jitter.
If we are talking about synchronization, master clock should be as stable as
possible (i.e. xtal, and no caps), and slave cloc
On Mon, Jan 02, 2006 at 03:14:14PM +0100, Asbjørn Sæbø wrote:
> What I really would like is a sound card with adjustable sampling
> frequency. That is, small scale tunable on an almost continous scale.
> Practiaclly, I think that one possible way to do it would be to use a
> temperature sensiti
To better measure actual drift one has to use really good LPF, which
means they have a pretty big delay.
So, it doesn't make sense to use a very good sample rate conversion
because we learn bout the drift well AFTER it occurs.
Good sample rate conversion makes sense only if clock frequencies
of t
On Fri, Dec 30, 2005 at 05:36:28PM -0500, Ross Vandegrift wrote:
> [...]
> Say I have two sound cards in my box. Each sound card has an
> independent crystal that generates a clock for timekeeping. The
> crystals are rated to resonate at some fixed frequency, but there will
> always be a margain
On Fri, Dec 30, 2005 at 11:47:41PM -0500, Ross Vandegrift wrote:
> On Fri, Dec 30, 2005 at 05:42:32PM -0500, Lee Revell wrote:
> > LDAS (the low delay audio streamer) does something similar - it has to
> > compensate for the drift between two machines clocks' that exchange
> > audio over the networ
It doesn't matter actually.
If read pointers of the sound cards are accessible, then one of the
soundcards can be considered as the reference one and "absolute"
time can be measured as
(buffer_size * number_of_fully_read_buffers) + read_pointer
- I mean, read_pointer has the range of 0..buffer_s
As I understand it, the new HPET timers are sufficiently different from the
old RTC chips, that the RTC timer has gotten screwed up in the transition.
Ie, you could use the new hpet fuctionality and it would work well.
Unfortunately no software does. It uses the old RTC interface, and that as
I un
On Sat, 2005-12-31 at 12:36 -0800, Bill Unruh wrote:
> But the problem is getting those ticks out. In particular, with the
> new timer chips on the newer chipsets, rtc works by polling, which is
> notoriously bad at accurate timing. Even with interrupts, you cannot
> have them too often or your co
On Sat, 31 Dec 2005, Ross Vandegrift wrote:
On Sat, Dec 31, 2005 at 02:11:19PM +0200, Sergei Steshenko wrote:
- I have already suggested to measure average interrupt request frequency.
If a card is playing N samples buffer with actual sampling frequency Fs, then
time between interrupts per buf
As a second thought regarding calibration - if we temporarily cross-connect
analog outputs and inputs of two cards, we can measure their relative
clock frequencies much more directly and precisely - no random factor.
But I agree, the best way is an HW solution, possibly removing
xtals/disabling cl
Technology has known calibration for quite a long time, so the cards
(the sampling rate correction code rather) can be precalibrated.
That is. before real palyback certain numbers of junk (zero filled ?)
can be player in order to measure sampling frequency difference.
Now, even in real time of rea
On Sat, Dec 31, 2005 at 02:11:19PM +0200, Sergei Steshenko wrote:
> - I have already suggested to measure average interrupt request frequency.
>
> If a card is playing N samples buffer with actual sampling frequency Fs, then
> time between interrupts per buffer empty is (N / Fs), i.e. for two card
"
Is there some way to test the cards and measure their frequency? If
so, you could do a pretty full-blown NTP for sound cards and that
would be pretty freakin cool.
"
- I have already suggested to measure average interrupt request frequency.
If a card is playing N samples buffer with actual sam
> Is there some way to test the cards and measure their frequency? If
> so, you could do a pretty full-blown NTP for sound cards and that
> would be pretty freakin cool.
I know when programming the old SoundBlaster 16 cards they would trigger
an interrupt when they switched output buffers (so you
On Fri, Dec 30, 2005 at 05:42:32PM -0500, Lee Revell wrote:
> LDAS (the low delay audio streamer) does something similar - it has to
> compensate for the drift between two machines clocks' that exchange
> audio over the network but you could apply the algorithm to two cards on
> one box. It uses t
For starters, one may start measuring average frequency of interrupt
requests generated by both cards provided both of the play the same
length buffer.
The measure of the average frequency will be the computers RTC.
I am not saying that it is simple, and yes, prior knowledge, like NTP,
should be
On Fri, 2005-12-30 at 17:36 -0500, Ross Vandegrift wrote:
> On Fri, Dec 30, 2005 at 12:45:48PM +1000, Adam Nielsen wrote:
> > I've always wondered about this. Fair enough that two cards would play
> > back sound at slightly different speeds, but why can't you just drop a
> > sample or two every fe
On Fri, Dec 30, 2005 at 12:45:48PM +1000, Adam Nielsen wrote:
> I've always wondered about this. Fair enough that two cards would play
> back sound at slightly different speeds, but why can't you just drop a
> sample or two every few milliseconds or so, to keep the sound roughly in
> sync?
How do
In the telecom industry there is a special term, if I remember correctly, it's
"bit shaving".
The idea is like this: suppose you're on serial (RS232) link with TWO stop bits,
but the frequencies are slightly out of sync.
The protocol is implemented in such a manner, that if the second stop
bit is
> It might be even worse. The cards most likely have independent clock
> generators. In such a case, there will be (slightly) different
> playback speed of left and right channels.
I've always wondered about this. Fair enough that two cards would play
back sound at slightly different speeds, bu
24 matches
Mail list logo
