Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Pedro I. Sanchez" <psanchez@fosstel.com>
Cc: alsa-devel@alsa-project.org
Subject: Re: ASoC: at91sam9260-PCM1808/TAS5709-based board driver
Date: Tue, 25 Aug 2009 15:46:14 -0400	[thread overview]
Message-ID: <4A943F86.5000601@fosstel.com> (raw)
In-Reply-To: <20090825182934.GA4317@sirena.org.uk>

Mark Brown wrote:
> On Tue, Aug 25, 2009 at 01:31:57PM -0400, Pedro I. Sanchez wrote:
> 
>> The TAS5709 is a playback-slave-only device The SSC is therefore put in 
>> master mode and I can see the SSC clock signals (SCLK and LRCLK) on the 
>> scope when playing a sound file. I can also see the activity on the data 
>> line. But unfortunately, there is no sound, just a speaker Hisss when I 
>> play a file. I doubled checked all the volume levels to ensure they are 
>> not mutted.
> 
> Is there any control in the CODEC?  If so you should check that it is
> set up properly.
> 

There are registers to mute/unmute channels and master volume. For the 
time being I am using my pcm_prepare function to write directly to those 
registers to ensure that they are not muted when a sound file is played.

I haven't "mastered" the definitions of sound controls in ALSA yet, I'll 
do that later.

>> However, I noticed that the duty cycle of the SSC clocks is not 50% as I 
>> would expect it to be. There seem to be much more bits on one channel 
>> than in the other (my sample file is stereo, 16 bits, 44.1 MHz). The 
>> sample clock illustrations in the TAS5709 all have the same number of 
>> bits per channel, but it doesn't say explicitly that this is mandatory. 
>>  From my understanding of the I2S spec, this is not.
> 
>> The TAS5709 is supposed to detect the clock and data rates 
>> automatically. Do you know if this non-50% duty cycle could be the 
>> reason for the lack of sound? Is there a way to force it to be 50%?
> 
> If the CODEC is trying to work out what the sample and clock rates are
> automatically then it does seem reasonable that any oddities in the
> clocks that it's given might confuse it somehow - for example, causing
> it to expect more bit clocks than it's actually getting which would
> cause it to fail to clock in enough data to do a conversion.
> 
> I'd expect that appropriate configuration of the clock dividers for the
> SSC it's possible to make it generate more normal looking clocks, I
> don't think anyone ever optimised the divider configuration when the
> AT91SAM9G20-EK was running the SSC in master mode.

Indeed, as I change the dividers the duty cycle changes. But I am out of 
logic now on how to find the right values. It seems that a high degree 
of black magic is required to find them. This is the code that I am 
using in the machine driver to set them up:

	/* set the MCK divider for BCLK */
	ret = snd_soc_dai_set_clkdiv(cpu_dai, ATMEL_SSC_CMR_DIV, cmr_div);
	if (ret < 0)
		return ret;

	if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
		/* set the BCLK divider for DACLRC */
		ret = snd_soc_dai_set_clkdiv(cpu_dai,
						ATMEL_SSC_TCMR_PERIOD, period);
	} else {
		/* set the BCLK divider for ADCLRC */
		ret = snd_soc_dai_set_clkdiv(cpu_dai,
						ATMEL_SSC_RCMR_PERIOD, period);
	}
	if (ret < 0)
		return ret;


The big quest for me now is to figure out what "cmr_div" and "period" 
have to be. They must be different for each sample rate. Any pointers 
would be appreciated.

Thanks,

--
Pedro

> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

  reply	other threads:[~2009-08-25 19:46 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-08 17:39 ASoC: at91sam9260-PCM1808/TAS5709-based board driver Pedro Sanchez
2009-08-09 10:36 ` Mark Brown
2009-08-09 13:35 ` Jon Smirl
2009-08-09 13:37   ` Jon Smirl
2009-08-11 18:41     ` Pedro I. Sanchez
2009-08-11 18:51       ` Jon Smirl
2009-08-11 22:41       ` Mark Brown
2009-08-25 17:31         ` Pedro I. Sanchez
2009-08-25 18:29           ` Mark Brown
2009-08-25 19:46             ` Pedro I. Sanchez [this message]
2009-08-26 11:44               ` Mark Brown
2009-08-27 19:11                 ` Pedro I. Sanchez
2009-08-28 12:15                   ` Mark Brown
2009-08-28 21:24                     ` Pedro I. Sanchez
2009-08-28 21:52                       ` Pedro I. Sanchez
2009-08-29  9:18                       ` Mark Brown
2009-08-29 16:01                         ` Pedro I. Sanchez

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=4A943F86.5000601@fosstel.com \
    --to=psanchez@fosstel.com \
    --cc=alsa-devel@alsa-project.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox