All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Knecht <markknecht@attbi.com>
To: Paul Davis <paul@linuxaudiosystems.com>
Cc: patrick reardon <swpatrick@earthlink.net>,
	Alsa-Devel <alsa-devel@lists.sourceforge.net>
Subject: Re: possible problems with rc6 aplay
Date: 15 Dec 2002 20:38:54 -0800	[thread overview]
Message-ID: <1040013536.2187.4.camel@Godzilla> (raw)
In-Reply-To: <E18NleD-0004xk-00@sc8-sf-list1.sourceforge.net>

Paul,
   I'm using two Hammerfalls in separate boxes. Please try to come up
with a solution, either automatically or by asking questions in some
configuration process, that allows two Linux boxes to choose which to
make the master. It is important in my case.

Thanks,
Mark

On Sun, 2002-12-15 at 19:13, Paul Davis wrote:
> >Latency: 4096 samples (2 periods of 16384 bytes)
> >Hardware pointer (frames): 0
> >Passthru: no
> >Clock mode: autosync
> >Pref. sync source: ADAT1
> >
> >IEC958 input: Coaxial
> >IEC958 output: Coaxial only
> >IEC958 quality: Consumer
> >IEC958 emphasis: off
> >IEC958 Dolby: off
> >IEC958 sample rate: error flag set
> >
> >ADAT Sample rate: 44100Hz
> 
> if you're hammerfall is configured as shown above (and no, the name
> change makes no difference), then the SR that it uses will be
> determined by your external converter connected to the first ADAT
> port. nothing that ALSA does (or any program using ALSA does) will
> alter the SR. thats because you are synced to ADAT1, not the card's
> internal clock, thus the SR is determined by the clock signal arriving
> at ADAT1, which presumably comes from a converter somewhere back up
> the ADAT chain.
> 
> its been on my to-do list for some time to make "master" the default
> clock mode on the hammerfall, which avoids any ambiguity about the
> sample rate used by the card. i've held back because its really not
> the right option for most studio-ish users, who have external
> converters that probably have rate switches on them and they expect
> the hammerfall to follow the switch setting.
> 
> does any of this make it any clearer? its really a bit of problem that
> the rate setting code doesn't do a full 100% check on all this
> stuff. an app can set the rate to 44100, and appear to have succeeded,
> but it will have no difference on the actual rate if the sync source
> is not the clock's internal clock. this is true, btw, for most digital
> cards. if you tried to record at 44100, but your external converters
> were running at 48kHz (as you suggest they have been), then the
> recordings will be at 48kHz with the sync source set as shown above.
> 
> --p
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility 
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel




-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

  reply	other threads:[~2002-12-16  4:38 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-15 21:59 possible problems with rc6 aplay patrick reardon
2002-12-15 22:15 ` Mark Knecht
2002-12-16  3:13 ` Paul Davis
2002-12-16  4:38   ` Mark Knecht [this message]
2002-12-16 10:17     ` Martin Langer
2002-12-16 12:04       ` Mark Knecht
2002-12-16 13:49         ` Paul Davis
2002-12-16 13:57           ` Takashi Iwai
2002-12-16 14:29             ` Paul Davis
2002-12-16 14:53               ` alsasound init script (Re: possible problems with rc6 aplay ) Takashi Iwai
2002-12-16 15:23                 ` Paul Davis
2002-12-16 14:36         ` possible problems with rc6 aplay Martin Langer
2002-12-16 14:51           ` Paul Davis
     [not found]           ` <20021216144807.8950gmx1@mx005-rz3.gmx.net>
2002-12-17 17:54             ` clock mode problem [was: possible problems with rc6 aplay] Martin Langer
     [not found] <20021216134609.VYJW9197.sccrgwc02.attbi.com@newmx2.fast.net>
2002-12-16 21:20 ` possible problems with rc6 aplay Mark Knecht
     [not found] <200212151910.18nLEb5ck3NZFjX0@robin>
2002-12-16 22:53 ` patrick reardon
2002-12-17  1:44   ` Mark Knecht
2002-12-17  2:48   ` Paul Davis
     [not found] <200212161844.18o7IP2Gs3NZFjV0@sparrow.mail.pas.earthlink.net>
2002-12-17 17:08 ` patrick reardon

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=1040013536.2187.4.camel@Godzilla \
    --to=markknecht@attbi.com \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=paul@linuxaudiosystems.com \
    --cc=swpatrick@earthlink.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.