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 network but
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 of
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
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 sensitive
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
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
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
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
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 telecomm
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 cards
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
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
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
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
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
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
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 few
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
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
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, but
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
21 matches
Mail list logo
