Problem on sound speed

[victorien]

Hi,

I make some audio test on my board : imx280, sgtl5000, Linux3.14, rootfs by OpenEmbedded and I play MP3 file with mpg123.

the issue is : my platform need 60s and 35ms to play a sound of 60s (it's take 60s on my computer). I try with another MP3 player and I have the same problem.

Is there someone who knows were is generate this changement of speed ?

[jörg_krause]

Hi Victorien,

I am using your clock correction patch for a while and I noticed a mistake when setting the SAIF clock in mxs_saif_set_clk(). Setting the clock rate with clk_set_rate(master_saif->clk, round_mclk); only works if the master clock is 384*fs or 512*fs. For example I have a codec which does only support 192*fs for sample rates of 192kHz. Therefore, the desired master clock is 36.864MHz. Now, using your patch the wrong clock divider is set to HW_CLKCTRL_SAIF0_DIV (0x13A9 instead of 0x2752).

Note, that a comment in the mainline driver notes: SAIF clock should be either 384*fs or 512*fs. Therefore, I fixed the issue by setting clk_set_rate(master_saif->clk, [384|512]*fs); depending on the sampling rate.

[victorien]

Hi,

sorry to answer you so late ; I just see your message.

Your issue looks very strange because during my test, I see that the value change of +1 or -1 with or without the patch.

Did you see a difference without my patch ?

I check fastly on the datasheet and I'm not sure that it's possible to generate a MCLK clock of fs*192 with iMX28. I'll try to make more test next week.

[jörg_krause]

Hi Victorien,

I just saw your reply...

What I meant is that the base oversample rate should be 512 or 384 times the sample rate. An additional divider exists within the SAIF to generate sub-multiples of these two base rates if required by the codec:

• The sub-rates that can be generated from 512x are: 256x, 128x, 64x, and 32x.
• The sub-rates for the 384x base rate are: 192x, 96x, and 48x.

Your patch only works for the base rates 512 and 384, but not for the sub-rates.

EDIT: I finally managed to attach the patches. Note, that the first patch has been accepted upstream. The second patch still needs further testing, especially when both SAIF0 and SAIF1 are used.

[victorien]

Hi Jörg,

Ok, I understand your correction. My patch didn't touch this part and the codec that I use works at 384x or 512x then I didn't see this issue.

It's great that you patch the kernel !

[CarlosCasillas]

Hi,

Have you considered file open/close times on the embedded system? What about clock precision on the i.MX28 board?

In the other hand, I’m afraid that such Linux version and MP3 players are not supported by Freescale on the i.MX28 platform.

Hope this will be useful for you.
Best regards!
/Carlos

[victorien]

Hi,

Thanks for your answer. I made more tests and I found the reason of my problem : the issue is the SAIF clock. There are a bug on divider computing and the precision of the divider is not enough to provide a stable audio rate for a long time (cf chapter 35.2.1 of datasheet). I'm working on a correction.

[jörg_krause]

Hi,

do you like tho share your investigations? Many thanks!

[victorien]

Hi,

Sure, I can share !

I made 2 modifications :

- On mxs clock driver, I change the function which compute the divider to have the best result (cf patch 0001)

- The iMX28 datasheet says that the precision of divider in not enough to respect an audio/video synchronisation (chapter 35.2.1 page 2203). Then I had a process to change periodicaly the SAIF frequency (cf patch 0003)

This code is based on kernel 3.14 and I'm not sure that it is conformed to the "linux rule" then you can propose improvment !

[jörg_krause]

Many thanks for this! Great work!

I applied the patches without any problems on a 4.0 Kernel. The synchronisation is much better now. However sometimes the frequency is adjusted to a new value where after this a lot of sync errors occur. The frequency is adjusted to the old value after around 52 seconds and the sync is alright again. Do you know why the frequency is adjusted?

[jörg_krause]

I have got it! Every 420.1 seconds the frequency is adjusted for 52 seconds to maintain audio synchronization within +/-20ms, right?

[victorien]

Yes it's right. This part is explain on datasheet.

But I don't understand what do you mean by "However sometimes the frequency is adjusted to a new value where after this a lot of sync errors occur.".

This modification of the driver is under development, then I'm really interested by your comments and results

[jörg_krause]

victorien Let me explain: The source DACs clock (a remote music player) has coincidentally the same "wrong" clock frequency which is not adjusted. The first 420 seconds both are running "synchronous". After 52 seconds my clock is running faster then the remotes clock and the device has to do some corrections to maintain synchronization with the slower remote clock.

So, as you see, this is not a problem of your patch. So forget about this - it just took me a while to understand what's happening here :-)

[fabio_estevam]

Good job, Victorien!

Does it take exactly 60s for the track to play with your changes applied?

When you are happy with the fix, please let me know and I can help you submitting your changes to the mainline kernel.

Regards,

Fabio Estevam

[jörg_krause]

As the patch 1 is a bugfix we should really submit it to mainline kernel!

[fabio_estevam]

I agree, Jörg. If you or Victorien could send it, that would be awesome. Please note that the patch misses a Signed-off-by tag.

[victorien]

I'm agree and I'll submit it to mainline. Do you have any comment about this patch ? improvment ? respect of kernel rule ?

And it will be the first time I submit a patch to list ; what is the best way to do ?

[lategoodbye]

Hi Victorien,

do you still want to submit this patch to mainline? In the case you don't have the time please let us know.

Regards

Stefan Wahren

[victorien]

Hi,

get_maintainer.pl doesn't suggest Shawn Guo and alsa-devel list (but the patch is for clock in general, not specific to audio part). Stephen Boyd adds Shown in copy.

Stefan, Who is Marek (is email address) that you suggest to add in copy ?

[lategoodbye]

Hi Victorien,

get_maintainer.pl is only a tool to make suggestions and is not exact in every case:

Shawn Guo is author of the driver and maintainer of MXS architecture

Marek Vasut ( marex@denx.de ) is a very active developer for i.MX28 platform

Best regards

Stefan

[victorien]

Hi,

Thanks for your help. And sorry for the mistake but I'm new in Linux world !

Best regards