• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category Drivers
  • Assigned To No-one
  • Operating System Another
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.6
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by saratoga - 2010-06-06
Last edited by saratoga - 2010-06-24

FS#11364 - AS3543 volume increase

Volume tests of RB, the OF, and different amp settings are here:

RMAA tests driving a load for the OF, RB and various settings are here:

Specifically, these two entries for the current SVN build and the patched one:

The AS chips use a two step volume control with separate levels for the DAC and headphone amp. This patch increases the DAC volume 7dB. So basically, +6dB in the current build (which does not distort) becomes 0dB in the patch (which also does not distort). The new +6dB corresponds to actually over driving the amp, and does distort (but probably not enough to notice in real music verses a full scale test tone).

Interestingly the OF can drive as loud as our new +6dB with very little distortion, which might suggest we don’t have one of the voltages set right somewhere. If we ever get a JTAGed as3525v2 player it would be great to dump the AS3543 registers.

Closed by  saratoga
2010-06-24 01:15
Reason for closing:  Accepted
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Committed as r27101.

ranma has jtaged Clip+ but I’m not sure if he could run the OF yet since the internal storage is broken

Perhaps the difference in volume comes from using microphone/FM/PCM muxing?

I only have my sound card line in to make recordings, is it enough to compare clip+ with clipv2 and fuzev2 ?

A typical line in should be fine. Although if your sound card is very poor like mine the SNR figures may not mean much, the THD measurements should still be good.

That said, even with this patch, the THD is still nearly 0 at 0dB, and surprisingly low even at +6dB, so I don’t see figuring out exactly what the OF does as all that important.

Perhaps it would be simpler to define something to 0x1b/0×16, and just use that define in the conditions?

I measured OF / RB / RB with 0x1b with emu0404usb and portable multimeter.

Attached files are RMAA data. RB’s IMD at low frequency is not as good as OF, but it seems, 0x1b with +6db have steel good performance.

Measured volume level is,
OF : 0.546V
RB with 0x1b : 0.310V

Thank you for this great work.

Was this with my patch or did you just edit the code yourself?

It is your patch with no modification. I applied with patch with slitly modified latest RB(26809 +  FS#11364  - AS3543 volume increase + FS#11297_as3525v2-cpufreq-v10.diff).

All test was with Maximum volume (RB with +6).

Did you confirm that the final volume was louder then SVN?

I tested unmodified RB, too. It’s volume level was 0.310V.
It seems something wrong with my test. I’ll test again with clean RB with this patch only.

No that makes sense. Looking at the code I wasn’t sure if this actually boosted the volume or just raised the DAC volume and lowered the amp volume by the same amount. I think the volume scale needs to be changed so that +6 in the current build becomes 0 dB and you can go to what used to be +12dB.

I tested clean RB (26832) with this patch.

Both clean RB and patched RB have 0.310V of max volume (at +6). The result comes different with your test results.

Is this patch need to sync?

dfkt commented on 2010-06-16 14:59

I’ve tested this patch against the other variants suggested by Funman and Timar, and against the default build. Results are unexpected:

nickp commented on 2010-06-17 01:47

Here’s a patch against r26873 that includes Funman’s suggested method of only altering the mix_l/ mix_r values;

I used value 0x1b and kept Saratoga’s “if CONFIG_CPU == AS3525v2” condition, but thought I’d stick this around just the mix_(l|r) values.

These are the results I got by playing a normalised white noise file on the Clip+ at maximum volume/ +6db, recorded using an M-Audio Audiophile 2496, from Cooledit Pro’s “statistics”.

				Peak		Average
				Amplitude	RMS

Original WAV 0 -9.42
Original Firmware -5.6 -16.71
Trunk (r26873) -10.36 -21.515
All 0x1b * -11.64 -22.89
mix_lr 0x1b -4.415 -15.395 * vol1.patch

RMAA tests can be found below. I tried to include results for the trunk build, but I gave up as RightMark seemed to be having problems with the output.

This is just the patch posted on ABI a couple weeks ago with my comments from the above patch. See the ABI clip+ thread, it screws up the volume because it doesn’t change the volume in the if (vol_r ⇐ … line like the patch I posted above does. Try scrolling from low volume to high volume and you’ll see why thats a problem.

Since you’re actually increasing the volume range 6dB, you need to change rockbox to go from a volume of -72.5 - +6dB to -88dB - +6dB, otherwise you’ll get that weird jump in volume.

Nick Peskett’s modified patch was worked. It gives more vol than OF to sansa clip+.

OF : 0.546V (MAX)
RB with nickp’s patch : 0.66V at +6, 0.369 at 0

And I checked clipping problem with DSSF3’s software oscillator.

OF shows clipping at 0.546V. But at 0.324V, OF doesn’t clipped. More than 0.324V, OF shows clipping.
RB doesn’t clipped still 0.369V (0).More than 0.369V, RB shows clipping.

With nickp’s patch we can have more volume with no clipping(0.369V) than OF(0.324V).

But nickp’s patch gives same vol at 0 and 1 (0.369V). Maybe this problem should be corrected.

nickp commented on 2010-06-17 04:56

Ah yes, I’m noticing the jump between -40 & -39. I see it mentioned in the ABI thread now, sorry.

My headphones aren’t very sensitive, so had never ventured down that low.

Yes, the patch I uploaded is entirely derived from the postings on the ABI thread (mainly timar, dfkt, funman & saratoga), but mainly I found snippets of code rather than a patch, so thought I’d post something here for people looking for a simple volume boost patch (seemed a better place). I seem to have added to the confusion though!

Heres a quick and dirty attempt. Not sure if its correct, but it does scale the volume continuously and I think its louder.

Edit: this will also break on the AMSv1 players, but its a start.

nickp commented on 2010-06-17 06:01

Your clip_vol_v2.patch looks (and sounds) pretty good.

Loudest results so far using the white noise clip I tested earlier;

Peak Amplitude: -4.06 dB (OF: -5.6dB)
Average RMS: -14.85 dB (OF: -16.71dB)

No noticeable degradation in the RMAA tests (newest patch is Vol V2);

Pressing “down volume” button ~1 sec, from 6db to -72db;

I tested again with clip_vol_v2.patch.
Now the volume level goes up to 0.69V(+6, clipping occured) and 0.369V(0,+1, clipping not occured)

But still volume level is not continuously down or up.
I found there are same volume section like, 0/1, -2/-3, -5/-6, -8/-9, -11/-12, -14/-15,,,,,, .
I checked this with DSSF3’s software oscillator. You can easily check with that program or other similar programs.

The DAC only has 1.5dB step sizes for volume. Is that what you’re referring to?

Yes. I think this problem occured because rockbox only support 1db volume control. If rockbox support 1.5db volume control, it’ll be perfect.

Cleaned up code and prevented changing non-AMSv2 targets. If no one else has any problems I’ll commit this version.

FWIW I think this could also be used to increase volume on AMSv1 targets, but I haven’t tried. Are they any louder in the OF then in Rockbox?

some things which might need change in as3514.c:
- audiohw_settings
- sound_val2phys?

I think sound_val2phys should be left alone since the DAC and HP amp volume don’t appear to touch the line in or mic paths. I’ve fixed the audiohw_settings table.

Tested for a couple of days on FuzeV2, works very well here.


Available keyboard shortcuts


Task Details

Task Editing