Version: (using KDE KDE 3.5.0) Installed from: Gentoo Packages OS: Linux Now lirc-regulated volume step is 4%. Two considerations are here: 1. The "percent" term says nothing. I think, more suitable and standard to use decibel scale, say form -60db to 0db (low boundary may be configurable: -100db, -80db, -60db, -40db, for example). Even users without knowledge about db are familiar with this term via AV-receivers, other players and so on. 2. Current 4% is very big step. Volume lirc control is repeating, and overall volume change speed is very high. Let's make a step equal to 1%. Or, which is final and blameless :-), 1db.
> 1. The "percent" term says nothing. I think, more suitable and standard to > use decibel scale, say form -60db to 0db (low boundary may be configurable: > -100db, -80db, -60db, -40db, for example). Even users without knowledge > about db are familiar with this term via AV-receivers, other players and so > on. I don't think this would be feasible for a number of reasons. Firstly, amaroK uses software mixing. Hence, we could never actually have an accurate representation of the power output of the signal. Here is an example where the percentage is appropriate. Put your volume slider to 50%. Now open kmix (or your favourite mixer), and change the volume. the music output has changed. Imagine if we had a label which said -30dB. It would be inaccurate the moment an external source played with the hardware volume mixing. Secondly, whilst decibel is certainly more accurate for audio output, i don't believe it to be as user friendly. There would be too many users who would find the value meaningless (let alone to confusement as to a negative value). Thirdly, I would imagine this to be engine specific, which is crap! dB calculation requires the value of outputted power - can we even get this value?! The only problem I can think of with percentage value, is that percentage is a linear scale, whilst our volume is logarithmic. Not so consistent (or accurate). I hope you can relate to why I am going to close this bug. But maybe somebody has a better argument for/against. Thanks! Seb
Seb, Thank you! - you have found a time to give such detailed answer. Nevertheless, I'll try (with my ugly English) to find "a better argument for" :-) 1. Consistency between amaroK lable and actual sound card output. It isn't our goal. Imagine audio devices chain: source, preamp, power amp. Every the chain item can have own volume regulater. It isn't a problem. 2. "Decibel for user". I'm sure there isn't any user without knowledge about a decibel as "something related to audio". From this point there isn't any difeerence which scale/term to use - "decibel" or "percent". Such audio giants like Yamaha think it's beter for user (and business) to use decibel scale even for _home_ Audio-Video devices (my RX-V540RDS receiver has decibel scale - not for volume only: all level tunings have this scale). And, at last, for such excellent development team (excellent app has excellent team by definition :-)), I think, it is extremely easy to give to user a choice which scale to use. And - another opportunity is: to use the only db scale, but (by default or optionally) show lables "0".."100" instead of "-100db".."0db". 3. Engines. Ah... Have they undetermined level values? I'm not C/C++ developer (server-side java programming), but I can not imagine any highly spreaded audio engine without strictly specified volume regulating interface. Is my imagination too optimistic? :-) 4. Whell, what about volume step reducing? It seems, like we have forgot about it :-) Probably, another whish must be reported, and only from my (as user) point of view these parts (db scale and volume step) are related. P.S. Of course, I'm not going to reopen the whish: at any case I'm very appreciative to the amaroK development team. Thanks! Whith hope, Andrew
I too yearn for a decibel-labeled volume scale. I think Seb overlooked how decibels are useful for, as it is precisely fitting such volume scales as the software volume factor amarok applies to the audio signal. Andrew already explained gave good argument for it all. 0dB really is another way to say 100%. for any value, say -8dB, the corresponding attenuation is obtained by multiplying the audio values by pow(10, -8/20). It *is* user-friendly because the resulting scale is actually natural (a linear scale on sound levels doesnt match our ear's perception of 'how loud' a sound is). Most (if not all) volume knobs on audio devices are in fact using fixed decibel steps (it would make no sense to have a linear scale), even when it does not explicitly mention 'dB' anywhere. For instance, I measured all the volume steps of my DAP (a rio karma), and it turned out they're all precisely 2dB increments. And the volume knob on my amplifier definitely follows a logarithmic scale too. I'm pretty confident I could write a patch to turn the volume into a logarithmic scale (i.e., decibles), if there were a good chance to get it committed.
Created attachment 15312 [details] patch to xine and gst engine, making the volume scale use decibels mostly proof of concept, but already functional. (except it doesnt cover all engines, nor consequences to crossfade / equalization)
I wrote the patch above when I started tweaking amarok_replaygain.py, as I needed to have some kind of consistency in the volume scales. Obeying the constraint that m_volume is an int, set in the range 0..100 by the GUI, I used the following mapping to decibels : db = 0.5*percents -50 ( => range -50dB to +0dB. I'd prefer -40dB +10dB, so that very low tracks could be pushed a few dB up by replaygain, but I tried it and it seems the xine-engine caps its amplification factor to 1.00, so positive gains only had effect with gst) BTW I monitored my output, and did observe -1dB decrease every 2 percent decrement on the slider, as should be, so it does prove the concept :) this patch could be generalized to the remaining engines and committed as is, though IMO if the decision to switch to decibles is made, it would be preferable to change the setVolumeSW API function interface so that the gain (in decibels) is passed around as a double, rather than a ambiguous troublesome integer in 0..100, completely tied to GUI choices...
Samuel, I have tried the patch - it works! Thanks! Are you going to modify UI/OSD controls too? :-) ________________ Will anybody from development team reopen the issue?
Just want to inform, I use Samuel's patch all these days. It makes amaroK using much-much-more handy! Especially it is clear with lirc. Volume changes are predictable now. Even without UI-controls (to db scale) modification. Reopening the issue, as the patch (IMHO) has proved the concept.
Samuel, It seems like the patch doesn't suit to the current SVN state. Will you be so kind to modify the patch? Now, without the patch applied, the patch benefits are more obvious for me ;-)
Aha... Have found: enginebase.cpp and enginebase.h files were moved one dir up.
Have found starnge fragment in the enginebase.cpp file: "We're using a logarithmic function to make the volume ramp more natural." Simply ALL people experience (not saying about ALL psychoacoustics researches) says about exponential curve. As a workaround I use this patch: --- enginebase.cpp.orig 2006-08-10 02:33:07.000000000 +0400 +++ enginebase.cpp 2006-08-11 00:51:10.000000000 +0400 @@ -46,5 +46,5 @@ { // We're using a logarithmic function to make the volume ramp more natural. - return static_cast<uint>( 100 - 100.0 * std::log10( ( 100 - volume ) * 0.09 + 1.0 ) ); + return static_cast<uint>( 100.0 * std::pow( 10.0, (volume-100.0) / 40.0 ) ); } It is a workaround rather a fix because integer scale up 100 is in use, and values below a level "20" (-40db, sptep is 0.5db) are rounded to zero.
Sorry folks, but Amarok 1.4.x is not maintained anymore
well, amarok 2 doesn't use a decibel scaling either
(In reply to comment #12) > well, amarok 2 doesn't use a decibel scaling either Then could you please open a separate wish, please? As the code base of Amarok 1.4 and Amarok 2 are totally different, it makes no sense to keep this open. Thank you.
Myriam, is it possible to move existing votes for the bug to newly created one? If it isn't so, I can not understand the way the issue was "resolved". The issue itself doesn't depend on codebase - resolving the issue in code does only.
(In reply to comment #14) > Myriam, is it possible to move existing votes for the bug to newly created one? > If it isn't so, I can not understand the way the issue was "resolved". The > issue itself doesn't depend on codebase - resolving the issue in code does > only. Amarok 1.4 is not maintained anymore, and nobody will ever filter for 1.4.x bugs or wishes, as those are not relevant anymore to the current workflow. Also, this wish refers to a patch which is not usable in Amarok2 as such, hence it makes no sens to keep this open. Please file a new wish against Amarok 2.1.
Done: https://bugs.kde.org/show_bug.cgi?id=195558