[alsa-devel] How can I make sure the period size is a multiple of 16?
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?
On Wednesday 05 September 2007 10:50:31 Timur Tabi wrote:
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
Eliot Blennerhassett wrote:
Set snd_pcm_hardware.period_bytes_min to 16 or is that 16 * samplesize?
This value is measured in bytes.
snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES, 16);
This parameter is measured in frames.
HTH Clemens
On Wed, 5 Sep 2007, Clemens Ladisch wrote:
Eliot Blennerhassett wrote:
Set snd_pcm_hardware.period_bytes_min to 16 or is that 16 * samplesize?
This value is measured in bytes.
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?
At Wed, 5 Sep 2007 02:55:32 -0700 (PDT), Trent Piepho wrote:
On Wed, 5 Sep 2007, Clemens Ladisch wrote:
Eliot Blennerhassett wrote:
Set snd_pcm_hardware.period_bytes_min to 16 or is that 16 * samplesize?
This value is measured in bytes.
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
Eliot Blennerhassett wrote:
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.
On Thu, 6 Sep 2007, Timur Tabi wrote:
Eliot Blennerhassett wrote:
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.
participants (5)
-
Clemens Ladisch -
Eliot Blennerhassett -
Takashi Iwai -
Timur Tabi -
Trent Piepho