Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: John Rigg <aldev@sound-man.co.uk>
To: Ludovico Verducci <ludwigvan@alice.it>
Cc: alsa-devel@alsa-project.org
Subject: Re: Enabling in-kernel synch for M-Audio boards
Date: Tue, 18 Sep 2007 11:40:33 +0100	[thread overview]
Message-ID: <20070918104033.GA2491@localhost> (raw)
In-Reply-To: <46EF8729.3080901@alice.it>

On Tue, Sep 18, 2007 at 10:07:05AM +0200, Ludovico Verducci wrote:
> John Rigg ha scritto:
> > On Mon, Sep 17, 2007 at 08:44:03PM +0100, John Rigg wrote:
> >   
> >> On Mon, Sep 17, 2007 at 12:22:19PM +0200, Ludovico Verducci wrote:
> >>> I'm developing a complex multichannel audio distribution system where 
> >>> multiple linux boxes will stream audio data over ethernet and then 
> >>> should play audio at sample level resolution synchronization. The boxes 
> >>> clocks are synchronized over ethernet using PTP. 
> >>> I need to keep in synch the audio board's clocks and I can't use an 
> >>> external wordclock nor s/pdif. 
> >>>       
> >> Won't this cause serious clock jitter problems? I don't see how the
> >> PCI bus can deliver precise enough timing, considering how much other
> >> data it has to handle.
> >>     
> I didn't mean to directly drive the audio board's clock over the PCI
> bus. I think this is simply not feasible. But I think that using control
> signals periodically exchanged over PCI between the audio board and the
> kernel could be possible (if the hardware could support a similar
> feature, of course) to skew the board's clock to keep it in synch with a
> software reference.

Ah, I misunderstood what you meant.

> As far as I know the delta family boards drivers support the
> synchronization of up to 4 audio boards over PCI: at the moment I'm
> reverse engineering the hardware trying to understand how this can be
> accomplished.

I'm aware that some Windows users are using several Delta 1010s
without external sync, but I'm not sure how it is done (or how
good it sounds). AFAIK it would require a VCXO so that the frequency 
of the card's clock could be varied by enough to keep it in sync 
(ie. making the clock oscillator part of a phase locked loop). Looking
at the PCI card on the 1010, I can only see standard fixed-frequency 
crystals. The only PLLs appear to be the internal PLL in the S/PDIF
receiver and the 4046 PLL chip for the word clock input signal.

John

  reply	other threads:[~2007-09-18 10:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-17 10:22 Enabling in-kernel synch for M-Audio boards Ludovico Verducci
2007-09-17 19:44 ` John Rigg
2007-09-18  6:57   ` John Rigg
2007-09-18  8:07     ` Ludovico Verducci
2007-09-18 10:40       ` John Rigg [this message]
2007-09-18 13:50         ` Clemens Ladisch
2007-09-18 18:07           ` Ludovico Verducci
2007-09-18 22:16           ` John Rigg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070918104033.GA2491@localhost \
    --to=aldev@sound-man.co.uk \
    --cc=alsa-devel@alsa-project.org \
    --cc=ludwigvan@alice.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox