Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Janssen <pe1chl@amsat.org>
To: alsa-devel@alsa-project.org
Subject: Re: Control the exact moment of output
Date: Tue, 29 Apr 2014 10:25:16 +0200	[thread overview]
Message-ID: <535F61EC.9070003@amsat.org> (raw)
In-Reply-To: <535F59DD.2080207@ladisch.de>

Clemens Ladisch wrote:
> Rob Janssen wrote:
>> For a distributed system that requires synchronized output I would like to determine
>> the exact moment when output samples are sent, preferably within +/- 1 sample time.
>>
>> Is this possible within the ALSA API?
> In theory, yes; snd_pcm_delay() should take these latencies into account.
>
> In practice, there is no hardware where this value is accurate.  Drivers with
> large latencies (e.g., USB) report their internal queues, but nobody bothers
> for the small delays (about 10 samples) in the DMA controllers and DACs.
Ok, thanks for the reply!
We will use PCI soundcards, not USB dongles, and it is not a problem when there is a fixed extra delay
that is the same for all the systems.  What we need to control is the synchronization between
the physically separated systems, and my approach up to now is to do this by synchronizing
to the very precise system time derived from GPS.

I was thinking along the line of an API feature where one can send frames with a related moment
of playback, but now I realize that what I should do is calculate how far off the desired playback
moment we are (using the current system time, the desired playback time, and the snd_pcm_delay)
for each block, and then pad or trim some frames as required before sending the block.
Is that correct?

>
>> And are there soundcards available where the sample clock can somehow be
>> locked to system time or an external 10MHz/1PPS reference?
> Some cards can be locked to an S/PDIF input or to a word clock from another
> sound card.  This does not work for physically separated outputs; you'd have
> to measure the clock differences and do dynamic resampling.
>
We would have to generate a word clock or S/PDIF signal from the 10MHz/1PPS we have available
from the GPS (which are synchronous on all the sites).   That will be the next step when the first
approximation does not yield us enough perfection.

Rob

  reply	other threads:[~2014-04-29  8:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-19 18:21 Control the exact moment of output Rob Janssen
2014-04-29  7:50 ` Clemens Ladisch
2014-04-29  8:25   ` Rob Janssen [this message]
2014-04-30  6:43     ` Patrick Shirkey
2014-04-30  8:11       ` Rob Janssen

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=535F61EC.9070003@amsat.org \
    --to=pe1chl@amsat.org \
    --cc=alsa-devel@alsa-project.org \
    /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