RMAA results of Clip+ with updated PMU initialisation

[bertrik]

In an attempt to fix the bug of unstable USB connection on sansa AMSv2 targets, I looked a bit closer at the initialisation of the PMU (power management unit) in the AMSv2 players and created a patch to use the same settings as the sansa original firmware.

You can find the patch at:
http://www.rockbox.org/tracker/task/11664#comment40611

It's not really clear yet if the new PMU settings make much difference regarding the USB problems, but it does have an effect on the audio performance. The new PMU settings increase (among other things) the internal voltages used by the analog parts from 1.7V to 2.5V, for example the D/A converter voltage.

dfkt has been so kind to make RMAA graphs, with and without the patch:
"Here are some RMAA tests for Bertrik's PMU init patch, compared to a default build. The PMU init test without load looks a bit weird for the left channel - I repeated it twice to make sure the results are correct. The 16 Ohm one looks fine, however. This sure boosts the volume closer to Sandisk's stock firmware - very nice!

http://rmaa.elektrokrishna.com/index.php?dir=Temp/&file=Clip%2B%20Rockbox%20stock%20vs.%20PMU%20init.htm
http://rmaa.elektrokrishna.com/index.php?dir=Temp/&file=Clip%2B%20Rockbox%20PMU%20init%20-%20no%20load.htm
http://rmaa.elektrokrishna.com/index.php?dir=Temp/&file=Clip%2B%20Rockbox%20PMU%20init%20-%2016%20Ohm.htm
"
If you want to comment on the audio quality effect, please do it here in the forum, not in the flyspray task (that one is dedicated to the AMSv2 USB problem).

[dfkt]

The volume difference of over 4dB between stock SVN and the patch is too high for RMAA to analyze, so I had to pre-amp the quieter version. In reality, the SNR and noise floor difference between the two should be bigger than shown in these RMAA tests.

[bertrik]

To elaborate a bit, the patch actually changes several things at once:

1) the audio PLL in the codec is forced on.
This setting appears to be a bit silly, because we already supply a different audio clock through MCLK.
Our current default is "auto" mode for the PLL, but I've verified that playback still works even if we disable the PLL.
Disabling the PLL might save a bit of current and so increase runtime with no adverse effect.

2) The switching speed of the CVDD power supplies is lowered from 2 MHz to 1 MHz.
Our current default is 2 MHz, playback apparently works either way. I can imagine that a 1 MHz switching speed slightly lowers power consumption.

3) drive current for the 24 MHz and 32 kHz clock outputs is reduced from 6 mA to 1 mA.
This could reduce interference in theory. I guess it makes very little difference but it probably doesn't hurt to use the OF settings either.

4) decrease the threshold for USB VBUS voltage detection from 4.5V to 3.18V.
Not sure about this one, perhaps some USB hosts provide a voltage that is close to the 4.5V threshold.
I think it won't hurt to set it at 3.18V.

5) increase the PVDD1 and AVDD17 voltages from 1.7V to 2.5V
Voltage PVDD1 can be used as a supply for peripheral logic. Voltage AVDD17 supplies the analog parts (like the D/A converter) and this setting probably has the most impact on audio performance. The datasheet shows slightly improved S/N performance and higher full-scale output levels for high voltage vs. low voltage. I can imagine that this comes at the cost of slightly reduced battery runtime.


My proposal is:
a) explicitly switch off the audio PLL (setting 1)), contrary to the OF setting, since it's not needed and disabling it might save a little power.
b) copy settings 2), 3) and 4)
c) measure runtime impact of voltage increase of setting 5) and make a decision based on this

[keyb_gr]

^ Sounds like a plan.

Re: 1), that might explain part of the somewhat odd RMAA results. Almost looks like only one channel is running on the PLL or something. Hence, codec config seems somewhat messed up. Which of the lines would I need to throw out (didn't check the datasheet now)?

Re: 2), that's what I'd expect, too.

Re: 3), disk access noises did seem pretty inconspicuous on my SE420s at first listen. Now I don't have any super high bitrate files on there (LAME -V 6 to -V 4 MP3 only), so further testing by those using FLAC is recommended.

Other observations: Occasional ugly high-frequency cracks upon resuming playback, esp. left channel (codec init?). Power-off pop noise seems significantly reduced, only a soft pop on HD590s now.

EDIT:
OK, a look at the datasheet allowed me to document things and switch PLL mode to auto...

Code: [Select]

+#ifdef SANSA_CLIPPLUS
+  /* see AS3543 DS p.55/91 */
+    ascodec_write_pmu(0x1A, 7, 0x00); /* PLL */
+    ascodec_write_pmu(0x17, 7, 0x30); /* DCDC_Cntr */
+    ascodec_write_pmu(0x1A, 2, 0xCC); /* 24M/32k osc drive */
+    ascodec_write_pmu(0x19, 2, 0x41); /* CHGVBUS2 */
+    ascodec_write_pmu(0x18, 1, 0x35); /* PVDD1 */
+    ascodec_write_pmu(0x18, 7, 0x31); /* AVDD17 */
+#endifNo idea why PVDD1 is also increased in value.

My Clip+ sounds fine like that, power-off pop noise remains low on both HD590s and powered speakers (where it used to be quite loud). The high-frequency cracks at init still appear once in a while, not sure whether they weren't present before.

I'd hope measurements would be OK now. The oddities might have been related to the notoriously picky headphone jack anyway.

Bertrik, my ears are thanking you already. I went through the shutdown code a while back, trying to find a cause for the stupid loud power-down pop noise in vain. It appeared whenever the headphone amp was turned off. Looks like pop noise suppression circuitry needs a higher supply voltage in order to work well.

[keyb_gr]

I have now compared my Clip+ both with the patch as shown above (i.e. PLL: auto) and without (otherwise same 30404M + FS#11304 build).
Results
The difference pretty much boils down to the expected higher output level and somewhat increased distortion as a result. No oddities or anything.

Line-in: Aureon Sky w/ Prodigy 7.1 driver, maybe not the cleanest input ever but OK.