From: Anders Torger <torger@ludd.luth.se>
To: Paul Davis <paul@linuxaudiosystems.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Subject: Re: Re: Digital sound card conventions
Date: Fri, 3 Jan 2003 23:03:50 +0100 [thread overview]
Message-ID: <200301032303.50790.torger@ludd.luth.se> (raw)
In-Reply-To: <200301032139.WAA08066@alsa.alsa-project.org>
On Friday 03 January 2003 22.47, Paul Davis wrote:
> >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.
>
> this seems wrong to me. what should fail is an attempt to set the
> sample rate unless the hardware is its own clock Master. if no
> attempt is made to set it, then the application gets whatever the
> hardware is running at, whether that is externally controlled or some
> h/w specific default.
An attempt to set it to the sample rate that happens be the correct one
should be ok, at least I think so.
So, your suggestion is, that for capture, always state the full hardware
capability (in hwparams), but fail if incorrect the settings are made?
I think that is ok too, but currently I'm narrowing down the hwparams
to fit what is available at the input when the sound card is opened (of
course, that could have changed until the sound card is started, but it
is quite unlikely).
I think both approaches are ok, but narrowing down the alternatives I
think is more nice to the applications. My guess is that the common use
of a digital sound card is that the input signal is not changed too
often, and then it is nice if the software gets the correct
capabilities, so those applications that think that all sound cards are
analog will work in the expected way anyway.
> > Also it will fail, when sample rate is changed during
> >operation.
>
> the hammerfall driver used to contain stubs for doing this. every
> read/write operation would check that the (possibly externally
> controlled) SR was the same as "last time". i never did any more on
> this.
Uhmm... I don't think I will include changed sample rate / format
callback stuff for now, because I don't know how to implement it.
However, if there is a good example which I could imitate, let me know.
/Anders Torger
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
next prev parent reply other threads:[~2003-01-03 22:04 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
2003-01-03 21:47 ` Paul Davis
2003-01-03 22:03 ` Anders Torger [this message]
[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=200301032303.50790.torger@ludd.luth.se \
--to=torger@ludd.luth.se \
--cc=alsa-devel@alsa-project.org \
--cc=paul@linuxaudiosystems.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.