First -- greetings to all. This is my first post, so I thought I would use this as an opportunity to extend a thanks and kudos to those who have worked to develop and improve Rockbox. It seems to be an active project perpetually improving.
Now to business

After having tried using the compressor I stopped using it because it takes away clarity and causes music to sound wooly.
I have looked into the code and created a laundry list of ideas to help improve the clarity of the sound:
1) Attack time parameter.
>> Currently the attack time is 0ms, or rather, a leaky peak detector. This clips an onset and smears transients.
2) Sidechain EQ. Application of sidechain high-pass filtering similar to what is found in the JoeMeek compressor will help reduce compression on low frequency material thereby reducing distortion and preserving high-frequency content.
3) Exponential attack & decay characteristic. This will require a first order digital filter (y[n] = a*x[n] + b*y[n-1]) creating two multiplication terms as compared to the single addition for linear release. However, the linear release sounds very mechanical to my ears.
(1), (2) and (3) are a bare minimum for an industry standard compressor.
(4) Delay line for a certain amount of look-ahead compression. I'm thinking attack times of 5ms to 20ms and a delay line on the same order of magnitude, so it will not be a severe memory hog.
I am working slowly on coding some of these things myself, but certainly I will need to take more time to learn how the rest of the system treats settings and the user interface. The only "new" thing added to the user interface would be Attack time parameter, so it should be pretty simple. The rest would be hard-coded, automagic (unless people started requesting EQ presets for the sidechain). I think selecting an EQ curve and hard-coding it will be more than adequate to improve clarity.
I have hard-coded the linear attack at 15ms, and this makes a difference in the clarity of the transients, enough that the compressor is tolerable enough to use. Of course, there will be clipping when the transient exceeds 0dB, but it's much more transient headroom than the current algorithm.
I would like to make sure if the original developer of the compressor is reading this that it is clear that I think it is a well-written piece of code -- things are done very efficiently and it does not waste hardware resources. I am suggesting features that will push the hardware requirement/performance balance more in the direction of performance.
Of course, even if these suggestions are never implemented in the distribution of Rockbox, one can be assured I will always have a compressor that is perfect for me, so thanks for the giant shoulders on which to stand