Re: [alsa-devel] Artifacts present in AIC23 capture for 48 KHz sampling rate
-----Original Message----- From: Aggarwal, Anuj Sent: Friday, November 06, 2009 6:28 PM To: alsa-devel@alsa-project.org; 'linux-omap@vger.kernel.org' Subject: Artifacts present in AIC23 capture for 48 KHz sampling rate
Hi,
I am observing artifacts (sharp spikes at fixed intervals) while capturing audio on AM3517 EVM and AIC23 codec. They are present only in one of the channels when I am capturing at 48 KHz. All other sampling rates are working fine with the above said combination.
I have also attached the screenshot taken with the help of Audacity utility. Here, I tried recording silence but artifacts were observed on one channel.
Has anyone also observed the similar behavior with AIC23 codec? Any hints on what could be the root cause?
[Aggarwal, Anuj] On further debugging, I found that the function find_rate() in sound/soc/codecs/tlv320aic23.c is not returning the correct value for capture in 48KHz sample rate. In USB mode (MCLK=12MHz), for 48KHz, it returns 0x7D (CLKOUT=0, CLKIN=1, SR[3:0]=0xF, BOSR=1, Normal=1) whereas as per the AIC23B spec, it should have been 0x5D (CLKOUT=0, CLKIN=1, SR[3:0]=0x7, BOSR=1, Normal=1). When I forcefully write the above said value to the Sample Rate Control register, things work fine for me for 48KHz capture. Is my understanding correct for this problem? Can someone help me understand how the function calculates the appropriate value?
Regards, Anuj Aggarwal
Aggarwal, Anuj wrote:
-----Original Message----- From: Aggarwal, Anuj Sent: Friday, November 06, 2009 6:28 PM To: alsa-devel@alsa-project.org; 'linux-omap@vger.kernel.org' Subject: Artifacts present in AIC23 capture for 48 KHz sampling rate
Hi,
I am observing artifacts (sharp spikes at fixed intervals) while capturing audio on AM3517 EVM and AIC23 codec. They are present only in one of the channels when I am capturing at 48 KHz. All other sampling rates are working fine with the above said combination.
I have also attached the screenshot taken with the help of Audacity utility. Here, I tried recording silence but artifacts were observed on one channel.
Has anyone also observed the similar behavior with AIC23 codec? Any hints on what could be the root cause?
[Aggarwal, Anuj] On further debugging, I found that the function find_rate() in sound/soc/codecs/tlv320aic23.c is not returning the correct value for capture in 48KHz sample rate. In USB mode (MCLK=12MHz), for 48KHz, it returns 0x7D (CLKOUT=0, CLKIN=1, SR[3:0]=0xF, BOSR=1, Normal=1) whereas as per the AIC23B spec,
0x7D would be BOSR = 0, USB/NORMAL = 1, SR=0xff, div2 = 1
The bug is with sr_valid_mask,
static const unsigned short sr_valid_mask[] = { LOWER_GROUP|UPPER_GROUP, /* Normal, bosr - 0*/ LOWER_GROUP|UPPER_GROUP, /* Normal, bosr - 1*/ LOWER_GROUP, /* Usb, bosr - 0*/ UPPER_GROUP, /* Usb, bosr - 1*/ };
should be
static const unsigned short sr_valid_mask[] = { LOWER_GROUP|UPPER_GROUP, /* Normal, bosr - 0*/ LOWER_GROUP, /* Usb, bosr - 0*/ LOWER_GROUP|UPPER_GROUP, /* Normal, bosr - 1*/ UPPER_GROUP, /* Usb, bosr - 1*/ };
Can you give this a try and let me know?
Thanks Troy
-----Original Message----- From: Troy Kisky [mailto:troy.kisky@boundarydevices.com] Sent: Wednesday, November 18, 2009 12:39 AM To: Aggarwal, Anuj Cc: alsa-devel@alsa-project.org; linux-omap@vger.kernel.org Subject: Re: [alsa-devel] Artifacts present in AIC23 capture for 48 KHz sampling rate
Aggarwal, Anuj wrote:
-----Original Message----- From: Aggarwal, Anuj Sent: Friday, November 06, 2009 6:28 PM To: alsa-devel@alsa-project.org; 'linux-omap@vger.kernel.org' Subject: Artifacts present in AIC23 capture for 48 KHz sampling rate
Hi,
I am observing artifacts (sharp spikes at fixed intervals) while capturing audio on AM3517 EVM and AIC23 codec. They are present only in one of the channels when I am capturing at 48 KHz. All other sampling rates are working fine with the above said combination.
I have also attached the screenshot taken with the help of Audacity utility. Here, I tried recording silence but artifacts were observed on one channel.
Has anyone also observed the similar behavior with AIC23 codec? Any hints on what could be the root cause?
[Aggarwal, Anuj] On further debugging, I found that the function find_rate() in sound/soc/codecs/tlv320aic23.c is not returning the correct value for capture in 48KHz sample rate. In USB mode (MCLK=12MHz), for 48KHz, it returns 0x7D (CLKOUT=0, CLKIN=1, SR[3:0]=0xF, BOSR=1, Normal=1) whereas as per the AIC23B spec,
0x7D would be BOSR = 0, USB/NORMAL = 1, SR=0xff, div2 = 1
The bug is with sr_valid_mask,
static const unsigned short sr_valid_mask[] = { LOWER_GROUP|UPPER_GROUP, /* Normal, bosr - 0*/ LOWER_GROUP|UPPER_GROUP, /* Normal, bosr - 1*/ LOWER_GROUP, /* Usb, bosr - 0*/ UPPER_GROUP, /* Usb, bosr - 1*/ };
should be
static const unsigned short sr_valid_mask[] = { LOWER_GROUP|UPPER_GROUP, /* Normal, bosr - 0*/ LOWER_GROUP, /* Usb, bosr - 0*/ LOWER_GROUP|UPPER_GROUP, /* Normal, bosr - 1*/ UPPER_GROUP, /* Usb, bosr - 1*/ };
Can you give this a try and let me know?
[Aggarwal, Anuj] I tried this on AM3517 EVM + AIC23B; it works fine for me. But I have tested the fix only with a 12 MHz clock. Thanks for quickly fixing this.
Thanks Troy
Fix the ordering of sr_valid_mask array. The lower bit of the index represents USB not bosr.
Reported-by: Anuj Aggarwal anuj.aggarwal@ti.com Signed-off-by: Troy Kisky troy.kisky@boundarydevices.com --- sound/soc/codecs/tlv320aic23.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sound/soc/codecs/tlv320aic23.c b/sound/soc/codecs/tlv320aic23.c index 0b8dcb5..6b24d8b 100644 --- a/sound/soc/codecs/tlv320aic23.c +++ b/sound/soc/codecs/tlv320aic23.c @@ -265,8 +265,8 @@ static const int bosr_usb_divisor_table[] = { #define UPPER_GROUP ((1<<8) | (1<<9) | (1<<10) | (1<<11) | (1<<15)) static const unsigned short sr_valid_mask[] = { LOWER_GROUP|UPPER_GROUP, /* Normal, bosr - 0*/ - LOWER_GROUP|UPPER_GROUP, /* Normal, bosr - 1*/ LOWER_GROUP, /* Usb, bosr - 0*/ + LOWER_GROUP|UPPER_GROUP, /* Normal, bosr - 1*/ UPPER_GROUP, /* Usb, bosr - 1*/ }; /*
On Tue, Nov 17, 2009 at 01:51:01PM -0700, Troy Kisky wrote:
Fix the ordering of sr_valid_mask array. The lower bit of the index represents USB not bosr.
Reported-by: Anuj Aggarwal anuj.aggarwal@ti.com Signed-off-by: Troy Kisky troy.kisky@boundarydevices.com
Applied, thanks.
participants (3)
-
Aggarwal, Anuj
-
Mark Brown
-
Troy Kisky