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
next prev parent 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