On Thu, 05 Nov 2009 14:55:30 +0000 Liam Girdwood <lrg@xxxxxxxxxxxxxxx> wrote: > I've reworked this myself now. It does appear that the current FPER > calculations assume BCLK scales with rate > > i.e. BCLK = rate * channels * word len > > This is fine for when McBSP is FRM/BCLK slave (all users except pandora) > as FPER should be ignored internally. > > However, when BCLK is constant (e.g. McBSP BCLK derived from constant > source) and we run McBSP as FRM/BCLK master we currently break our > sample rate generation. > This is true, currently possibilities to get standard sample rates as accurately as possible when using McBSP as a master and when using fixed sample rate generator input clock (CLKSRG) are too much limited. So the period size adjustment is a good improvement. CLKSRG can take its input from internal fixed 96 MHz, CLKS pin, CLKR pin, CLKX pin or internal interface clock (proprotional to CPU freq). > Imho, it's better to generate FPER based upon BCLK and rate. e.g. we > calculate the frame size required for the given BCLK and rate. > Yep. Actually BCLK doesn't have to be fixed as it is derived by dividing the CLKSRG with CLKGDV. This can allow to optimize the BCLK and frame size to be smaller when CLKSRG >> BCLK. Would be nice if both the divider and frame size are calculated dynamically based on CLKSRG frequency and sample rate. > I'm now slightly curious about how pandora handles different rates since > it uses the McBSP in master mode too. I guess they can only handle a > single sample rate ? > IRCC correctly the external master clock used in Pandora was derived from the codec and that clock was following the sample rate. -- Jarkko _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
