All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eliot Blennerhassett <linux@audioscience.com>
To: Robert Hancock <hancockrwd@gmail.com>
Cc: alsa-devel@alsa-project.org
Subject: Re: SPDIF/AES input sample rate handling?
Date: Tue, 02 Jun 2009 17:20:13 +1200	[thread overview]
Message-ID: <4A24B68D.8060009@audioscience.com> (raw)
In-Reply-To: <gvqavg$rav$1@ger.gmane.org>

Robert Hancock wrote:
> A question about how ALSA drivers should handle SPDIF or AES digital 
> audio inputs: I may be eventually be writing an ALSA driver for an audio 
> card which has multiple AES digital audio inputs. The card would support 
> multiple sample rates on input with the provided input data being fed 
> directly to software with no sample rate conversion. This raises the 
> question of how to handle requests for a particular sample rate. If the 
> user app requests recording at a sample rate of say 32KHz and we say 
> "OK", and then they proceed to connect an input running at 44.1KHz 
> sampling rate, the card will produce and the app will receive samples at 
> a faster than expected rate. Presumably this is something the app just 
> has to deal with, but will anything in the ALSA core/library puke 
> because of it?

I think it will just run faster.

If you *already* have the 44.1kHz input connected when the app tries to
set up the stream, then your driver can report that it is only capable
of 44.1, and the app or ALSA plug layer will be forced to do resampling.

aside: does it make sense to allow recording at all if there is no valid
input clock?

I'm not sure of the best way to dynamically change such a constraint
when the input changes.

--
Eliot

      reply	other threads:[~2009-06-02  5:20 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-30  3:59 SPDIF/AES input sample rate handling? Robert Hancock
2009-06-02  5:20 ` Eliot Blennerhassett [this message]

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=4A24B68D.8060009@audioscience.com \
    --to=linux@audioscience.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=hancockrwd@gmail.com \
    /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.