All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anders Torger <torger@ludd.luth.se>
To: Jaroslav Kysela <perex@suse.cz>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Subject: Re: Re: Digital sound card conventions
Date: Fri, 3 Jan 2003 22:27:47 +0100	[thread overview]
Message-ID: <200301032227.47848.torger@ludd.luth.se> (raw)
In-Reply-To: <Pine.LNX.4.33.0301032118550.500-100000@pnote.perex-int.cz>

On Friday 03 January 2003 21.33, Jaroslav Kysela wrote:
> On Fri, 3 Jan 2003, Anders Torger wrote:
> > I'm doing a maintenance update on the rme96 driver, and I wonder if
> > there are any conventions to follow in the driver concerning
> > digital sound cards.
> >
> > The specific questions are how to handle sample rates and sound
> > formats on the input.
> >
> > The sound card supports several sample rates and formats. What
> > should happen if the user tries to open the input with 48000 kHz
> > ADAT, but the format is actually 44100 kHz and SPDIF? I can allow
> > it if I want to, the user will get data, but at 48000 kHz of
> > course.
> >
> > What should happen when there is no input signal at all? The
> > hardware supports opening the input, but should I do so in the
> > driver?
> >
> > The signal can of course change in runtime as well...
> >
> > I'm thinking of allowing it all, but I don't know if that is the
> > right way to go.
>
> This part of PCM API has not been discussed. I think that we should
> follow the most easy way: It is - allow only sample rate given by
> application, if the master clock is using another sample rate - in
> trigger() callback - driver will fail. Also it will fail, when sample
> rate is changed during operation. We probably need to add a new PCM
> state -
> SNDRV_PCM_STATE_STREAM_CHANGED (equal to DRAINING, but informative
> for applications). The notification of master clock / sample rate (or
> other parameter) changes should be implemented using the control API.

So what you are saying is, for now, do what is correct at the moment. Is 
this ok:

If no signal on the input - allow to open with any setting the hardware 
supports. The current rme96 driver will return -EIO, but that sucks if 
you're just opening the card to check some parameters, so I plan to 
change that.

If there is a signal on the input, limit the reported sound card 
capabilities to only those currently available on the input, so when 
the sound card is opened for capture, it seems only capable of 48kHz if 
that is the current sample rate.

/Anders Torger


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

  reply	other threads:[~2003-01-03 21:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-03 19:44 Digital sound card conventions Anders Torger
2003-01-03 20:33 ` Jaroslav Kysela
2003-01-03 21:27   ` Anders Torger [this message]
2003-01-03 21:47   ` Paul Davis
2003-01-03 22:03     ` Anders Torger
     [not found] <20030103213948.169F659D307@kerberos.suse.cz>
2003-01-05 14:44 ` Jaroslav Kysela
2003-01-06 16:28   ` Paul Davis
2003-01-06 17:21     ` Jaroslav Kysela
2003-01-07 15:53     ` Takashi Iwai

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=200301032227.47848.torger@ludd.luth.se \
    --to=torger@ludd.luth.se \
    --cc=alsa-devel@alsa-project.org \
    --cc=perex@suse.cz \
    /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.