All of lore.kernel.org
 help / color / mirror / Atom feed
From: Clemens Ladisch <clemens@ladisch.de>
To: Uli Franke <uli.franke@weiss.ch>
Cc: Daniel Weiss <weiss@weiss.ch>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	Rolf Anderegg <Rolf.Anderegg@weiss.ch>
Subject: Re: Constraints and hw_params with highly configurable HW
Date: Thu, 05 Sep 2013 10:47:03 +0200	[thread overview]
Message-ID: <52284507.5000004@ladisch.de> (raw)
In-Reply-To: <52270071.9030500@weiss.ch>

Uli Franke wrote:
>> Then the constraints should be read from the device in the PCM open
>> callback.
>
> No, that's not possible as the constraints will/can change in case you
> request a different sample rate for instance. Therefore the constraints
> won't be known until you set the rate for instance.

The PCM constraints can represent arbitrary dependencies between the
parameters, as long as they are known to the driver.

For example, one dependency (already handled by the ALSA framework) is
between buffer size (length in frames) (A), buffer time (length in
seconds) (B), and sample rate (C), with A = B * C.  If any of these
parameters changes, the allowed range of the other two is adjusted.
For example, if a device allows sample rates between 48 kHz and 96 kHz
(but none has yet been chosen), and if the buffer time is set to 0.5 s,
then the interval for the buffer length is set to 24000...48000 frames.

My dice driver assumes that the number of channels depends only on the
sample rate (and that only 48/96/192 kHz matter).  The function
dice_rate_constraint() is called when the number of channels in the
snd_pcm_hw_params structure changes, and adjusts the allowed sample
rates accordingly; the function dice_channels_constraint() is called
when the sample rate changes, and adjusts the allowed number of channels
accordingly.

> And you will never be able to pre-fetch this information reliably as
> the DICE firmware is allowed to change its setup arbitrarily.

A generic DICE driver does not know what some arbitrary firmwares does,
but for Weiss devices, you know the rules, don't you?


Regards,
Clemens

      reply	other threads:[~2013-09-05  8:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-03 15:45 Constraints and hw_params with highly configurable HW Uli Franke
2013-09-03 17:58 ` Clemens Ladisch
2013-09-04  9:42   ` Uli Franke
2013-09-05  8:47     ` Clemens Ladisch [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=52284507.5000004@ladisch.de \
    --to=clemens@ladisch.de \
    --cc=Rolf.Anderegg@weiss.ch \
    --cc=alsa-devel@alsa-project.org \
    --cc=uli.franke@weiss.ch \
    --cc=weiss@weiss.ch \
    /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.