Problem on sound speed

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem on sound speed

1,018 Views
victorien
Contributor IV

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 ?

Labels (1)
0 Kudos
31 Replies

397 Views
jörg_krause
Contributor III

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.

0 Kudos

397 Views
victorien
Contributor IV

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.

0 Kudos

397 Views
jörg_krause
Contributor III

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.

0 Kudos

397 Views
victorien
Contributor IV

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 !

0 Kudos

397 Views
CarlosCasillas
NXP Employee
NXP Employee

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

0 Kudos

397 Views
victorien
Contributor IV

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.

0 Kudos

397 Views
jörg_krause
Contributor III

Hi,

do you like tho share your investigations? Many thanks!

0 Kudos

397 Views
victorien
Contributor IV

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 !

0 Kudos

397 Views
jörg_krause
Contributor III

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?

0 Kudos

397 Views
jörg_krause
Contributor III

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

0 Kudos

397 Views
victorien
Contributor IV

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

0 Kudos

397 Views
jörg_krause
Contributor III

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 :-)

0 Kudos

397 Views
fabio_estevam
NXP Employee
NXP Employee

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

0 Kudos

397 Views
jörg_krause
Contributor III

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

0 Kudos

397 Views
fabio_estevam
NXP Employee
NXP Employee

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.

0 Kudos

397 Views
victorien
Contributor IV

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 ?

0 Kudos

397 Views
lategoodbye
Senior Contributor I

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

0 Kudos

397 Views
victorien
Contributor IV

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 ?

0 Kudos

397 Views
lategoodbye
Senior Contributor I

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

0 Kudos

397 Views
victorien
Contributor IV

Hi,

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

Best regards

0 Kudos