imx28 sgtl5000 recording issue

[christianswion]

Hello guys,

i have an issue trying to record from an SGTL5000 using 8kHz sampling rate.

The soundquality is very bad, higher samplerates are okay.

I think there is an issue in one of the kernel-drivers.

We are using a custom board with the sgtl5000, installed kernel is 3.14.35 with backported patches from mainline to

- sound/soc/mxs/mxs-pcm.c

- sound/soc/mxs/mxs-saif.c

- sound/soc/codecs/sgtl5000.c

- sound/soc/mxs/mxs-sgtl5000.c

I'am as good as possible on the current mainline drivers, except of underlying frameworks.

arecord -D "hw:0,1" -t wav -f S16_LE -c 2 -r 8000 test.wav

I've attachted a sample recording with 8 kHz, it sound like there a missing samples.

And a file with 48 kHz sampling rate, same hw and settings.

Capture-vol: 67, mic-vol: 33, AVC-off, Capture-ZC off.

The hardware is almost exactly the reference from the sgtl5000 datasheet.

Can anyone help me?

Thank you guys!!

kind regards,

Christian

[christianswion]

Hi Fabio,

its simple, just playback a wav file with 8 kHz rate:
> aplay test.wav

That sounds wired to me, similiar to the recording failure.

We have a application which receives and transmits one RTP-stream, at first we tried to sample the microphone with 48kHz and resample it by gstreamer to 8kHz.

Same with the playback: we receive at 8kHz stream and resample it to 48kHz for the speaker output.

This only eats about 60% cpu and addtionally we have a gui with touchscreen-input.

Now the idea was to capture/playback directly with 8Khz, then no resampling is needed.

Regards,

Christian

[fabio_estevam]

Hi Christian,

I was able to reproduce this issue on a imx28evk board.

Will let you know if I can make any progress on this.

Regards,

Fabio Estevam

[fabio_estevam]

Hi Christian,

Do you know if any kernel version has ever played 8kHz correctly? Does NXP 2.6.31 kernel behave correctly?

I would like to know if this is a regression or not.

Regards,

Fabio Estevam

[christianswion]

Hi Fabio,

I’ve tried 3.14.0 – 8kHz playback isn’t supported until your patches: https://github.com/torvalds/linux/commit/2a4cfd10229dc93507aa5ddbc1ba0162140f4951#diff-4073f96dd68da... and https://github.com/torvalds/linux/commit/d206f66177ab7cd69d79c7e01b43f45d935f43dd#diff-54fba35cc9710... .

With this patches enabled the problem is already present.

I’ve never tested Kernel 2.6.31 on imx28, we started our development on kernel 3.10 and now we are on 3.14 with upstream-patches for sgtl5000.

Probably this could take many time to setup which I want to avoid.. I’m not familiar with kernel 2.6. (no dt etc…).

Regards,

Christian

Von: FabioEstevam

Gesendet: Mittwoch, 17. Januar 2018 17:26

An: Fischer, Christian <fischerc@swissphone.de>

Betreff: Re: - Re: imx28 sgtl5000 recording issue

NXP Community <https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>

Re: imx28 sgtl5000 recording issue

reply from Fabio Estevam<https://community.nxp.com/people/FabioEstevam?et=watches.email.thread> in i.MX Community - View the full discussion<https://community.nxp.com/message/978428?commentID=978428&et=watches.email.thread#comment-978428>

[fabio_estevam]

Hi Christian,

Ok, understood. This means that the 8kHz problem is not a regression and it has been present for a long time.

I don't have the time currently to investigate this issue.

Hope you can make progress with it.

Regards,

Fabio Estevam

[christianswion]

Hello Fabio,

unfortunately I couldn’t make a progress on this.

I compared register maps and had a look on the clocks with a osci.

Compared to 16kHz playback/capture, everything looks fine..

16kHz:

- 8.196 MHz mclk

- 512 kHz Bclk

- Register diff: 1/2 SYS_FS, int. Rate 32 kHz and 512*FS

8 kHz:

- 4.096MHz mclk

- 256 kHz bclk

- Register diff: 1/4 SYS_FS, int. Rate 32 kHz and 512*FS

Only the internal sys-rate divider was different to 16 kHz operation.

Clocks looking okay, I already tried these patches to properly set the saif fractional divider:

https://community.nxp.com/thread/357691

But that did not the trick.

I once tested with 11.025kHz, the error is also there, but not as strong as at 8 kHz.

Maybe its dependent from the mclk which is below 8 MHz using 8/11.025 kHz?

Or maybe we need to set other pcm-parameters?

root@172:~ arecord -D "hw:1,1" -c 2 -t wav -f S16_LE -r 8000 -vv test__.wav

Recording WAVE 'test__.wav' : Signed 16 bit Little Endian, Rate 8000 Hz, Stereo

Hardware PCM card 1 'mxs_sgtl5000' device 1 subdevice 0

Its setup is:

stream : CAPTURE

access : RW_INTERLEAVED

format : S16_LE

subformat : STD

channels : 2

rate : 8000

exact rate : 8000 (8000/1)

msbits : 16

buffer_size : 4000

period_size : 1000

period_time : 125000

tstamp_mode : NONE

tstamp_type : MONOTONIC

period_step : 1

avail_min : 1000

period_event : 0

start_threshold : 1

stop_threshold : 4000

silence_threshold: 0

silence_size : 0

boundary : 2097152000

appl_ptr : 0

hw_ptr : 0

root@172:~ arecord -D "hw:1,1" -c 2 -t wav -f S16_LE -r 16000 -vv test__.wav

Recording WAVE 'test__.wav' : Signed 16 bit Little Endian, Rate 16000 Hz, Stereo

Hardware PCM card 1 'mxs_sgtl5000' device 1 subdevice 0

Its setup is:

stream : CAPTURE

access : RW_INTERLEAVED

format : S16_LE

subformat : STD

channels : 2

rate : 16000

exact rate : 16000 (16000/1)

msbits : 16

buffer_size : 8000

period_size : 2000

period_time : 125000

tstamp_mode : NONE

tstamp_type : MONOTONIC

period_step : 1

avail_min : 2000

period_event : 0

start_threshold : 1

stop_threshold : 8000

silence_threshold: 0

silence_size : 0

boundary : 2097152000

appl_ptr : 0

hw_ptr : 0

Sorry that I cant make progress on this, my knowledge about kernel-debugging and alsa are not so big…

Can you find the time to investigate this further?

Kind regards,

Christian

Von: FabioEstevam

Gesendet: Donnerstag, 18. Januar 2018 11:31

An: Fischer, Christian <fischerc@swissphone.de>

Betreff: Re: - Re: imx28 sgtl5000 recording issue

NXP Community <https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>

Re: imx28 sgtl5000 recording issue

reply from Fabio Estevam<https://community.nxp.com/people/FabioEstevam?et=watches.email.thread> in i.MX Community - View the full discussion<https://community.nxp.com/message/978691?commentID=978691&et=watches.email.thread#comment-978691>

[fabio_estevam]

Hi Christian,

If I remember correctly SGTL5000 SYS_MCLK should be betweenn 8 and 27MHz.

Regards,

Fabio Estevam

[christianswion]

Hi Fabio,

this is correct for the PLL mode.. but in synchronous mclk mode max. 512*FS => 4.096 MHz, so that’s already the max. clock for 8kHz.

PLL mode can’t be used with mxs28 because the saif only works in master-mode but sgtl5000 can only work in PLL mode if he is the clock-master.

Had also a look on the SAIF-registers, but I can’t see any important difference to other sampling rates.

Just tried a 4.15.0-rc9 (sound/for-next branch) and the failure exists also.

I can’t make further progress on this, but we need this for RTP streaming.. hope you can find time to have a deeper look on it.

Regards,

Christian

[fabio_estevam]

Hi Christian,

Yes, you are correct.

What happens if you remove the -D "hw:1,1" parameter of aplay/arecord? Would ALSA perform sample rate conversion and the sound becomes better?

Regards,

Fabio Estevam

[christianswion]

Hi Fabio,

If I set the card as sysdefault and set rate to 16kHz or higher this works.

But with samplerate conversion we run into high cpu load.

Because we stream RTP-data, we only need the 8kHz samplingrate. Because of the symetric rates of the SAIF, we then have to downsample the recording before streaming and upsample the stream before playback.

Regards,

Christian

[fabio_estevam]

Hi Christian,

Could you try using the audio simple card bindings instead of using mxs-sgtl5000.c ?

Regards,

Fabio Estevam

[christianswion]

Hello Fabio,

I did that test and unfortunately this is broken too.

I’m not 100% sure, but if I record with 8kHz and then playback on the same device, it seems that the quality is better.

Simple-Sound-Card setup:

First I had to patch the mxs-saif.c with this unapplied patch: https://marc.info/?l=linux-kernel&m=148242588200882&w=2

I had to make a little trick in the simple-sound-card.c, with 2 dai-links the linking failed because they hat the same name. Don’t now how to fix this properly but I added the field prefix to the dai-link-node.

asoc_simple_card_dai_link_of in simple-sound-card.c

int link_prefix = 0;

of_property_read_u32(node, "prefix", &link_prefix);

ret = asoc_simple_card_set_dailink_name(dev, dai_link,

"%s-%s%d",

dai_link->cpu_dai_name,

dai_link->codec_dai_name,

link_prefix);

Devicetree:

sound {

compatible = "simple-audio-card";

simple-audio-card,name = "mx28-sgtl5000";

simple-audio-card,mclk-fs = <512>;

simple-audio-card,widgets =
"Microphone", "Mic Jack",
"Line", "Line In",
"Line", "Line Out",
"Headphone", "Headphone Jack";
simple-audio-card,routing =
"MIC_IN", "Mic Jack",
"Mic Jack", "Mic Bias",
"Headphone Jack", "HP_OUT";

simple-audio-card,dai-link@0 {
format = "i2s";
bitclock-master = <&cpu_dai0>;
frame-master = <&cpu_dai0>;
prefix = <0>;

cpu_dai0: cpu {
sound-dai = <&saif0>;
};
codec_dai0: codec {
sound-dai = <&sgtl5000>;
clocks = <&saif0>;
};
};

simple-audio-card,dai-link@1 {
format = "i2s";
bitclock-master = <&cpu_dai0>;
frame-master = <&cpu_dai0>;
prefix = <1>;

cpu_dai1: cpu {
sound-dai = <&saif1>;
};

codec_dai1: codec {
sound-dai = <&sgtl5000>;
};

};

};

Codec:
sgtl5000: codec@a {
#sound-dai-cells = <0>;
compatible = "fsl,sgtl5000";
reg = <0x0a>;
clocks = <&saif0>;
VDDA-supply = <&reg_3p3v>;
VDDIO-supply = <&reg_3p3v>;
VDDD-supply = <&reg_sgtl5000_vddd>;
micbias-resistor-k-ohms = <2>;
micbias-voltage-m-volts = <2750>;
};

SAIF:
saif0: saif@80042000 {
pinctrl-names = "default";
pinctrl-0 = <&saif0_pins_a>;
assigned-clocks = <&clks 53>;
assigned-clock-rates = <24576000>;

status = "okay";

};

Which results in:

asoc-simple-card sound: mxs-saif : sysclk = 24572753, direction 0

asoc-simple-card sound: sgtl5000 : sysclk = 24572753, direction 0

asoc-simple-card sound: name : mxs-saif-sgtl5000-0

asoc-simple-card sound: link 1:

asoc-simple-card sound: format : 4001

asoc-simple-card sound: mxs-saif : sysclk = 7324, direction 0

asoc-simple-card sound: sgtl5000 : sysclk = 24572753, direction 0

asoc-simple-card sound: name : mxs-saif-sgtl5000-1

asoc-simple-card sound: Card Name: mx28-sgtl5000

asoc-simple-card sound: sgtl5000 <-> 80042000.saif mapping ok

asoc-simple-card sound: sgtl5000 <-> 80046000.saif mapping ok

Regards,

Christian

[christianswion]

Didn't tried it because first I have to port our BSP modifications to the 4.14.

That could take some time..

Should I try it?

Regards,

Christian Fischer

[fabio_estevam]

I think it is worth trying it with the latest mainline kernel.

Please note that kernel 3.14 is no longer supported.

Regards,

Fabio Estevam

[christianswion]

Hello Fabio,

I've got now the 4.14.12 kernel running, but the result is the same.

Only patch on the sgtl5000 codec was to fix the micbias:

In "mic_bias_event":

    switch (event) {
    case SND_SOC_DAPM_POST_PMU:
+  case SND_SOC_DAPM_POST_PMD:

and in "sgtl5000_dapm_widgets":                                                  

"SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD)," to

"SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD | SND_SOC_DAPM_POST_PMD),"

Otherwise the codec will not supply my microphone. I had to fix this already in 3.14.

kind regards,

Christian

[fabio_estevam]

Hi Christian,

Ok, great. Let's try to fix the problem in mainline.

First of all, please submit your micbias patch to the alsa-devel list.

./scripts/get_maintainer.pl sound/soc/codecs/sgtl5000.c will tell you the correct people and list to submit it to.

If you have issues with the process, please contact me offline.

On the recording issue, please report this problem in the alsa-devel list as well.

I will try to assist there.

Regards,

Fabio Estevam

[christianswion]

Hello Fabio,

the patch is posted in: [alsa-devel] [PATCH] ASoC: sgtl5000: Fix powerup/down of micbias 

The recording problem is posted in: [alsa-devel] ASoC: sgtl5000: recording issue at 8 kHz with fsl-imx28 

Hope that is ok!

Kind regards,

Christian Fischer

[christianswion]

Hello Fabio,

could you have a look at the problem?
I've found out that the playback is also affected by the problem.
If i can provide you any information or do tests, please let me know.

I've commited, hopefully the last, patch für mxs-sgtl5000 regarding the mic-bias issue: http://mailman.alsa-project.org/pipermail/alsa-devel/2018-January/130666.html
But this don't have any relations with the 8 kHz recording and playback problem.

Regards,
Christian

[fabio_estevam]

Hi Christian,

I don't have access to a mx28evk board at the moment. I hope to be able to investigate this issue next week.

Could you please show me the steps for reproducing the playback issue?

Maybe it will be easier to debug playback use case.

Thanks for submitting the fix to alsa-devel. I understand these are separate issues.

Regards,

Fabio Estevam

[fabio_estevam]

Does it record well if you use kernel 4.14.12 instead?

Regards,

Fabio Estevam