All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: alsa-devel@alsa-project.org, Takashi Iwai <tiwai@suse.de>,
	nsekhar@ti.com, Liam Girdwood <lgirdwood@gmail.com>,
	Jyri Sarha <jsarha@ti.com>,
	zonque@gmail.com, Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH v3 1/3] ASoC: davinci-mcasp: Constraint on the period and buffer size based on FIFO usage
Date: Tue, 25 Mar 2014 12:07:58 +0200	[thread overview]
Message-ID: <5331557E.9020908@ti.com> (raw)
In-Reply-To: <532AF7E7.8060702@metafoo.de>

[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]

On 03/20/2014 04:15 PM, Lars-Peter Clausen wrote:
> That sounds like a bug in either the kernel or alsa-lib. We do have a rule in
> place that specifies that the buffer size needs to be a integer multiple of
> the period size and we have a rule in place that the period size needs to be a
> multiple of a constant C. Hence ALSA should be able to deduce that the buffer
> size needs to be at least a multiple of min_periods * C. We probably should
> fix this for good and not workaround it in individual drivers. Do you think
> you can put together a small standalone test application that shows the issue?

Now that I have 'wasted' quite some time with this I ended up writing the tool
to test the issue.

It is a simple tool which:
opens the hw:0,0 (you can pass another PCM to open).
Goes and tests 44.1, 88.2, 48 and 96 KHz from 0.1s to 1s buffer time with
0.005s steps.
It prints the running test and tells if the combination failed or not. If it
is OK, it is going to print the resulting buffer time.

Since the output is long for email they are in pastebin.

On am335x-evmsk only period_step = 32 constraint is placed by the McASP driver:
http://pastebin.com/C81uQkJd

When both period_step and buffer_step is set to 32:
http://pastebin.com/D8hr3bQ1

As a note: if I run this tool on my desktop/laptop it does fail in some
combination there as well with hd_intel. What is even more interesting is that
I have less failure cases with hda_intel on 64bit machines then on my old
macbook1,1 which is 32bit Linux. Basically the mcabook,1,1 behaves similarly
like my am335x (when I change the hda_intel driver to place only period_step =
32 constraint)

-- 
Péter

[-- Attachment #2: constraint.c --]
[-- Type: text/x-csrc, Size: 2285 bytes --]

#ifndef _GNU_SOURCE
#define _GNU_SOURCE
#endif

#include <stdio.h>
#include <alsa/asoundlib.h>

#define BUFFER_TIME_MIN		(100000)
#define BUFFER_TIME_MAX		(1000000)
#define BUFFER_TIME_STEP	(5000)

int try_alsa_setup(snd_pcm_t *pcm, unsigned int rate, unsigned int *buffer_time,
		   unsigned int *periods)
{
	int r;
	snd_pcm_hw_params_t *hwparams;

	snd_pcm_hw_params_alloca (&hwparams);

	r = snd_pcm_hw_params_any(pcm, hwparams);
	if (r < 0)
		return r;

	r = snd_pcm_hw_params_set_rate_resample(pcm, hwparams, 0);
	if (r < 0)
		return r;

	r = snd_pcm_hw_params_set_access(pcm, hwparams,
	                                  SND_PCM_ACCESS_RW_INTERLEAVED);
	if (r < 0)
		return r;

	r = snd_pcm_hw_params_set_format(pcm, hwparams,SND_PCM_FORMAT_S16_LE);
	if (r < 0)
		return r;

	r = snd_pcm_hw_params_set_rate_near(pcm, hwparams, &rate, NULL);
	if (r < 0)
		return r;

	r = snd_pcm_hw_params_set_channels(pcm, hwparams, 2);
	if (r < 0)
		return r;

	r = snd_pcm_hw_params_set_buffer_time_near(pcm, hwparams, buffer_time,
	                NULL);
	if (r < 0)
		return r;

	r = snd_pcm_hw_params_set_periods_near(pcm, hwparams, periods, NULL);
	if (r < 0)
		return r;

	r = snd_pcm_hw_params(pcm, hwparams);
	if (r < 0)
		return r;

	r = snd_pcm_hw_params_current(pcm, hwparams);
	if (r < 0)
		return r;

	return 0;
}

int main(int argc, char *argv[])
{
	const char *dev;
	snd_pcm_t *pcm;
	unsigned int rates[] = {44100, 88200, 48000, 96000, 0 };
	unsigned int periods = 10;
	unsigned int i;
	int r;

	dev = argc > 1 ? argv[1] : "hw:0,0";

	printf("Opening %s\n\n", dev);
	for (i = 0; rates[i]; i++) {
		unsigned int time = BUFFER_TIME_MIN;
		do {
			unsigned int buffer_time = time;
			r = snd_pcm_open(&pcm, dev, SND_PCM_STREAM_PLAYBACK, 0);
			if (r < 0) {
				printf("Failed to open %s\n", dev);
				return -1;
			}

			printf("Try of %dHz, %u us buffer: ", rates[i],
			       buffer_time);

			r = try_alsa_setup(pcm, rates[i], &buffer_time,
					   &periods);

			if (r < 0)
				printf("FAILED\n");
			else
				printf("OK (got %u us)\n", buffer_time);

			r = snd_pcm_close(pcm);
			if (r < 0) {
				printf("snd_pcm_close() failed %d\n", r);
				return r;
			}
			time += BUFFER_TIME_STEP;
		} while (time <= BUFFER_TIME_MAX);
	}

	printf("Done with %s\n\n", dev);
	return 0;
}

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]



  reply	other threads:[~2014-03-25 10:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-18 13:20 [PATCH v3 0/3] ASoC: davinci: perparation for eDMA dmaengine PCM Peter Ujfalusi
2014-03-18 13:20 ` [PATCH v3 1/3] ASoC: davinci-mcasp: Constraint on the period and buffer size based on FIFO usage Peter Ujfalusi
2014-03-18 13:23   ` Peter Ujfalusi
2014-03-18 14:28     ` Peter Ujfalusi
2014-03-18 18:07       ` Mark Brown
2014-03-19 11:13         ` Peter Ujfalusi
2014-03-19 13:14           ` Mark Brown
2014-03-20 13:47             ` Peter Ujfalusi
2014-03-20 14:15               ` Lars-Peter Clausen
2014-03-25 10:07                 ` Peter Ujfalusi [this message]
2014-03-18 13:20 ` [PATCH v3 2/3] ASoC: davinci-mcasp: Assign the dma_data earlier in dai_probe callback Peter Ujfalusi
2014-03-19 13:19   ` Mark Brown
2014-03-18 13:20 ` [PATCH v3 3/3] ASoC: davinci-pcm: Add empty functions for !CONFIG_SND_DAVINCI_SOC builds Peter Ujfalusi
2014-03-19 13:16   ` Mark Brown

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=5331557E.9020908@ti.com \
    --to=peter.ujfalusi@ti.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=jsarha@ti.com \
    --cc=lars@metafoo.de \
    --cc=lgirdwood@gmail.com \
    --cc=nsekhar@ti.com \
    --cc=tiwai@suse.de \
    --cc=zonque@gmail.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.