From: Craig McQueen <craig.mcqueen@beamcommunications.com>
To: alsa-devel@alsa-project.org
Subject: Low sample rates for SGTL5000 on i.MX28
Date: Thu, 13 Nov 2014 17:34:13 +1100 [thread overview]
Message-ID: <546450E5.9090203@beamcommunications.com> (raw)
I'm testing the 3.18 kernel for i.MX28 EVK, which has an SGTL5000 CODEC.
I notice that audio cannot be output at 8 kHz or 11.025 kHz, although
the SGTL5000 data sheet table 8 indicates this should be possible.
If I try to play or record at 8 kHz or 11.025 kHz, I get an error message:
# aplay test_8k.wav
[ 6168.910201] mxs_evk_startup: Skipped programming wolfson codec
Playing WAVE 'test_8k.wav' : Signed 16 bit Little Endian, Rate 8000
Hz, Mono
[ 6168.941211] sgtl5000 0-000a: Invalid mclk frequency: 4.096MHz
[ 6168.947047] mxs-sgtl5000 sound.11: ASoC: machine hw_params
failed: -22
aplay: set_params:1145: Unable to install hw params:
...
For an 8 kHz sample rate, I get
Invalid mclk frequency: 4.096MHz
For 11.025 kHz sample rate, I get
Invalid mclk frequency: 5.644MHz
Looking in the code (/sound/soc/mxs/mxs-sgtl5000c), I see:
/* Sgtl5000 sysclk should be >= 8MHz and <= 27M */
if (mclk < 8000000 || mclk > 27000000) {
dev_err(codec_dai->dev, "Invalid mclk frequency:
%u.%03uMHz\n",
mclk / 1000000, mclk / 1000 % 1000);
return -EINVAL;
}
But a sysclk constraint of 8 to 27 MHz only applies if the supplied
clock is asynchronous to the frame clock, and the internal clock is
being generated by PLL (which it's not in this case). So I tried
removing this constraint. But I found that from codecs/sgtl5000.c, I
would get the error "PLL not supported in slave mode". I tried changing
the switch (sgtl5000->sysclk / sys_fs) to switch (sgtl5000->sysclk /
frame_rate), on the basis of the SGTL5000 data sheet table 8. But the
resulting audio sounds funny (frequency shifted).
Looking in the SGTL5000 data sheet table 18, it seems unclear whether
the MCLK_FREQ field is a multiple of the sample rate (Fs) or the
internal system sample rate SYS_FS. It seems that there is some
inconsistency in the interpretation of this in codecs/sgtl5000.c
compared to mxs/mxs-sgtl5000.c.
What is the correct interpretation of the SGTL5000 data sheet MCLK_FREQ
field, and can the mxs-sgtl5000 driver be fixed to support 8 kHz and
11.025 kHz sample rates?
--
Craig McQueen
next reply other threads:[~2014-11-13 6:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-13 6:34 Craig McQueen [this message]
2014-11-13 12:32 ` Low sample rates for SGTL5000 on i.MX28 Fabio Estevam
2014-11-13 22:36 ` Craig McQueen
2014-11-13 23:34 ` Fabio Estevam
2014-11-14 0:29 ` Fabio Estevam
2014-11-14 0:59 ` Fabio Estevam
2014-11-14 2:53 ` Fabio Estevam
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=546450E5.9090203@beamcommunications.com \
--to=craig.mcqueen@beamcommunications.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.