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 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.