How can I make sure the period size is a multiple of 16?

[Timur Tabi]

To work around a hardware issue, my ASoC driver requires the period size to be
a multiple of 16. What is the best way to ensure that?

[Eliot Blennerhassett]

Post by Timur Tabi
To work around a hardware issue, my ASoC driver requires the period size to
be a multiple of 16. What is the best way to ensure that?

Well, I was going to refer you to
http://www-old.alsa-project.org/~iwai/writing-an-alsa-driver/index.html
but I just get a blank page today.

Set snd_pcm_hardware.period_bytes_min to 16 or is that 16 * samplesize?

You need to add some constraints to your driver, in the open callback.
E.g.
snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 16);

List of hwparams that can be constrained is in asound.h
List of constraint helpers in pcm.h, or grep for snd_pcm_hw_constraint to see
usage examples.

--
Eliot

[Clemens Ladisch]

Post by Eliot Blennerhassett
Set snd_pcm_hardware.period_bytes_min to 16 or is that 16 * samplesize?

This value is measured in bytes.

Post by Eliot Blennerhassett
snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 16);

This parameter is measured in frames.


HTH
Clemens

[Trent Piepho]

Post by Clemens Ladisch

Post by Eliot Blennerhassett
Set snd_pcm_hardware.period_bytes_min to 16 or is that 16 * samplesize?

This value is measured in bytes.

Post by Eliot Blennerhassett
snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 16);

This parameter is measured in frames.

Isn't SNDRV_PCM_HW_PARAM_PERIOD_SIZE measured in frames, and
SNDRV_PCM_HW_PARAM_PERIOD_BYTES in bytes?

[Takashi Iwai]

At Wed, 5 Sep 2007 02:55:32 -0700 (PDT),

Post by Trent Piepho

Post by Clemens Ladisch

Post by Eliot Blennerhassett
Set snd_pcm_hardware.period_bytes_min to 16 or is that 16 * samplesize?

This value is measured in bytes.

Post by Eliot Blennerhassett
snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 16);

This parameter is measured in frames.

Isn't SNDRV_PCM_HW_PARAM_PERIOD_SIZE measured in frames, and
SNDRV_PCM_HW_PARAM_PERIOD_BYTES in bytes?

Yes, *_BYTES is for bytes.

I don't know what happens with www-old.alsa-project.org.
Anyway, I'd love to move back the pages to www.alsa-project.org, if
possible. If that's difficult due to a technical reason, I'm willing
to move the stuff to other web site.

Jaroslav, what is the status?


thanks,

Takashi

[Timur Tabi]

Post by Eliot Blennerhassett
You need to add some constraints to your driver, in the open callback.
E.g.
snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 16);

Thanks. snd_pcm_hw_constraint_step() is not documented anywhere, and the
comments in the source code don't provide any clues, either. Even the "ALSA
Driver API" document just lists the function, but doesn't actually tell you
what it does.

[Trent Piepho]

Post by Timur Tabi

Post by Eliot Blennerhassett
You need to add some constraints to your driver, in the open callback.
E.g.
snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 16);

Thanks. snd_pcm_hw_constraint_step() is not documented anywhere, and the
comments in the source code don't provide any clues, either. Even the "ALSA
Driver API" document just lists the function, but doesn't actually tell you
what it does.

I still haven't figured out what the "condition bits" do. It's always 0 every
time one of the constraint functions are called. I looked in the ALSA core
code, and it seems that if you specify some condition bits they must match
some flag bits in the hw params for the constraint to apply. But the flags
bits just get copied from user space, so there is no clue in the kernel code
what they are or what they do.