Tuesday, February 12, 2013

amixer vs alsamixer: Master channel

A convenient method to change the Master volume that I use is via a custom KISS bash script that essentially calls amixer. One curious observation I made was that the return value of amixer for the Master channel did not correlate with alsamixer. A small research reveals why:

from the alsa-devel mailing list:

The percentage in amixer has nothing to do with dB level.
It's just the percentage of the raw value range of that mixer
element.  Thus showing 89% is correct.  It's 10% down from 100%
(1% is because of the resolution of the raw values).

Now, alsamixer shows the percentage in a different way.  It's
explained well in the source code (alsamixer/volume_mapping.c), but
not mentioned in the man page, unfortunately.

* The mapping is designed so that the position in the interval is proportional
* to the volume as a human ear would perceive it (i.e., the position is the
* cubic root of the linear sample multiplication factor).  For controls with
* a small range (24 dB or less), the mapping is linear in the dB values so
* that each step has the same size visually.  Only for controls without dB
* information, a linear mapping of the hardware volume register values is used
* (this is the same algorithm as used in the old alsamixer).

The percentage representation in alsamixer corresponds to this
mapping, thus it's neither dB nor linear percent.

Original discussion is here:

The script itself:

##Amixer Script.
if [ $1 -eq 1 ]
    amixer set Master 5%+
    notify-send "Volume Increase +5%:" "Master Volume Level: $(amixer get Master | grep Mono: | grep [0-9]*% -o)"

if [ $1 -eq 2 ]
    amixer set Master 5%-
    notify-send "Volume Decrease -5%:" "Master Volume Level: $(amixer get Master | grep Mono: | grep [0-9]*% -o)"

#if [ $1 -eq 0 ]
#       amixer set Master toggle
#       notify-send "Volume Master Toggle:" "Master Volume Level: "


Running with arguments 1,2 or 0 increases, decreases or toggles(Mute) the Master channel respectively. I don't use the toggle segment thus its commented out.

Sunday, February 10, 2013

Linux in 2013, systemd, kernel regressions etc etc...

It has been a very busy time for me, exams on one side and setting up Arch all over again on the other. Somehow I got upto 70% of the work done reinstalling, configuring, rewritting and theming but thankfully the worst is out of the way. I know that because before I reinstalled Arch, I assumed a lot of things about the procedure from earlier experience but the reality was close to shocking, see below.

1. Arch installer removed, all steps are to be done by the user.
2. Bye sysvinit! Hello systemd
3. Kernel Power Regressions. !!
4. HDD APM Issue. !!
5. Openbox updated to 3.5
6. Kernel Ver. @ 3.7.6
7. Since I had newer hardware with dual GPUs [Hybrid Graphics/Optimus], I had to rewrite conky and many scripts due to many low level changes.

Now Im not saying that all of this was bad, actually upgrades like systemd were much of a welcome, anyway what follows is a rundown of each and what I did to counter/resolve the issues.

1. Not much of an issue actually, to be honest, I liked the fact that the installer now required the user to customize manually. Helps in the optimization of the system also as a secondary bonus, the packages installed are always the latest since the new installer "pacstrap" downloaded the latest package versions as compared to installing directly from the Live Media.

2. This was a big surprise, whatever I knew about the original rc.conf sysvinit boot system had to be washed and relearnt with systemd in mind. Mind you, systemd is a boon! Bootup times have been slashed due to the efficient parallelization implemented which contrasts from the original init sequential boot proccess. Also systemd allowed for a much neater boot process modification and the entire start|stop sequence is much cleaner. Although it takes a while to get used to but once you do, creating your own service/tmpfiles becomes a breeze. Also syslogd is now replaced with a journel which can be accessed through the systemctl command. Actually all one needs to use is the systemctl command!

3. These "issues" are actually fixed in the 3.8.x RC versions which are yet to be tested and marked stable but we will get there. The issues Im talking about affect the sandybridge (and possibly ivy too!) line of CPUs. CPU frequency scaling gets locked at maximum frequency w/o turbo boost (Thank god!). In my case (2670QM) the scaling clocks reported to be the lowest clock possible: 800 MHz, but a look at the current clocks proved that they were actually stuck at 2.2 GHZ. Also, on the integrated GPU end, RC6 (powersaving) state was not being initialized. What really frustrated me further that temperatures were 10-15 degrees (Celsius)  higher than in Windows. This tends to happen randomly per boot and will be fixed once 3.8 is available as stable. Tip: If you cant wait, check the links at the end of the post for RC(Release Candidate) versions of the kernel.

  #] cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

 #] cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq

4. This was the most annoying/frustrating issue I have ever had. Not because it was difficult to fix but because of the everlasting effect it may have had on my HDD. Before I say more, understand that its not really Linux's fault, read on. Long story short,  2.5" HDDs implement shady power saving mechanisms such as head parking and spinning down the spindle motor during an I/O idle session. Furthermore the smart brass at WDC decided to choose power saving over HDD lifespan. How they achieved this was by implementing something called intellipark, which essentially parks the head whenever it senses that I/O is idling. Sometimes this is done in less than 8 seconds. What this results in is a constant "clicking" sound from the HDD and the slow but eventual degradation in head quality which could lead to HDD failure. If that is not enough, the slowdown of the spindle motor puts pressure on it because to spin up the motor for an I/O active session it requires throwing in more power and not to mention stresses the motor further (Newton's first law!).

12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       455
193 Load_Cycle_Count        0x0032   155   155   000    Old_age   Always       -       136465

Checking SMART data on the HDD showed that the current LOAD_CYCLE_COUNT (Number of parks) had jumped to 136465 in less than a year. To put this in perspective, an average 2.5" HDD has a lifetime of 300000 - 600000 parks. Way to go WDC!

 I would also like to add that a similar but slightly less annoying effect was also visible when running Windows 7. Thankfully Linux has a tool [hdparm] which allows modifying many variables on the HDD directly such as the APM(Advanced Power Management) value. My original value was 96, which then I changed to 254 to basically kill all possible forms of APM. Did it work?

Yes! :-)

5. Not new and also not much of an issue, openbox 3.4 config is a drop in replacement for 3.5.

6. Kernel is currently at 3.7.6, nice and fast with major fixes but with the power regressions.

7. As previously mentioned in an older post, this was somewhat of a new laptop, modifying old scripts/configs took some time, had to scale conky config and other scripts to take into i7's quad cores plus inclusion of NVIDIA GPU temperature monitoring thanks to the free nouveau driver which enabled basic power management.

Optimus is still not a fully functional componenet in Linux but thanks to projects such as bumblebee, enabling hybrid graphics support was relatively easy.

So thats pretty much it, Im looking forward to checking out how tools such as Metasploit, Nmap etc have improved.

Any questions/comments... insults??


Kernel Power Regressions: 
: https://bbs.archlinux.org/viewtopic.php?id=150743  //RC Versions in this thread
: https://wiki.archlinux.org/index.php/Intel_Graphics#Module-based_Powersaving_Options

HDD APM Issue: 
: https://bbs.archlinux.org/viewtopic.php?id=39258
: https://wiki.archlinux.org/index.php/Hdparm#Parking_your_hard_drive
: http://en.wikipedia.org/wiki/S.M.A.R.T.#ATA_S.M.A.R.T._attributes
: http://forums.anandtech.com/showthread.php?t=2085685

: https://wiki.archlinux.org/index.php/Systemd

Sunday, February 3, 2013

There and back again....

Went from Fedora > Ubuntu > Fedora > Arch > Fedora > Arch(Incomplete setup) > M$ Bulldows. Been so busy lately that haven't used linux in 6 months! Arch is a pain to setup again (don't get me wrong, its a great distro and my fav.) so I guess I will finally go back to where I came from.... Fedora.

Current release => Fedora 18

Downloading right now!

EDIT: Nope... F18 sucks (Check below)... thankfully i did a little research... I guess the universe wants me to stick to Arch, Its better to set things up the way you like them and not letting some company or a group of people decide.

Src: http://www.dedoimedo.com/computers/fedora-18-kde.html
Src2: http://linux.slashdot.org/story/13/01/23/230255/alan-cox-fedora-18-the-worst-red-hat-distro-switches-to-ubuntu