From Vim to Emacs+Evil chaotic migration guide

From Vim to Emacs+Evil chaotic migration guide

I've been using Vim for 18 years, and for me it was the only option for serious text work (like programming or writing) because I'm totally addicted to modal text editing to the point that I feel crippled when I've to edit text in a non-modal editor. You may argue that programming is not about how fast you write and you would be right, but if you can imagine somebody programming on an on screen keyboard on a tablet, you know how modal editor users feel about non modal edition.

But as many Vimmers, I was always curious about Emacs (the enemy in the editor flamewars!), it's operating-system-in-a-window and the Lisp virtual machines concepts but the non-modal editing and the low quality of the existing modal editing modes compared with Vim made me keep a sane distance from it.

But then, Evil-mode happened. Evil mode is being developed as a perfect Vim emulation for Emacs. Some of its developers have publicly stated that Vim is the model and if something works differently than in Vim it should be marked as a bug. I've been hearing very good things about Evil-mode, and when some of my old Vimmers contacts made the switch I knew the mode should be very good.

So two weeks ago I installed Emacs and Evil and started to configure everything to my liking. My first objective was to have an editing environment as efficient as the one I've in Vim, with the same plugins and shortcuts. I didn't expected to really reach that point in a long time, because I heard than Emacs has less plugins than Vim and I expected to have a hard time creating my dotfiles using Elisp. After two weeks of intense investigation, googling, Elisp accelerated learning, reading of other people's dotfiles and tinkering I can say that I was very wrong. Not only I've an environment where I didn't lost almost anything to my highly-tuned Vim, but I also got gains in some other areas (and I still haven't started to play with the famous Org mode or Gnus).

This article is a pretty chaotic recollection of bits about how I turned Emacs into my Vim, and then how I improved over it. Most of the items will be bits of Elisp code for the config file or info about plugins. My hope is that this article will be useful to other Vim power users trying Emacs+Evil because I would have loved to find an article like this when I was starting.

This article has been written with the help of lot of random people whose configs, articles an answers I had the luck to land after some internet search, mostly from StackOverflow, GitHub, and random forums. To keep the article clean, I don't always cite the source of the snippets but you could easily find most of them just googling the code.

You can also check my Emacs' dotfiles if you're interested, but remember that these are newbie dotfiles so I'm probably doing something stupid on them. As you'll see, my config is split between several files. I advise you to don't do this from the start, but to dump everything into your .emacs file because it is easier to experiment and change a lot when you're starting (and if you're a little like me you'll be playing a lot with your config) and once you've more or less settled on a config, split it into categories. Oh, and keep Vim at hand to fix your Emacs config the several times you'll broke it.

A good Windows version

I've to use Windows at work and I was having a lot of problems with the official version of Emacs for Windows (slowness, unstability, huge memory usage spikes...). Reddit's user tuhdo read about my woes and suggested two versions of third party packages of Windows Emacs. I've tested both and I can say that this one is definitively the best and solves all my problems.

Basic Emacs survival keys

If you're a Vim user after installing Evil you'll be using Vim-style commands most of the time, but to install Evil first and for some modes where Evil doesn't work (like the package manager) you'll need some basic cheatsheet of Emacs commands.

  • C-g (that is Control and g at the same time) to cancel prompts. Later we'll remap the escape key to do the same which anyone coming from Vim will need to retain its sanity.
  • C-x k to kill (close) a buffer. Automatically opened windows are usually closeable with "q".
  • C-x o (that's an "o" not a zero) to rotate between window
  • C-x 2 to create an horizontal split (window)
  • C-x 3 to create a vertical split
  • M-x (M = Alt on PC) shows the "minibuffer" where you can call Emacs functions. Later I'll show how to improve it a lot.
  • To toggle long lines wrapping (like set wrap/nowrap in Vim), do M-x visual-line-mode RET.
  • C-y: yank/paste. The only way to paste on the modeline even when you're using Evil.

Package management

The integrated plugin (package in emacspeak) manager is pretty good. It lists, downloads, updates and install the packages in a breeze. I've tested almost all of Vim's plugin managers and neither of them is close to this. You start it with M-x list-packages (enter to install, d to delete, x to execute deletions).

To add more sources to the package managers and to have a function that will load packages and install them if missing (useful if you move your config between computers) put this on your config file:


;; packages
(setq package-archives '(("gnu" . "http://elpa.gnu.org/packages/")
                         ("org" . "http://orgmode.org/elpa/")
                        ("marmalade" . "http://marmalade-repo.org/packages/")
                         ("melpa-stable" . "http://melpa-stable.milkbox.net/packages/")))
(package-initialize)

(defun require-package (package)
  (setq-default highlight-tabs t)
  "Install given PACKAGE."
  (unless (package-installed-p package)
    (unless (assoc package package-archive-contents)
      (package-refresh-contents))
    (package-install package)))

Note: as Phil suggested in the comments, the non-stable Melpa repository is risky to have for newbies since it pulls directly from git master, I've used melpa-stable in the config example, if you want to use Melpa just remove the "-stable" from both the name and URL in the config.

Evil (Vim emulation)

It's fucking impressive. I don't miss any text command, operator, motion or work flow from Vim. Marks, paragraph reformatting, visual mode, visual block, macros, registers, text objects, splits (vertical, horizontal, :normal, folding, etc)... it has almost everything.

Of course Vim plugins doesn't work, but there are Emacs or Evil alternatives for most of them.

Themes

You can use M-x load-theme RET to check the available themes (you can install more with the package manager). Once you have chosen one theme, put in .emacs: (load-theme 'misterioso t).

Terminal Colors

By default, most themes look like shit on terminal Emacs (emacs -nw if you don't want the window to open). On Vim some themes too, but in Emacs this happens with almost all of them. This can improve a lot installing the color-theme-approximate package with makes the same thing as CSApprox in Vim: translate colors to their console equivalents. Once installed add this to your .emacs: (color-theme-approximate-on). If it doesn't work try to put the line lower in the .emacs file (it happened to me). If everything still look like shit check that you have the correct TERM environment variable set (hint: is different inside screen or tmux).

Change cursor color depending on mode

This is something that I liked to have in Vim. Fortunately, you can also have it in Emacs. Unfortunately, I've been unable to get in working on non-GUI emacs:

(setq evil-emacs-state-cursor '("red" box))
(setq evil-normal-state-cursor '("green" box))
(setq evil-visual-state-cursor '("orange" box))
(setq evil-insert-state-cursor '("red" bar))
(setq evil-replace-state-cursor '("red" bar))
(setq evil-operator-state-cursor '("red" hollow))

Tabs

If you install the evil-tabs package and enable it with (global-evil-tabs-mode t) you'll have :tabnew, gt and friends with numbered tabs by default. Showing the tab number is a very useful feature when you can change to a tab with #gt like in Vim (with # being a number from 0 to 9), but unfortunately this package doesn't support #gt but I worked it around with my awesome Elisp skills (close to zero):

(define-key evil-normal-state-map (kbd "C-0") (lambda() (interactive) (elscreen-goto 0)))
(define-key evil-normal-state-map (kbd "C- ") (lambda() (interactive) (elscreen-goto 0)))
(define-key evil-normal-state-map (kbd "C-1") (lambda() (interactive) (elscreen-goto 1)))
(define-key evil-normal-state-map (kbd "C-2") (lambda() (interactive) (elscreen-goto 2)))
(define-key evil-normal-state-map (kbd "C-3") (lambda() (interactive) (elscreen-goto 3)))
(define-key evil-normal-state-map (kbd "C-4") (lambda() (interactive) (elscreen-goto 4)))
(define-key evil-normal-state-map (kbd "C-5") (lambda() (interactive) (elscreen-goto 5)))
(define-key evil-normal-state-map (kbd "C-6") (lambda() (interactive) (elscreen-goto 6)))
(define-key evil-normal-state-map (kbd "C-7") (lambda() (interactive) (elscreen-goto 7)))
(define-key evil-normal-state-map (kbd "C-8") (lambda() (interactive) (elscreen-goto 8)))
(define-key evil-normal-state-map (kbd "C-9") (lambda() (interactive) (elscreen-goto 9)))
(define-key evil-insert-state-map (kbd "C-0") (lambda() (interactive) (elscreen-goto 0)))
(define-key evil-insert-state-map (kbd "C- ") (lambda() (interactive) (elscreen-goto 0)))
(define-key evil-insert-state-map (kbd "C-1") (lambda() (interactive) (elscreen-goto 1)))
(define-key evil-insert-state-map (kbd "C-2") (lambda() (interactive) (elscreen-goto 2)))
(define-key evil-insert-state-map (kbd "C-3") (lambda() (interactive) (elscreen-goto 3)))
(define-key evil-insert-state-map (kbd "C-4") (lambda() (interactive) (elscreen-goto 4)))
(define-key evil-insert-state-map (kbd "C-5") (lambda() (interactive) (elscreen-goto 5)))
(define-key evil-insert-state-map (kbd "C-6") (lambda() (interactive) (elscreen-goto 6)))
(define-key evil-insert-state-map (kbd "C-7") (lambda() (interactive) (elscreen-goto 7)))
(define-key evil-insert-state-map (kbd "C-8") (lambda() (interactive) (elscreen-goto 8)))
(define-key evil-insert-state-map (kbd "C-9") (lambda() (interactive) (elscreen-goto 9)))

Somebody with better Elisp skills please help me with a less kludgy solution, but this works (and it's in fact one key press less than #gt).

Leader key

In order to define an use a <leader> prefix for your personal shortcuts you have to install the package evil-leader and put lines like these on your .emacs (I use comma as a leader key):

(global-evil-leader-mode)
(evil-leader/set-leader ",")

Later, I found that the key didn't work on some modes (like when editing the .emacs file in emacs-lisp-mode), but the package FAQ solved the problem, you have to add this before the global-evil-leader-mode setting:

(setq evil-leader/in-all-states 1)

Sessions (:mksession in Vim)

Emacs have the commands M-x desktop-save and desktop-read. To have it automatically saved/restored put into the .emacs: (desktop-save-mode 1). If you want to start emacs without auto loading the session (if you configured it), the command is emacs --no-desktop. But Emacs sessions doesn't know about elscreens (which evil-tabs use for creating Vim-like tabs) so if you want to save and restore full sessions including tabs copy these functions into your config file and assign them some shortcut:

;; Save session including tabs
;; http://stackoverflow.com/questions/22445670/save-and-restore-elscreen-tabs-and-split-frames
(defun session-save ()
    "Store the elscreen tab configuration."
    (interactive)
    (if (desktop-save emacs-configuration-directory)
        (with-temp-file elscreen-tab-configuration-store-filename
            (insert (prin1-to-string (elscreen-get-screen-to-name-alist))))))

;; Load session including tabs
(defun session-load ()
    "Restore the elscreen tab configuration."
    (interactive)
    (if (desktop-read)
        (let ((screens (reverse
                        (read
                         (with-temp-buffer
                          (insert-file-contents elscreen-tab-configuration-store-filename)
                          (buffer-string))))))
            (while screens
                (setq screen (car (car screens)))
                (setq buffers (split-string (cdr (car screens)) ":"))
                (if (eq screen 0)
                    (switch-to-buffer (car buffers))
                    (elscreen-find-and-goto-by-buffer (car buffers) t t))
                (while (cdr buffers)
                    (switch-to-buffer-other-window (car (cdr buffers)))
                    (setq buffers (cdr buffers)))
                (setq screens (cdr screens))))))

Accents

Accents didn't work for me on GUI mode, only in text mode. That was fixed adding (require 'iso-transl) to my .emacs.

"After" macro definition

I have an "after" macro defined that I copied from someone config file (can't remember who - sorry). This is useful to specifiy code to be executed after some plugin has loaded.

The definition is on my config file as:

;; "after" macro definition
(if (fboundp 'with-eval-after-load)
    (defmacro after (feature &rest; body)
      "After FEATURE is loaded, evaluate BODY."
      (declare (indent defun))
      `(with-eval-after-load ,feature ,@body))
  (defmacro after (feature &rest; body)
    "After FEATURE is loaded, evaluate BODY."
    (declare (indent defun))
    `(eval-after-load ,feature
       '(progn ,@body))))))

Vim-like search highlighting

I prefer how Vim's highlight search and left the highlighted terms until you make another search or clean the highlighted terms. I tough this would be easy to get but it turned it wasn't so easy (for me). At the end I made my first Emacs extension (and the first time I've programmed in Lisp since the university a long time ago...) so all turned well. The extension is already on Melpa has the very brief name of evil-search-highlight-persist. You can enable it with:

(require 'evil-search-highlight-persist)
(global-evil-search-highlight-persist t)

To map a shortcut (leader-space) to clear the highlights I have:

(evil-leader/set-key "SPC" 'evil-search-highlight-persist-remove-all)

I must note that another good way to search in Emacs is to use occur or helm-occur. This will show the search results on a list (on a split window with occur) and you'll be able to jump easily to any match.

Helm: Unite/CtrlP style fuzzy file/buffer/anything searcher on steroids

Helm does the same thing as Unite/CtrlP on Vim and does it really well. You can also enable Helm to manage the command buffer, which is pretty awesome with: (helm-mode 1) in the .emacs file. I also configured a shortcut in normal mode, SPACE SPACE which is the same I was using with Vim. This can be done with: (define-key evil-normal-state-map " " 'helm-mini).

But Helm can be really configurable and you can include or exclude modules in the helm interface show with the shortcut associated to your config, for example I've:

;; helm settings (TAB in helm window for actions over selected items,
;; C-SPC to select items)
(require 'helm-config)
(require 'helm-misc)
(require 'helm-projectile)
(require 'helm-locate)
(setq helm-quick-update t)
(setq helm-bookmark-show-location t)
(setq helm-buffers-fuzzy-matching t)

(after 'projectile
  (package 'helm-projectile))
(global-set-key (kbd "M-x") 'helm-M-x)

(defun helm-my-buffers ()
  (interactive)
  (let ((helm-ff-transformer-show-only-basename nil))
  (helm-other-buffer '(helm-c-source-buffers-list
                       helm-c-source-elscreen
                       helm-c-source-projectile-files-list
                       helm-c-source-ctags
                       helm-c-source-recentf
                       helm-c-source-locate)
                     "*helm-my-buffers*")))

Here, I define a "helm-my-buffers" function that when called (assign a shortcut to it!) will show Helm interface but searching (fuzzy, real time as you write, unordered) in open buffers, recent files, project files (see below for more on that), tags inside the files, tabs and results from the Linux command locate that searches quickly from a database of all the files in the file system. How awesome is that?

But this is only the tip of the iceberg of Helm power. There are sources for searching the symbols (functions, classes, globals, etc) in the current buffer (helm-imenu), bookmarks (including Chrome/Firefox bookmarks), HTML colors (showing the color, name, and hexadecimal code), apt packages and more.

If you check the sources of the helm-my-buffers function above you can see that I'm also using helm-c-source-projectile-files-list. This will use another installable third party package called Projectile that will search for a git/hg/svn file in the current directory and its parents and extract the current project files. Linking it will Helm makes it super easy to open any file in your current project (providing you've it under version control) without having the browse the filesystem, even for files that you have never opened (and thus are not in Emacs' recent files list).

Another good combination of Helm with a nice Emacs feature (this time included by default) is helm-imenu. iMenu is a pretty smart minor mode that extract "locations" inside a buffer. For code in a programming language this will be typically the classes, methods and other symbols. Calling helm-imenu instead of the default imenu will make it very easy to jump quickly to a location inside the buffer just writing a couple of letters.

Another great feature of Helm is the chance to replace the default "M-x" menu interface. M-x is what you use to issue Emacs commands, a little like ":" in Vim (but only a little, ex mode in Vim or Evil is another kind of animal). One great thing about Emacs is that it has commands and modes for a lot of things, and with Helm M-x you don't have to learn them all. For example if I don't remember how to show white space characters I just press M-x and start to write whitesp... and Helm will show me as first result whitespace-mode which is exactly what I want (it also showed whitespace-cleanup that clears all the trailing whitespace and that is how I discovered it). Want to check the commands related to spelling? M-x spell. How to list errors in the code with flycheck? M-x fly errors. How to sort the lines of a selection? M-x sort. This is really convenient and as an Emacs newbie I get a lot of things done just searching in Helm-M-x without having to search on Google. You can map Helm-M-x to M-x with:

(global-set-key (kbd "M-x") 'helm-M-x)

There is another package that also helps when learning to use a specific mode, it's called "Discover My Major" (discover-my-major in Melpa). Invoking the command with the same name will show all the functions enabled by the current major mode. It's great to discover what every mode can do.

There is another package that also helps when learning to use a specific mode, it's called "Discover My Major" (discover-my-major in Melpa). Invoking the command with the same name will show all the functions enabled by the current major mode. It's great to discover what every mode can do.

Edit: thanks to tuhdo in the comments who told me how to show the full path of the files in the helm-recentf sources).

Vim's Marks => Evil's Marks + Emacs' Bookmarks

Evil has marks just like Vim: m to jump to a mark, m-letter to set a mark, m-uppercase_letter to set a mark that works between buffers. But while marks are pretty useful for example to quickly jump between two or three positions inside some files when you're coding, Emacs also has the concept of "bookmarks" that are like inter-file marks that you can set with a name (instead of a letter) and that with the elisp bit below in your config file can be saved between sessions. I'm using helm-bookmarks to see and set them, which I've mapped to SPC-b. To delete bookmarks, press TAB inside the helm sub-window to see the list of actions and choose "Delete Bookmark(s)".

;; save bookmarks
(setq bookmark-default-file "~/.emacs.d/bookmarks"
      bookmark-save-flag 1) ;; save after every change

Folding... and narrowing!

Folding with Evil works as expected, using the same operators that in Vim (with the added benefit that if you're using Helm-M-x you can do M-x RET fold to search the folding commands in case you forgot the Vim-style operator). Emacs also support an interesting feature called "narrowing". Narrowing will hide everything else in the file except the narrowed function or region. This is pretty useful when you want to make global replaces or run some macro but don't want to affect the other parts of the buffer. I don't use it much so I haven't assigned any shortcut, I just use the commands narrow-to-region and narrow-to-defun. Once you have finished working on the narrowed region, you can display the rest of the buffer again with the widen command.

Project Management

I've already mentioned Projectile that combined with Helm makes searching for project files very convenient, but there are other options. One of them is project-explorer, which is pretty much like Vim "project" script: when you enable it it will show a side split (sorry, window) with your project files. With Helm + Helm-Projectile + the file explorer it's rarely needed but from time to time it's nice to have a tree view of a source code project (more if the code isn't yours). The Windows can be opened with the command "project-explorer-open" (I didn't assign any shortcut to it). One thing to note if you're using Evil is that the shortcuts like TAB to toggle a folder subtree only work if you're in insert mode.

(package 'project-explorer)
(after 'project-explorer
  (setq pe/cache-directory "~/.emacs.d/cache/project_explorer")
  (setq pe/omit-regex (concat pe/omit-regex "\\|single_emails")))

Ctags => Etags

Emacs use a tags file format with a syntax that is different from the "default" ctags called "etags". Generating etags is easy since Exuberant-Ctags already know how to generate them (just add a -e switch). Emacs distributions usually came with an etags binary (I'm using ctags because there is a patched version with support for the D language but Emacs's etag binary doesn't support it). Once generated Emacs will ask you where the tags file is the first time you use any tag command (like find-tag or evil-jump-to-tag to jump to the specified tag) and once loaded it will remember it (at least for the current session, I still need to find how to make it remember the path between sessions).

I've defined this create-tags function on my .emacs to regenerate the tags files (it will ask for a directory and then use that directory as root from where to scan and place to store the tags file):

;; etags
(cond ((eq system-type 'windows-nt)
        (setq path-to-ctags "C:/installs/gnuglobal/bin/ctags.exe")))
            (cond ((eq system-type 'gnu/linux)
                    (setq path-to-ctags "/usr/local/bin/ctags")))

(defun create-tags (dir-name)
        "Create tags file."
                (interactive "DDirectory: ")
                        ;; (message
                                ;;  (format "%s -f %s/tags -eR %s"
        path-to-ctags (directory-file-name dir-name) (directory-file-name
        dir-name)))
                (shell-command
                         (format "%s -f %s/tags -eR %s" path-to-ctags
        (directory-file-name dir-name) (directory-file-name dir-name)))
            )

With third party packages there is also support for normal ctags files and GNU Global, but I find the etags support more than convenient for my needs

Spell checking

No need to install anything if you have ispell on your system, just do: :ispell-buffer to start a spell check of the current buffer (alternatives are show above and shortcuts below) and :ispell-change-dictionary to use another dictionary (to check another language). If you prefer spell checking on the fly with underlines under misspelled words use :flyspell-mode and to see alternatives to a misspelled word press M-$ (Alt-$ on most PCs) with the cursor over the word.

Relative line numbers

Install the package "relative-line-numbers" and enable it globally on your config file with:

(add-hook 'prog-mode-hook 'relative-line-numbers-mode t)
(add-hook 'prog-mode-hook 'line-number-mode t)
(add-hook 'prog-mode-hook 'column-number-mode t)

Easymotion => Evil Ace Jump

The functionality provided by the awesome Easymotion plugin on Vim is actually integrated by default on Evil since it incorporates a package called Ace Jump that does mostly the same. It's less powerful than Easymotion (some jumps like backwards-only / forward-only / end-of-word and others are missing) and I prefer how Easymotion shows directly two chars when a jump is going to require them (instead of showing one and after pressing it, the other which is what Ace-Jump does) but the important modes (bidirectional jump to word and to char) that were the ones I was mostly using are provided.

Unlike Easymotion, jump to word asks for a letter, but that can be easily disabled with: (setq ace-jump-word-mode-use-query-char nil). The author makes the case that without asking for a char you're probably entering more key presses most of the time. This is probably true, but when I want to jump to a random word inside the buffer my brain-eye connection has already identified the word but I've to stop and look/think for the first char, so in the end for me is actually faster to get jump shortcuts to all the words without having to provide the leading character.

I mapped the word/line/char to e/l/x with:

(evil-leader/set-key "e" 'evil-ace-jump-word-mode) ; ,e for Ace Jump (word)
(evil-leader/set-key "l" 'evil-ace-jump-line-mode) ; ,l for Ace Jump (line)
(evil-leader/set-key "x" 'evil-ace-jump-char-mode) ; ,x for Ace Jump (char)

Smooth scrolling

One annoying thing that most Vim users will find in Emacs is the jumpy scrolling. To have Emacs scroll like Vim (that is, line by line and leaving some lines before starting to scroll) the solution is to install the package smooth-scrolling and add this to your config:

(setq scroll-margin 5
scroll-conservatively 9999
scroll-step 1)

It's not perfect because sometimes when you're close to the start of end of the file it still jumps.

Powerline

Super-easy, just install the powerline-evil package and put this in your config:

(require 'powerline)
(powerline-evil-vim-color-theme)
(display-time-mode t)

Syntactic checking on the fly with Flycheck

One of the best Vim plugins if you're a programmer is Syntastic that runs a syntactic check auto detecting a huge variety of linters every time you save. Emacs also have a similar package called "Flycheck". It is even better because it runs in parallel while you work so you don't have to wait for it to finish its checks like happens with Vim. Another related package is flycheck-pos-tip that shows errors on a tooltip (if you're on GUI Emacs, obviously) instead of the minibuffer. My full flycheck config is:

;; flycheck
(package 'flycheck)
(add-hook 'after-init-hook #'global-flycheck-mode)

(after 'flycheck
  (setq flycheck-check-syntax-automatically '(save mode-enabled))
  (setq flycheck-checkers (delq 'emacs-lisp-checkdoc flycheck-checkers))
  (setq flycheck-checkers (delq 'html-tidy flycheck-checkers))
  (setq flycheck-standard-error-navigation nil))

(global-flycheck-mode t)

;; flycheck errors on a tooltip (doesnt work on console)
(when (display-graphic-p (selected-frame))
  (eval-after-load 'flycheck
    '(custom-set-variables
      '(flycheck-display-errors-function #'flycheck-pos-tip-error-messages))))

j/k for browsing wrapped lines

Evil has the same problem as Vim when browsing with j/k long wrapped lines; it jumps the entire "real" line instead of the visual line. The solution is also easy:

(define-key evil-normal-state-map (kbd "j") 'evil-next-visual-line)
(define-key evil-normal-state-map (kbd "k") 'evil-previous-visual-line)

escape... escapes things

One very annoying thing with Emacs is that when you are in the M-x buffer (the one were you call Emacs functions) you've to use C-g to exit it. If you use escape as most Vim users would tend to do by default you need to hit the key like a million times (it's more like 3, but it's extremely frustrating anyway). This code on my .emacs that I copied from davvil init.el on Github fixed it:

;; esc quits
(defun minibuffer-keyboard-quit ()
  "Abort recursive edit.
In Delete Selection mode, if the mark is active, just deactivate it;
then it takes a second \\[keyboard-quit] to abort the minibuffer."
  (interactive)
  (if (and delete-selection-mode transient-mark-mode mark-active)
      (setq deactivate-mark  t)
    (when (get-buffer "*Completions*") (delete-windows-on "*Completions*"))
    (abort-recursive-edit)))
(define-key evil-normal-state-map [escape] 'keyboard-quit)
(define-key evil-visual-state-map [escape] 'keyboard-quit)
(define-key minibuffer-local-map [escape] 'minibuffer-keyboard-quit)
(define-key minibuffer-local-ns-map [escape] 'minibuffer-keyboard-quit)
(define-key minibuffer-local-completion-map [escape] 'minibuffer-keyboard-quit)
(define-key minibuffer-local-must-match-map [escape] 'minibuffer-keyboard-quit)
(define-key minibuffer-local-isearch-map [escape] 'minibuffer-keyboard-quit)
(global-set-key [escape] 'evil-exit-emacs-state)

Start maximized, please

Another minor annoyance was that Emacs (GUI) didn't start maximized by default, but this is easy to fix:

(custom-set-variables
 '(initial-frame-alist (quote ((fullscreen . maximized))))) ;; start maximized

c-k/c-j for page down/up

One thing that surprised me considering how complete Evil is, is the lack of Vim's Control-d/Control-u for page down/up. Probably because C-u is pretty important in Emacs (it's the shortcut to give a numeric parameter to other commands, I think). I've in fact these mapped on my .vimrc to c-k/c-j (because I think they're more consistent with Vim's j/k movement keys) so that's how I mapped them in Emacs:

(define-key evil-normal-state-map (kbd "C-k") (lambda ()
                    (interactive)
                    (evil-scroll-up nil)))
(define-key evil-normal-state-map (kbd "C-j") (lambda ()
                        (interactive)
                        (evil-scroll-down nil)))

Coding Style and spaces instead of tabs

Emacs by default do the really evil thing of using tab characters for indentation. To do the right thing and use spaces with 4 spaces per tab: (setq-default tab-width 4 indent-tabs-mode nil). Also, I prefer the "bsd" style on my code on C-like languages (C, C++, Java, D...) but with 4 spaces tabs instead of 8 so I also added: (setq-default c-basic-offset 4 c-default-style "bsd").

There is also a nice package called "dtrt-indent" that can automatically determine the indentation settings used on the file that you're currently editting and adapt Emacs's settings to them. It's great when you're editing external files not created by you or that for some reason follow different indentation rules that the ones you've in your config file.

(package 'dtrt-indent)
(dtrt-indent-mode 1)

Auto-indent with the Return key

By default Emacs doesn't indent new lines until you press the TAB key. That is not good. But it can be changed easily enough to do the Vim thing, adjusting indentation on every new line automatically with:

(define-key global-map (kbd "RET") 'newline-and-indent)

Show matching paren

If you want to show the matching parenthesis, brace or bracket automatically, add this option: (show-paren-mode t). You can also install the Autopairs package to automatically add the matching parens/braces/etc after adding the opening one. I've mixed feelings about it because while very convenient (specially with Lisp!) it can be also very annoying when you want to surround something with parents and it adds a useless ")" after the opening one, I should use "Surround" on these cases, but half of the time I forget it. To enable autopairs put this on your config file after installing the package:

(require 'autopair)
(autopair-global-mode)

Fill column, auto line breaking and column limit mark

To visually mark the configured fill-column for the mode (like the colorcolumn option in Vim) install the package fill-column-indicator, then you'll enable it on every mode where you want to display it with fci-mode (see below).

To configure auto line breaking when the line exceed 82 chars for text and markdown files, with fill indicator line:

(add-hook 'text-mode-hook (lambda ()
                            (turn-on-auto-fill)
                            (fci-mode)
                            (set-fill-column 82)))
(add-hook 'markdown-mode-hook (lambda ()
                            (turn-on-auto-fill)
                            (fci-mode)
                            (set-fill-column 82)))

To set the non-auto-line limit for Python a C-mode (and D) to 94:

(add-hook 'python-mode-hook (lambda ()
                              (fci-mode)
                              (set-fill-column 94)))
(add-hook 'c-mode-hook (lambda ()
                         (fci-mode)
                         (set-fill-column 94)))

(add-hook 'd-mode-hook (lambda ()
                         (fci-mode)
                         (set-fill-column 94)))

Silver Searcher (ag)

If you don't know it, the Silver Searcher is like Ack but a lot faster. The "ag" package will allow you to make searches with it without leaving Emacs and show the results in a quickfix-style windows where you can select results and jump to them: M-x ag RET [search] RET [directory] RET.

Spanish keyboard remaps

I use Spanish keyboards. Yes, I know, Vim is much better with an English keyboard, but I'm 36 and have been using the Spanish layouts since I was 8, which means that my brain is too hardwired to it. But with a few remaps I made my Vim experience much better. These were - (minus sign) in normal mode as / (to search), as escape in insert mode (I want to try the kj thing) and as :. When you remap keys in Emacs you have to know the name of the function that the shortcut key will point to. Fortunately using C-h k (Control-h, release, k) will tell you the name of the function associated with the next key you press, so getting the name of the functions for these remaps is easy. The / and : remaps were easy:

(define-key evil-normal-state-map "-" 'evil-search-forward)
(define-key evil-normal-state-map " " 'evil-ex)
(define-key evil-insert-state-map " " 'evil-normal-state)

Don't create backup files

I use version control and I'm a compulsive saver, so I don't need backup files. I've these disabled on Vim and I've also disabled them on Emacs:

(setq make-backup-files nil)

Don't move back the cursor one position when exiting insert mode

This is something that I hated in Vim so I had it disabled with the following lines on my .vimrc:

autocmd InsertEnter * let CursorColumnI = col('.')
autocmd CursorMovedI * let CursorColumnI = col('.')
autocmd InsertLeave * if col('.') != CursorColumnI | call cursor(0, col('.')+1) | endif

To get the same behaviour in Evil you just have to set one option:

(setq evil-move-cursor-back nil)

Remember the cursor position of files when reopening them

Pretty easy:

(setq save-place-file "~/.emacs.d/saveplace")
(setq-default save-place t)
(require 'saveplace)

Disable scroll bars

By default Emacs put a scroll bar on every window (split) which IMO is incredibly ugly. I already have the % of my position on the file in Powerline so I don't need any scroll bars: (scroll-bar-mode -1).

"Graphical" GDB

Emacs GDB mode (enabled with M-x gdb RET binary_path) is pretty cool because it create several windows in the style of typical IDE debuggers, but that's not enabled by default, to enable it: (setq gdb-many-windows t).

Once you're in GDB mode with the binary loaded you can change to the source code windows (use C-x o to switch between splits or just mouse clicks, Vim-style C-w key bindings doesn't work in gdb mode), load the source code file you want to set breakpoints on and set a break point with M-x gud-break. Then you can run the program with "run" (r) on the gdb window and once in the break point advance with next (n) or step (s). Local vars and registers are show in one window, breakpoints and the stack frame in another one.

Color Identifiers Mode and Color Delimiters

The plugin colors-identifiers-mode colorize every variable in a different color. I've mixed feelings about it because the code looks like a fruit salad, but it makes really easy to visually identify where variables are used. I'm using it for now. Setup is:

(package 'color-identifiers-mode)
(global-color-identifiers-mode)

Another firm step into the total fruitsalarization of your Emacs is the Rainbow Delimiters package that will color nested delimiters on a different color so you can check easily which of them are pairs without having to move the cursor over them. When you have lots of nested parenthesis this helps a lot to see the pairs without having to move the cursor over them.

(package 'rainbow-delimiters)
(add-hook 'prog-mode-hook 'rainbow-delimiters-mode)

Diminish to clean clutter from the modeline

Diminish will remove the minor mode indicators from the mode line (or powerline). Example config:

(require 'diminish)
(diminish 'visual-line-mode)
(after 'autopair (diminish 'autopair-mode))
(after 'undo-tree (diminish 'undo-tree-mode))
(after 'auto-complete (diminish 'auto-complete-mode))
(after 'projectile (diminish 'projectile-mode))
(after 'yasnippet (diminish 'yas-minor-mode))
(after 'guide-key (diminish 'guide-key-mode))
(after 'eldoc (diminish 'eldoc-mode))
(after 'smartparens (diminish 'smartparens-mode))
(after 'company (diminish 'company-mode))
(after 'elisp-slime-nav (diminish 'elisp-slime-nav-mode))
(after 'git-gutter+ (diminish 'git-gutter+-mode))
(after 'magit (diminish 'magit-auto-revert-mode))
(after 'hs-minor-mode (diminish 'hs-minor-mode))
(after 'color-identifiers-mode (diminish 'color-identifiers-mode))

Select last yanked text

This is a pretty useful shotcut I've on my .vimrc that selects the last pasted (yanked) text:

nnoremap </leader><leader>V `[v`]

Thanks to the comment by delexi I know that the function in Emacs is called exchange-point-and-markwhich defaults to C-x C-x but I've remapped to leader-V with:

(evil-leader/set-key "V" 'exchange-point-and-mark)

Other Emacs alternatives for popular Vim plugins

  • Powerline => Powerline-Evil
  • Emmet => emmet-mode. I mapped "m" to "emmet-expand-line" because the default C-j shortcut is already defined in Evil.
  • Surround => evil-surround (same operators)
  • Tabular.vim => M-x align-regexp RET regexp RET (with a visual selection)
  • Rename => M-x dired-jump, R to rename the file, RET to reopen.
  • jDaddy => I only really used it to prettify json objects, this can be done with the functions defined by James P..
  • Autocomplete and company mode works much like YouCompleteMe on Vim: they give an improved completion when you're programming. I don't know the difference between both, Company is newer, I think, but the ac-dcd package for completing the D language is for Autocomplete so that's what I'm using.
  • Vimdiff => M-x ediff-files or ediff-buffers. Pretty similar. Press ? for help. If you use Helm (just use it) when you're in a helm file list you can press TAB and in the actions list you can select one to marking the file for ediff; much quicker than browsing by hand to the files to compare.
  • netrw/nerdtree => M-x dired (included) or M-x dired+ (installable).

Other random thoughts about Emacs, Evil and Vim

  • Copy and paste with the system clipboard works without having to paste from the "+ or "* register. It's still saved on those registers, but also in the default register so if you paste after copying from any other desktop program and then paste without specifying any register it will pull that register. Nice.
  • Evil doesn't have :pu/:put (paste below current line).
  • Some windows with Evil (like :registers) use Emacs key binding of q to exit instead of Vim esc.
  • The toolbar is actually useful for a newbie like me. Check it. To use the toolbar without the mouse you've the F10 key binding.
  • Paralellization is very nice to have. I love to have my syntax checked without pauses, but...
  • Not everything is perfectly paralellized. For example, when the package manager is loading the information from a package on a split (and sometimes it takes its time), all the interface hangs. One nice feature of Emacs is that you can almost always cancel any long running process with Control-G.

Tutorial de Overclocking en CPUs Ivy Bridge / Sandy Bridge

Vaya por delante que no soy un experto en overclocking. Aunque yo había hecho algunas cosas con este tema hacía muchos años (pero MUCHOS) cuando no era tan fácil y había que coger el soldador para soldar patillas y jumpers, hacía mucho tiempo que no le daba caña a una CPU porque en los últimos años he estado usando ordenadores portátiles que generalmente no conviene overclockear por temperaturas y batería.

Pero hace poco me agencié un ordenador de sobremesa bastante decente (i5 3570K, 16GB de RAM, MSI Lighting GTX 680) y me puse de nuevo al día con el tema de overclocking. La verdad es que me ha sorprendido lo fácil que es hoy en día.

Este artículo lo escribo principalmente como chuleta para mi mismo por si tengo que recordar cosas en el futuro. Como he dicho, no soy un experto y lo que se ahora mismo es resultado de muchas horas de leer tutoriales y foros, pero si un lector encuentra un error que me escriba y lo corrijo (juanjux arroba gmail punto com).

Nota: todo lo escrito aquí es aplicable a procesadores Ivy Bridge o Sandy Bridge, pero yo tengo un Ivy Bridge por lo que los voltajes y temperaturas son algo distintos. En general en Sandy Bridge los voltajes suelen ser más altos y las temperaturas más bajas.

Otra nota, dos en realidad: esto es aplicable a los procesadores de Intel cuyo modelo termina en "k" o "x" como el 3570k, 2500k, o el 3770k. Estos procesadores son los que Intel vende como "Unlocked & Unleashed" y permiten un overclock total. Otros procesadores generalmente no dejan tocar voltajes y sólo dejan subir, y no mucho, el multiplicador. También es necesario tener una placa con un chipset que permita overclockear como la Z67 o Z77 (casi todas las marcas tienen uno o más modelos de placas con este chipset). Si tienes un procesador "x" no te preocupes por nada de ésto, como eres rico yo te overclockeo la CPU a 50€ la hora. También sería importante que la placa base tenga como mínimo cuatro fases de voltaje (como la mía). Si tiene 8 o más, mejor que mejor. Si tiene tres, yo no lo haría.

Hardware usado

Este artículo va a describir un overclocking de un procesador Ivy Bridge, en concreto un Intel I5 3570K "Made in Costa Rica" sobre una placa base Asus P8Z77-V LX2 y un disipador de CPU Cooler Master 212 Evo.

Definiciones

Si leemos y entendemos estas definiciones tenemos el 80% de los conocimientos necesarios para hacer overclocking. El resto como veremos será aplicar algunos valores a la BIOS y buscar con que frecuencias y voltajes tenemos un procesador con temperaturas controladas y estable.

BIOS

Si no sabes lo que es, sal de aquí, corre. En general es recomendable usar la BIOS para overclockear. Mi placa incluye un programa de ASUS para overclockear desde Windows, pero en mi experiencia no funciona muy bien, mucho mejor con la BIOS.

Idle Cuando el procesador no está haciendo nada o casi nada

Carga

Cuando el procesador está trabajando. Puede ser media o alta.

vCore Es el voltaje real que la placa base aplica a la CPU. Puede ser fijo o variable según la frecuencia, y en ese caso hablaremos de vCore bajo carga o vCore sin carga.

VID

El voltaje teórico que la CPU tiene guardada en sus tablas. No es el real que se aplica, que sería el vCore.

La lotería del silicio

Con este término se suele hacer referencia al hecho de que no todos los procesadores salen igual de fábrica, aunque sea la misma marca y modelo e incluso la misma fábrica por impurezas o imprecisiones a nivel atómico. Todos los procesadores (salvo fallo de fabricación), salen funcionando perfectamente para las especificaciones con las que se venden, por ejemplo en el caso de un Intel i5 3570K todos funcionarán perfectamente a sus 3.4Ghz haciendo turbo con un core a 3.8ghz (y un turbo algo menor a los otros tres), pero cuando overclockeemos distintos procesadores responderán de forma distinta. Estas diferencias se traducen en que unos procesadores necesitarán vCore que otros para trabajar a las mismas frecuencias (por ejemplo, uno podría dar 4.3ghz a un vCore bajo carga de 1.20v y otro puede necesitar 1.22), y también en diferencias de temperaturas a igualdad de velocidad y voltaje (otro ejemplo, en dos procesadores que trabajen bien a 4.3ghz con un vCore bajo carga de 1.20v uno podría calentarse unos grados más que el otro). En general, cuanto menos voltaje necesite el procesador y menos se caliente, más podremos overclockearlo.

vDrop (con una "o")

Es la caída, por temas de electrones anarcopunkos, entre el voltaje que la placa aplica y el voltaje real. Por ejemplo si ponemos un voltaje fijo de 1.23v en la BIOS, con el procesador en idle y dependiendo de la placa que tengamos veremos que el vCore real será un pelo menor, por ejemplo 1.225, con lo cual tendríamos 0.005 de vdrop.

vDroop (con dos "o")

Es una caída de voltaje que se produce bajo carga con respecto al voltaje en idle. Esta caída de voltaje no es un fallo, está programada así en el procesador, por diseño. El objetivo del vdroop es minimizar los picos de voltaje que se producen cuando el procesador pasa de tener carga a no tenerla. Por ejemplo, si le ponemos un voltaje fijo de 1.23v y no existiera el vdroop (o tenemos puesto un LLC extremo, ver después) bajo carga el procesador seguiría teniendo 1.23v. Pero como al pasar de "carga" a "idle" se produce un pico (ver la imagen 2), durante un pequeño instante el procesador tendría (datos inventados), 1.30v para después volver a estabilizarse en 1.23v. Con el vdroop, si pusiéramos voltaje en modo fijo (hay otro modo, ver "offset" más adelante), observaremos los 1.25v configurados en idle, pero bajo carga (ver imagen 1) veremos que baja a 1.21v (por ejemplo, de nuevo, dependería del LLC configurado), de modo que el pico producido al terminar la carga podría ser de 1.25-1.27v, quedando cerca del vCore máximo configurado.

Voltajes sin Load Line Calibration, comportamiento por defecto:

Voltajes con Load Line Calibration (extremo o 100%) activo:

Voltaje fijo

Modo con el cual configuramos un voltaje fijo para la CPU en la BIOS. Este voltaje se aplicará independientemente de que la CPU tenga carga o no (con carga será el configurado menos el vdroop), por lo cual no es recomendable ya que sin carga o en cargas medias la CPU estará recibiendo más voltaje del realmente necesario, con lo cual se calentará más, gastará más energía y se acortará su vida. Sin embargo mucha gente overclockea con voltaje fijo y no tiene problemas durante muchos años, hay que tener en cuenta que la temperatura de la CPU sin carga siempre será menor que con carga a igualdad de voltaje (aunque sea mayor que la que debería ser con un voltaje variable) y el tiempo de vida que se acorte la CPU para overclocks no extremos puede resultar en CPUs que aún duran muchos años. Pese a los inconvenientes, overclockear con voltaje fijo es más fácil y aunque pensemos en usar voltaje variable ayuda empezar con un voltaje fijo como veremos después.

Voltaje variable y offset

Este es el otro modo de aplicar voltaje a la CPU en la BIOS y es el aconsejable en procesadores Ivy Bridge. Con este modo la BIOS aplica al procesador un voltaje dependiente de la frecuencia del reloj. Estos voltajes están guardados en unas tablas en el propio procesador. De modo que bajo carga el voltaje siempre será mucho menor que con carga, con lo que el procesador gastará menos energía, se calentará menos y durará más. Sin embargo en ocasiones es común, sobre todo a velocidades de overclock, que esos valores de voltaje no sean adecuados, por lo que en cualquier BIOS decente podremos poner un "offset" o "desplazamiento" en el cual indicamos un voltaje adicional (positivo o negativo) al que esté usando la CPU a ese voltaje. Por ejemplo si con un offset 0 observamos que la CPU a 4.3ghz tiene un vCore bajo carga de 1.16v, con un offset de +0.05 tendría 1.21v y con uno de -0.01 1.15v. Dependiendo de la lotería del silicio, algunos procesadores pueden necesitar más offset que otros para funcionar de forma estable a las mismas frecuencias. Incluso algunos funcionarán de forma estable con offset negativos, aunque a frecuencias altas no es lo normal. Algunas placas base permiten establecer el offset normal y el offset turbo. El normal se aplicará cuando el procesador no tenga carga o tenga cargas muy bajas (cuando normalmente los cores trabajan a 1600mhz en el caso de un i5 3570k), otras (como la mía) sólo permiten meter un offset que se aplicará en todos los casos.

Load Line Calibration (LLC)

El Load Line Calibration es un mecanismo que incluyen los fabricantes de placas base para disminuir el efecto del vdroop. Para ello hacen trabajar a los reguladores de voltaje de forma que compensen la caída de voltaje bajo carga de modo que en esa situación el voltaje caiga menos y se aproxime más al configurado. Esto permite que podamos configurar en la BIOS un voltaje (fijo o variable) más bajo para conseguir un procesador estable. El procesador se beneficiará de este menor voltaje sobre todo en cargas bajas, ya que en cargas altas con o sin LLC el vCore será el mismo si queremos que sea estable (solo que sin LLC tendremos que poner un vCore mayor). Por ejemplo, pongamos que tenemos un procesador que sabemos que funciona bien a 4.3ghz con 1.20v de vCore bajo carga. Sin configurar LLC (LLC 0%) sabemos que para conseguir esos 1.20v, tenemos que configurar en el procesador 1.24v. Eso hará que en idle el voltaje sea 1.24v (ya que casi no hay vdroop en idle) y bajo carga sea de 1.20v. Sin embargo si ponemos un LLC del 100% ("Extremo" en la mayoría de placas), podremos configurar en la BIOS un voltaje fijo de 1.20v, con lo cual en idle el procesador recibirá 1.20v, y el mismo bajo carga, con lo que habremos bajado en 0.05v el voltaje en idle, alargando la vida del procesador y bajando la temperatura (bajo carga será igual). Con un voltaje variable pasa lo mismo, si sin LLC necesitamos poner un offset de +0.07v, podríamos observar un vCore de 1.0v en idle y 1.20v bajo carga, pero si ponemos un offset extremo el voltaje en idle cambiará a 0.85v siendo aún 1.20v bajo carga.

¿Cual es el inconveniente de usar LLC por lo tanto y por qué hay varios niveles? Si hemos leído la definición del vdroop veremos que el fabricante del procesador lo incluye por un motivo, y es minimizar el efecto de picos de voltaje en cargas altas o bajas. Cuanto pueden acortar la vida del procesador esos picos, sobre todo cuando estamos trabajando en voltajes moderados (por debajo e 1.4v-1.5v) es algo indeterminado. Hay que tener en cuenta que según la especificación del 3570k, el procesador no se dañaría hasta 1.55v (si no recuerdo mal, por ahí andaba) por lo que un pico de microsegundos que produzca menos de 1.3-1.4v no acortaría mucho la vida del procesador. Otro inconveniente del LLC, este quizás más importante, es que hace trabajar más a los reguladores de voltaje o VRMs, por lo que se calentarán más. Como alguien que ha quemado más de un VRM yo no subestimo la importancia de ésto. En general, si nuestra placa base no tiene disipadores en los VRMs, no es aconsejable usar un LLC superior al 25% ("medium"). Si tiene unos disipadores normalitos podemos usar "high" (50%) o "very high" (75%). Si tenemos una placa base de las caras con unos disipadores tremendo o incluso refrigeración líquida en los mismos, podremos subir a "extreme" (100%) con bastante tranquilidad.

Importante antes de empezar: sobre disipadadores de CPU y temperaturas

Cuando hacemos overclock va a haber dos cosas que limiten las velocidades que podamos alcanzar: la estabilidad y la temperatura. El voltaje también podría considerarse un limitador ya que nunca deberíamos subir de 1.55v, pero en el caso del 3570k vamos a encontrar el tope de temperatura mucho antes de llegar a ese voltaje (salvo que usemos una refrigeración increíble con agua refrigerada, hielo o nitrógeno líquido... aquí somos gente normal ¿no?).

En general para overclocks no muy extremos la estabilidad es fácil de conseguir, tan sólo tendremos que ir subiendo el voltaje hasta que el procesador sea estable. Es muy raro que un 3570k no se overclockee como mínimo de forma estable a 4.3-4.4ghz. Algunos consiguen incluso 5Ghz. Pero subir la velocidad y el voltaje sube la temperatura, y si no la controlamos con mejor refrigeración tendremos en el mejor caso un procesador que hace "throttling", es decir, baja el rendimiento al mínimo en intervalos para bajar su propia temperatura, y en el peor caso un procesador quemado (y en ocasiones también una placa).

Hay dos especificaciones de temperaturas que tenemos que tener en cuenta para nuestro procesador: TCase y TjMax.

TCase es el máximo recomendado para la temperatura medida en un sensor que hay cerca de la CPU en la placa base. Los programas de lectura de sensores suelen dar el TCase como "CPU Temp" o "CPU" dentro de los sensores del chipset de la placa base (en el caso de mi placa y el HwInfo64 viene como "CPU" dentro de "Nuvoton NCT6779D". En general TCase suele ser 10-15 grados menor que la temperatura de los cores. Para un i5 3570k TCase es de 67.5C. Normalmente cuando overclockeamos no suele haber problema en acercarse o incluso sobrepasar un poco el TCase, ya que es mucho más importante la temperatura real de los cores y el sensor de la placa no siempre es muy fiable.

TjMax es la temperatura, medida en los propios cores del procesador, a partir de la cual el procesador pasará a un modo de "protección térmica" con rendimiento mínimo (para intentar bajar la temperatura) o incluso se apaga. Debemos evitar llegar al TjMax a toda costa, ya que es la temperatura a partir de la cual se podrían causar daños en el procesador (incluso a pesar de sus intentos de protegerse). Es más, cuanto más alejados estemos del TjMax, mejor. Para un i5 3570K el TjMax es de 105C, y la gente que entiende mucho de overclocking suele decir que hay que evitar que el procesador sobrepase los 90C incluso en pruebas de carga. Luego cada uno dependiendo de su valor y/o inconsciencia y/o riqueza puede variar sus temperaturas máximas "objetivo". Personalmente intento que incluso en las pruebas de carga más brutas (Intel Burn Test) el procesador no pase de 80-85 grados en ningún momento. Si pasa de esa temperatura, bajo la velocidad (o el voltaje, si consigo que sea estable con menos).

La temperatura sube cuando:

  1. Subimos el voltaje
  2. Subimos la velocidad

Los incrementos de voltaje suben más la temperatura que los incrementos de velocidad.

Sabiendo que la temperatura es el principal factor limitando de un buen overclock la pregunta obvia es ¿cómo conseguimos temperaturas más bajas para poder overclockear más? Y la respuesta es múltiple; en orden de importancia:

  1. Con un buen disipador de la CPU
  2. Con una mejor ventilación en nuestra caja
  3. Con una temperatura ambiente más baja.

Lo de la temperatura ambiente suele escapar a nuestro control (salvo aire acondicionado, pero supongo que no queremos tener puesto el aire siempre que el ordenador esté funcionando, estemos delante o no), pero los otros dos factores sí podemos controlarlos fácilmente. Lo de la caja es fácil; o bien ponemos más y mejores ventiladores (importante: cuanto más grandes mejor refrigeran y menos ruido hacen) o compramos una caja que venga con mejor ventilación de serie (como las Cooler Master HAF, por ejemplo).

El disipador de la CPU es muy importante porque es el primer responsable de enfriarla. Los procesadores suelen venir con un pequeño disipador que es perfectamente adecuado para la CPU funcionando a las velocidades y voltajes de serie y perfectamente inadecuado para cualquier overclock que no sea mínimo. Gastar un poco de dinero en un disipador mejor bajará enormemente las temperaturas de la CPU. Voy a poner mi caso como ejemplo.

Con el disipador de serie, sin overclocking y haciendo pruebas de stress, la temperatura máxima en los cores rondaba los 72-74 grados. De serie el 3570k sólo sube a la velocidad turbo (3.8ghz) a un core, el segundo core subiría a 3.7, el tercero a 3.5 y el cuarto creo que a 3.4.

Configurando en la BIOS que los cuatro cores pudieran subir a la vez a la vez a la velocidad turbo, la temperatura subía a 79C. Con un overclock muy suave a 4.0 ghz la temperatura ya sobrepasaba los 80C.

Con el Cooler Master 212 Evo (que me costó 28€), y el procesador sin overclock, no pasaba de 60C en pruebas de stress. Con mi overclock actual a 4.3Ghz y +0.055 offset no pasa de 78C con el test más bruto (Intel Burn Test), o 73C con un test más normal (Prime95) o juegos. Con el disipador de serie ni se me ocurriría probar a esta velocidad/voltaje. Llegaría al TjMax seguro. Hay que decir que la caja que tengo actualmente, bastante vieja, no tiene una ventilación muy buena, un ventilador de 120mm de entrada, y dos de 80mms lateral y de salida (que se le va a hacer, en algo tenía que recortar al actualizar el ordenador, espero cambiarla más adelante).

Hay otros disipadores mejores y más caros como el Noctua NH14 o incluso disipadores líquidos, tanto en circuito cerrado como "custom", pero para el overclock que buscaba de 4.3-4.4ghz me sobra con el Cooler Master (suelen aconsejarlo hasta 4.5ghz).

En resumen: si vamos a overclockear, hay que comprar un buen disipador. Antes de comprarlo hay que estar atento a las dimensiones, ya que hay algunos tan altos que no entran en la caja (tocan con el lateral). En el caso de mi cutrecaja, el 212 queda a 2 mms del lateral y un DH14 no me cabría. También hay que tener en cuenta que si tenemos módulos RAM con disipador, que son más altos, es probable que un disipador nuevo cubra algunos de los sockets de la RAM. En mi caso cubre el primero así que tuve que mover los dos módulos a los sockets 2 y 4.

Software necesario

Cuando overclockeamos medimos la temperatura, el voltaje y la estabilidad. Además nos interesará tener un control más fino de los ventiladores, tanto de la caja como de la CPU. En mi caso estoy usando estos programas, todos de Windows, aunque soy más de Linux, en este tema el software de Windows está mucho mejor:

SpeedFan: sirve para controlar los ventiladores como queramos. La interfaz es un poco peluda, pero a cambio nos da mucha flexibilidad. En este tutorial no voy a explicar como configurar speedfan, hay buenos tutoriales por Internet. Mi placa ASUS también venía con un programa que no está mal y era más sencillo de usar, el Fan Xpert +, pero no leía bien la temperatura de la CPU por lo que no me valía. En resumen, yo he puesto que los ventiladores están al 40% por debajo de 50C, al 80% (el 212 es muy silencioso) entre 50 y 70 grados, y al 100% por encima de 70C. Cada uno deberá equilibrar como desea tener las velocidades y el ruido. Otra opción es comprarse un regulador de ventiladores por hardware, que se suele instalar en una bahía de 5 1/4 y controla los ventiladores con diales. En mi caso tengo el ordenador debajo de la mesa al fondo, por lo que esta solución me resultaría muy incómoda y además speedfan varía automáticamente las velocidades.

CoreTemp: nos permite monitorizar las temperaturas de los cores, el consumo de energía y el VID. Lo más interesante es que nos guarda la temperatura máxima de cada core desde que se abrió el programa.

CPU-Z: usaremos CPU-Z para controlar el vCore real bajo carga y en idle.

Prime95: Prime95 produce una carga elevada en todos los cores del procesador. Tiene varios tests para probar datos pequeños, que caben en las cachés, y datos mayores que no caben. Las temperaturas máximas que se obtienen con Prime95 pueden ser similares a las que den juegos muy exigentes como la CPU o ciertos softwares de computación distribuída de tipo "seti@home", "folding@home" y demás. Prime95 es una prueba sobre todo de estabilidad, y lo normal para probar la estabilidad de un overclock es ejecutar la prueba "blend" durante 24 horas, o la prueba "small FFT" durante un rato para comprobar temperaturas máximas realistas.

Intel Burn Test: Intel Burn Test, IBT para abreviar, mete una tralla tremenda al procesador que nos va a permitir ver las temperaturas más altas que nuestro procesador alcanzaría jamás. No es un test realista pero no está de más comprobar esas temperaturas (quizás en el futuro algún juego o programa le meta al procesador una caña semejante). Además muestra los "gigaflops" por lo que nos sirve también como prueba de rendimiento.

HWInfo64: es un programa de lectura de sensores muy completo. Lee todo lo que nuestra placa base, procesador, discos duros y GPU dejen leer, incluyendo temperaturas, voltajes, revoluciones de ventiladores, etc, etc, etc. También guarda valores máximos durante su ejecución. El problema que yo he encontrado con HWInfo64 es que mete bastante caña al procesador y por lo tanto adultera un poco los otros tests de stress, por lo que suelo preferir usar CoreTemp y CPU-Z cuando estoy probando. Por ejemplo, el 3dMark11 me baja de 9400 a 9200 puntos si estoy ejecutando HWInfo64.

Visor de Eventos de Windows: nos va a permitir buscar los "WHEA Warnings" que casi siempre indican un overclock no estable.

Configuración inicial de la BIOS

Los nombres de campos, secciones y valores que voy a poner aquí son siempre con respecto a mi placa, ASUS P8Z77-V LX2. En otras placas con chipset Z77 los nombres de los campos o las secciones pueden varíar un poco, pero en general son semejantes.

El primer paso tras reiniciar y abrir la BIOS es ir a "modo avanzado" (el que no es tan gráfico y tiene distintas pestañas). Una vez dentro vamos a la pestaña de "Advanced" y ponemos "Intel Adaptative Thermal Monitor" a "Disabled".

Después vamos a la pestaña "AI Tweaker" y:

  • Ai Overclock Tuner: Manual

  • BCLK/PEG Frequency: 100.0

  • Entramos en DIGI+ VRM y ponemos el Load Line Calibration (LLC) al valor deseado. Para empezar, se puede poner en "Medium" o "High". Ponemos el CPU Power Phase Control a "Optimzed" y CPU Current Capability al 120%.

  • Turbo Ratio: Manual

  • Ratio Synchronizing Control: Enabled (esto hace que todos los cores puedan subir al máximo).

  • 1-Core Ratio Limit: Aquí ponemos el multiplicador del overclock que queremos tener. Por ejemplo para un overclock inicial de 4.0Ghz pondremos "40" y pulsamos intro. El número debería copiarse en los otros cores si activamos la opción anterior, si no, lo ponemos a mano para todos los cores.

Proceso de overclocking

Vamos a seguir un proceso de overclocking incremental, empezando con un valor conservador de velocidad y voltaje. Luego bajaremos el voltaje hasta que encontremos el voltaje mínimo con el cual el procesador es estable, y luego iremos subiendo la velocidad y ajustando el voltaje cuando sea necesario. Hay que decir que el proceso es largo aunque no muy laborioso, porque conviene ejecutar el Prime95 durante varias horas (pero no hace falta que estemos delante). Hay que hacerse a la idea de probar 1 o como mucho 2 overclocks cada día, por lo que tardaremos varios días hasta encontrar el overclock estable que buscamos.

Entramos en la BIOS. Ponemos el multiplicador de la CPU (en el caso de mi placa en "Core Ratio Limit") a un valor conservador como 41 (4.1Ghz). Vamos a la parte de "CPU Voltaje" y seleccionamos "Manual Mode". En el campo de texto "CPU Manual Voltaje" ponemos "1.25" (que sería mucho normalmente para esta velocidad, pero ya lo iremos bajando) y en "Digi+ VRM" ponemos el "Load Line Calibration" en "High".

Guardamos y reiniciamos.

Vamos a hacer el test de temperaturas. Lo normal es que con 1.25v sean algo más alta de lo normal, pero como lo más seguro es que luego podamos bajar ese voltaje, no nos preocuparemos siempre que no superen los 90C.

En Windows abrimos el CoreTemp y el CPU-Z. Abrimos el Prime95 y marcamos la casilla "In Place Large FFTs" y le damos a Ok. Dejamos que el Prime se ejecute mientras observamos las temperaturas en el CoreTemp. Si en cualquier momento pasara de 90C, paramos el Prime95 (Menu Test -> Exit). Mientras la CPU trabaja, miramos la ventana del CPU-Z y apuntamos el valor de "Core Voltage". Puede que oscile un poco entre dos o tres valores, en ese caso apuntamos el valor menor.

Tras dos o tres minutos, abrimos el Intel Burn Test y ejecutamos el test "Standar". Lo dejamos hasta que termine, de nuevo, controlando siempre las temperaturas y no dejando que pasen de 90C.

Finalmente, abrimos el visor de eventos de Windows y en la parte central desplegamos "Adventencia" y comprobamos que no hay ningún "WHEA Warning" o "WHEA Error". Los errores WHEA suelen indican errores de paridad detectados y corregidos por el procesador, pero que en cualquier caso son errores de funcionamiento de la CPU y por lo tanto indican que bajemos la velocidad o subamos el voltaje. Lo normal es que con esta velocidad y voltaje no hubiera errores.

Si estas pruebas se han completado con éxito, no vamos a hacer una prueba de estabilidad larga porque lo normal es que con estos valores tan bajos de velocidad y alto de voltaje el procesador sea estable como una roca (aunque caluroso). Si la temperatura subía mucho en algún test, no es preocupante de momento, porque estamos usando un voltaje relativamente alto. Sí sería preocupante que el procesador no sea estable o encontremos errores WHEA, indicaría que nos ha tocado un procesador al que no le gusta mucho overclockear. En ese caso si las temperaturas no fueron elevadas en las pruebas anteriores, podemos subir el voltaje y probar de nuevo, o si sí lo fueron bajar el overclock a 4.0 ghz y repetir.

En el caso normal de que a 4.1ghz el procesador sea estable con 1.25v en modo manual, reiniciamos y volvemos a la BIOS. Tocamos el voltaje y lo bajamos un poco a 1.23v. Reiniciamos en Windows y ejecutamos las pruebas anteriores para las temperaturas (Prime95 con large FFT e Intel Burn Test), apuntando de nuevo el vCore bajo carga, pero además usamos el ordenador con normalidad y a ser posible jugamos a juegos intensivos para la CPU (por ejemplo Planetside 2, Battlefield 3 en mapas de 64 jugadores, los Total War, etc). Cuando terminemos y dejemos de usar el ordenador (nos vamos a la cama, al trabajo, etc), dejamos el Prime95 funcionando con el test "Blend" (calentará menos la CPU que el Large FFT pero es más real). Lo idea es que se ejecute 24 horas, 8-12 horas puede valer aunque hay errores que salen bastante tarde. Normalmente con un 3570K salvo que juguemos el ordenador es bastante rápido mientras ejecutamos Prime5-Blend por lo que podríamos usarlo con normalidad para navegar, programar, ver vídeos de gatitos, bajar cosas, etc.

Cuando ya han pasado las horas que hayamos estimado oportunas de Prime95, si no se ha colgado o ha tenido pantallazo azul, miramos el visor de eventos y comprobamos que no hay errores WHEA.

Al final de todo este proceso pueden pasar dos cosas:

  1. Que el ordenador se haya colgado, congelado o con pantallazo azul, o tengamos errores WHEA en el visor de eventos. En este caso iremos a la BIOS, subimos el voltaje en 0.005 y repetimos todo el proceso.

  2. Que no tengamos problemas de estabilidad ni errores WHEA. En este caso vamos a la BIOS y bajamos el voltaje en 0.01 y repetimos el proceso.

Al final, encontraremos un voltaje manual para el cual el procesador es inestable mientras que el anterior un poco superior no lo era. Ese será el primero voltaje que consideraremos "estable" para 4.1Ghz y es el primer paso en nuestro overclocking.

Ahora vamos a la BIOS y subimos el multiplicador de turbo a 42, sin tocar el voltaje, y repetimos todo el proceso. Lo normal es que el voltaje mínimo con el que era estable a 41 no sea estable a 42. Cuando encontremos alguna inestabilidad o error WHEA, igual que antes, vamos a la BIOS y subimos el voltaje +0.005 hasta que encontremos un voltaje estable a 4.2Ghz.

Este proceso en general lo repetimos hasta que lleguemos a la velocidad o temperatura objetivo, y una vez llegados a ella de forma estable, apuntamos el vCore bajo carga y volvemos a la BIOS.

Cambiamos CPU Voltaje a "Offset Mode" y ponemos el offset en "0" o "+0.005" según nuestra placa (NO dejarlo en "Auto"). Reiniciamos. No nos asustemos si la cosa peta en el primer momento, o incluso arrancando, ya que a priori no podemos saber el voltaje que le estará metiendo la placa al procesador. En ese caso (caso catacrocker como diría mi amigo Santy) volvemos a la BIOS y subimos el offset en 0.005v (signo positivo) y probamos de nuevo. Una vez hemos arrancando Windows, ejecutamos Prime95 (da igual el test) y miramos el vCore en el CPU-Z. Aquí puede pasar que el vCore bajo carga sea mayor o menor que el que teníamos cuando estábamos con voltaje manual. Nuestro objetivo es que sea el mismo en modo offset. De modo que si por ejemplo con voltaje manual teníamos a 4.3GHZ un voltaje estable de 1.20v y en modo offset nos está mostrando 1.22, pondremos un offset negativo de -0.02 (IMPORTANTE: EL VALOR ES UN EJEMPLO, ¡TENEMOS QUE COMPARAR CON EL VCORE BAJO CARGA QUE APUNTAMOS CON EL VOLTAJE EN MODO MANUAL!). Si por el contrario en modo offset nos mostrase 1.17v ponemos un offset positivo de +0.03.

Una vez hemos conseguido que el vCore bajo carga en modo offset sea el mismo que cuando estábamos en modo manual, volvemos a ejecutar las pruebas de temperatura y estabilidad de nuevo (Prime95, Intel Burn Test, juegos, etc). A veces un vCore bajo carga que es estable en modo manual no lo es en modo offset, a pesar de tener el mismo valor, por temas de la Diosa Elektra. En ese caso podemos probar a subir poco a poco el offset, o incluso bajarlo si fuera estable y queremos probar si funciona bien con menos.

Y una vez tenemos un overclock estable a la velocidad que queremos con el voltaje en offset y temperaturas controladas, podemos decir que hemos terminado, aunque conviene darle un vistazo de vez en cuando al visor de eventos para controlar los errores WHEA porque en mi experiencia a veces tras encontrar un overclock estable a los 3 o 4 días mientras jugamos nos salta un error WHEA aislado, que con una pequeña subida del offset de 0.005 suele desaparecer para siempre. Como referencia yo ahora mismo tengo 4.3GHZ a +0.055 de offset.

Si nuestro factor limitador a la hora de overclockear ha sido la temperatura, la solución es encontrar un disipador mejor/más caro que nos permita subir un poco más.

Lo cierto es que a 2013, hay pocos programas o juegos que aprovechen la potencia de un 3570K, por lo que salvo que queramos participar en concursos de overclock (que los hay, y no vas a ganar) tampoco hace falta subir mucho el procesador.

Inciso importante sobre los errores WHEA

Hay gente en los foros de overclocking que no les da importancia porque dicen que si el Prime95 es estable durante horas, el Intel Burn Test pasa 40 o 50 ciclos y los programas y juegos no petan, el ordenador es estable aunque haya errores WHEA. Yo discrepo enormemente y explico por qué. Si miramos la descripción cuando sale un error WHEA veremos que casi siempre son errores de paridad. Esto quiere decir que el procesador ha detectado que un bit que tenía que ser un 0 es un 1 (o viceversa), y ha ordenado recalcular todo de nuevo (lo cual nos hace perder rendimiento y ya de por si sería un motivo para no querer este tipo de errores). Si de vez en cuando un bit se cambia, la CPU no está funcionando bien. Es como si nos estuviera diciendo que 2+2 son 9, aunque sea de pascuas a ramos. Además, y esto es más terrible, si en lugar de en un bit el error se produce en dos a la vez, el procesador no detecta el error y se lo come, lo cual nos puede dar como resultado un error inofensivo (un pixel se ve mal, un caracter sale raro), una petada del juego o programa que estemos usando, un catacrocker total del sistema, o peor, la corrupción de un fichero, que puede ser del sistema operativo o nuestra tesis.

Yo mientras probaba un overclocking fallido que resultó dar muchos errores WHEA descomprimí un fichero RAR y no se descomprimió bien a la primera (el 7zip dijo que falló la comprobación MD5), pero a la segunda sí. También hay que decir que hay errores WHEA "naturales" que pueden no tener que ver con el overclocking. Por ejemplo, un rayo cósmico que da en un registro o la RAM (no es broma, eso pasa y hasta hay una fórmula sobre la frecuencia), un pequeño fallo en el voltaje que da la placa base o la fuente de alimentación, etc. En general si después de dos meses sin errores nos da uno, sí que podríamos etiquetarlo como error natural e ignorarlo tranquilamente, pero los que dan en overclocking al poco tiempo o días, mejor no ignorarlos. Hay gente que funciona feliz con docenas de errores WHEA por minuto. Hay gente pa tó. En resumen, si tienes errores WHEA, sube el voltaje si tienes margen de temperatura, y sino baja la velocidad.

Por otro lado, si en un foro alguien te dice "¡ese voltaje es muy alto para esa velocidad!", podría ser cierto (lotería del silicio), pero en general no hagas mucho caso porque muchos overclockers no miran los errores WHEA (ni saben que existen). Yo he comprobado que la gente que sí dice mirar los WHEA suele aplicar voltajes más altos.

[Nota: Como tengo los comentarios de la web desactivados por spam, podeis mandarme las preguntas y sugerencias a juanjux arroba gmail punto com pero tener en cuenta que no soy un experto por lo que las preguntas sería mejor publicarlas en foros de overclockers. Las sugerencias y correcciones siempre serán bienvenidas.]

Si tienes problemas de velocidad de red, desactiva el Asus iNetwork Control

En el ordenador que tengo en la planta de arriba nunca tuve mucha velocidad de red porque estaba conectado por WIFI y arriba no llega muy bien. Como mucho 10 megas un día bueno, eso con WIFI N (aunque no a 5Ghz). Hace no mucho actualicé el ordenador completamente (placa, CPU, GPU, memoria, disipador de CPU...) y el problema se agravó, usando el mismo pincho WIFI, así que compré dos cacharros PLC (red por línea eléctrica) de 500 megas para ver si mejoraba la cosa. Y mejoró... a ratos. Mi conexión se volvió bipolar. A veces me daba 80 megas (es decir, prácticamente la conexión a tope) y otras veces me daba 1 mega o medio, sin patrón alguno ni horario ni de ningún otro tipo, hasta probé a encender y apagar todos los cacharros eléctricos de la casa uno por uno para ver si alguno interfería, reinstalar drivers, etc.

El caso es que buscando un tema que no tenía nada que ver en foros de overclocking me encontré con un hilo en el que varias personas decían que al desinstalar o desactivar el programa Asus iNetwork Control, parte del AI Suite que viene con las placas Asus (como la mía), dejaban de tener problemas de red. La verdad es que nunca he usado el iNetwork, pero estaba instalado y funcionando, con el icono donde las notificaciones, uno de esos iconos a los que nunca haces caso. Se supone que el programa sirve para priorizar las conexiones, algo así como uno QoS sencillo de usar, pero como nunca lo he tocado estaba con el perfil "auto". Fue desactivar el programa, hacer un speedtest y... ¡premio! 80 megas reales de conexión a internet, básicamente todo lo que da mi conexión. Y reproducible de forma consistente, a cualquier hora del día.

Entendería el resultado anterior si estando el programa estuviera ejecutando además algún juego u otro programa que necesitase baja latencia, pero no, las velocidades horribles se daban aunque el navegador fuera el único programa. Por lo tanto debo concluir que ese programa es una basura.

Como tener Whatsapp en un tablet Android sin 3G

En principio, Whatsapp es una aplicación que se asocia a un número de teléfono. Eso tiene la ventaja de que no tenemos que andar logueándonos o añadiendo usuarios, ya que a partir de la lista de contactos detectará automáticamente todos los que tengan Whatsapp. El inconveniente es que en dispositivos sin 3G ni número de teléfono como algunos tablets (por ejemplo versiones de Asus Transformer, Galaxy Tab, Nexus 7, etc) en principio no funciona.

Pero si tenemos un tablet y móvil con Android rooteados podemos tener Whatsapp siguiendo los siguientes pasos:

  1. Rootear el tablet Android y el teléfono si no lo tenemos hecho. El proceso será distinto según el tablet que tengamos y lo mejor será buscar en Internet como hacerlo en nuestro modelo exacto.

  2. MÓVIL Y TABLET: Instalamos Titanium Backup.

  3. MÓVIL: Instalamos la aplicación Go Contacts Ex.

  4. MÓVIL: Abrimos Titanium Backup, nos vamos a la pestaña "Copiar / Restaurar", buscamos Whatsapp (la lista va por orden alfabético así que estará por el final, ojo, Whatsapp, NO "Whatsapp Wallpaper"), pulsamos sobre el nombre, y damos al botón de "Copiar".

  5. MÓVIL: Cuando termine, hacemos una pulsación larga sobre "Whatsapp" y elegimos "Enviar la Copia de seguridad más reciente", elegimos "App + Datos (importación sencilla)", y elegimos la forma de exportar que prefiramos (puede ser a un fichero local en el móvil, usando Dropbox o Google Drive, como adjunto de correo, etc).

  6. MÓVIL: Repetimos el paso 5 con la aplicación "Go Contacts Ex".

  7. TABLET: Recuperamos los backups que hemos hecho en el móvil con el método que hayamos usando (adjunto, Dropbox, Google Drive, etc...).

  8. TABLET: Abrimos Titanium Backup

  9. TABLET: Usando el botón de menú (o si el tablet no tiene botón, el icono de menú en la esquina superior derecha), elegimos "Importar Copiar de seguridad".

  10. TABLET: Elegimos el fichero de backup de Go Contacts Ex y dejamos que lo instale.

  11. TABLET: Abrimos el GO Contact Ex y salimos

  12. TABLET: Volvemos a abrir Titanium Backup y repetimos el paso 9 con el backup de Whatsapp.

  13. Vamos a FonYou y nos registramos para obtener un número de móvil virtual, que asociamos a nuestro teléfono (es gratuíto). FonYou tiene otras cosas interesantes como llamadas internacionales a precio local y un buzón de voz muy avanzado, os aconsejo que le deis un vistazo a la web.

  14. MÓVIL: Abrimos Whatsapp y escribimos cualquier cosa a un contacto.

  15. TABLET: Abrimos Whatsapp y escribimos cualquier cosa a un contacto. Nos va a salir un mensaje diciendo que hay que validar el número (Whatsapp detecta que hay dos dispositivos con el mismo número), iniciamos el proceso de validación, ponermos el número que hemos obtenido de FonYou, se quedará en "Esperando SMS". Como el tablet no puede recibir SMS (nos llegará al móvil) al cabo de un rato esperando nos dará un error y nos dará la opción de validar por llamada de teléfono. Aceptamos esa opción.

  16. MÓVIL: Recibimos la llamada y apuntamos el código.

  17. TABLET: Metemos el código en Whatsapp.

  18. ¡Ya está! Tendremos Whatsapp funcionando en el tablet sin problemas.

Es importante saber que cuando escribamos un Whatsapp a un contacto desde el tablet le saldrá con el número de FonYou si no tiene ese número en su lista de contactos, por lo que tendremos que avisar a los contactos para que asocien ese nuevo número como número adicional nuestro en la lista de contactos (o como nuevo contacto como "Pepe Tablet") para que les salga el nombre. Si nos escriben al número del móvil el Whatsapp seguirá recibiéndose sólo en el móvil y viceversa con el número del tablet, pero al menos podremos iniciar conversaciones, o mandar imágenes, vídeos o enlaces desde el tablet (y las respuestas llegarán al tablet, si queremos seguir la conversación en el móvil hay que avisar al contacto o mandarle el siguiente mensaje desde el móvil).

Análisis/review de varios headsets para jugar y solución con kit artesanal (ACTUALIZADO ENERO 2013)

Índice

Introducción

En este artículo voy a contar mi pequeño viaje por el mundo de los headsets para juegos compatibles con PS3 y como al final descarté las opciones existentes para hacerme el mío propio usando unos cascos de audiófilo de muy buena calidad, un mixer dolby 5.1 y un micrófono de PC.

Mi pequeño viaje por el mundo de los headsets

Yo juego bastante con mis amigos a algunos juegos online que mejoran mucho si hay comunicación entre los jugadores, principalmente shooters, por lo que siempre he querido tener el mejor headset posible. Eso me ha llevado a probar varias opciones hasta que he dado con la que me ha producido más satisfacción.

Las cosas que considero importantes para un headset y que por lo tanto evaluaré de cada uno probado son:

  • Comodidad en la cabeza: algún sábado por la noche podemos llegar a jugar 4 o 5 horas del tirón, por lo que el headset debe ser cómodo durante largos periodos. Eso incluye no pesar demasiado, y no dar un calor excesivo. También se considera "comodidad" el que el headset sea inalámbrico en lugar de usar un cable, o el no necesitar centralita.
  • Compatible con PS3: dado que es la plataforma en la que juego, todos los que probé eran compatibles con PS3, por lo que no voy a evaluar esto.
  • Calidad del micro: un headset no me va a servir de mucho si mis amigos no me escuchan bien.
  • Polivalencia: si además de para juegos los cascos pudieran usarse para música y películas, mejor.
  • Calidad del sonido: aunque el juego al que solemos jugar online (Call of Duty) no tiene una gran calidad de sonido, sí que me interesaba que el headset pudiera dar la máxima calidad de sonido en relación al precio, ya que aparte de para el uso musical, sí quería disfrutar de otros juegos con una gran calidad de sonido (como los de la serie Mass Effect, Battlefield o el Skyrim).
  • Calidad del sonido envolvente: en juegos como shooters la calidad del sonido envolvente 5.1 o 7.1 es una cuestión de vida o muerte (virtual) saber por donde va a venir el enemigo cuando escuchas sus pasos, además de proporcionar una sensación de inmersión mucho mayor (un ejemplo claro es Mass Effect 3, cuando estamos en la ciudadela y se escuchan músicas, sonidos y conversaciones desde todas las direcciones).
  • Precio: hasta que a uno le toque el euromillones, el precio debe ser un factor a tener en cuenta.
  • Calidad: no vale de nada que unos cascos sean casi perfectos en todo si luego el cable se pela y parte al poco tiempo.

Primera prueba: pinganillos bluetooth

La PS3 soporta el uso de un pinganillo bluetooth, de estos que van en una oreja como los de los teléfonos, para comunicarnos. Y puesto que es una opción barata y la que usaban la mayoría de mis amigos, fue mi primera opción. Al principio compré un pinganillo genérico en Carrefour, pero tuve bastantes problemas: a veces tenía interferencias con el mando, que también se comunica por bluetooth. Además, la batería no aguantaba una sesión de más de dos horas aunque estuviera completamente cargada, o incluso se descargaba muy rápido sin usarse, por lo que muchas veces no podía usarlo por tener que estar cargando. La calidad de la voz tal como la escuchaban los otros jugadores tampoco era para tirar cohetes.

Así que al poco tiempo adquirí otro pinganillo "especial para PS3" que en concreto es el modelo Gioteck EX02 S. Este fue una mejora notable con respecto al genérico tanto en duración de batería como en ausencia de interferencias con el mando o calidad del sonido. La evaluación la haré de este segundo pingaillo.

Evaluación:

  • Comodidad: Muy buena. No se nota que los llevas y apenas pesan nada. Sin cable, claro.
  • Calidad del micro: Muy buena. Mis compañeros me escuchaban bien y cuando se lo regalé a un amigo yo le escuchaba mucho mejor que con el pinganillo genérico que tenía antes.
  • Polivalencia: Mala. Vale para la PS3 y para el teléfono, pero no lo vamos a usar con música aunque podamos al cubrir solo una oreja.
  • Calidad del sonido: No aplica. El sonido del juego sale por la TV.
  • Calidad del sonido envolvente: No aplica, por lo mismo que el punto anterior.
  • Precio: Bueno. Por 20 euros salimos del paso y podemos comunicarnos con los amigos; si estamos acostumbrados a jugar con el sonido de la TV no vamos a echar nada de menos.
  • Calidad de materiales: Muy buena. No tuve ningún problema y el cacharrín parece muy sólido.

Veredicto: si tenemos un sistema 5.1 o 7.1 real en la habitación y queremos disfrutarlo, el Gioteck (o cualquier otro pinganillo de calidad que no interfiera con el mando) es la mejor opción. Si no somos exigentes y nos conformamos con el sonido de la TV, también. En cualquier otro caso, es mejor mirar otras opciones.

Segunda prueba: Sharkoon X-Tatic Digital

Estos cascos me los recomendó un amigo y la verdad es que, pese a sus defectos, están muy bien por el precio. Son unos cascos con cable que tenían buena calidad de sonido y buena sensación de espacialidad. El problema era, que el cable se terminaba rompiendo (primero se pelaba y luego se le iban los cobres, que tuve que resoldar, le pasó a un amigo también) y luego eran algo incómodos. Fueron los que más tiempo usé.

Una característica interesante de estos cascos es que se puede regular independiéntemente el volumen de la voz y el sonido, algo que parece básico pero que como veremos no tiene ninguno de los otros headsets evaluados.

  • Comodidad: Muy baja. Con cable, con centralita, son pesados y dan bastante calor. Además la centralita necesita conectarse a corriente, con lo cual añadimos un enchufe más a nuestra seguramente ya saturada regleta.
  • Calidad del micro: Muy buena. Cuando un amigo que tiene éstos y los Sony los lleva se distingue claramente por la claridad de sonido.
  • Polivalencia: Buena, se puede escuchar música o ver películas con ellos (con un adaptador).
  • Calidad de sonido: Buena. No fueron los mejores ni los peores, para la mayoría de la gente será suficiente. El Bad Company 2 en modo "sonido de guera" (mi mejor benchmark) sonaba estupéndamente.
  • Calidad del sonido envolvente: Buena. Con un juego con un buen 5.1 o 7.1 se distinguía con un ángulo aceptable de unos 30 grados la dirección del sonido.
  • Precio: Regular. 100 euros por unos cascos con cable no es caro pero tampoco barato, sobre todo compitiendo con los Sony inalámbricos.
  • Calidad de los materiales: Mala. El cable que entra al auricular se suele pelar y romper. Las almohadillas se descoloran y desgastan con poco uso. A otra gente en Internet se le casca la centralita con demasiada frecuencia. Hay que mimarlos si queremos que duren.

Veredicto: si queremos gastarnos más de 100 euros y no nos importa ganar calidad de sonido y espacial a costa de que los cascos sean cableados los Sharkoon serán mejor opción que los Sony. Si quieres calidad de sonido alta y puedes gastar más, sigue leyendo, tanto si los quieres con cable como sin el.

Tercera prueba: Sony 7.1 PS3 headset

Este es el headset oficial de Sony para la PS3. Además de la comodidad, que evaluo más abajo, tiene otros detalles interesantes como que los menús de los cascos se muestren en la TV a través de la PS3. La carencia de centralita hace que sea muy fácil guardardos y no nos llene el mueble de la TV/PS3 de cables, enchufes y centralitas. Además, el precio es bueno para lo que ofrece (yo no he visto ningún otro headset 7.1 inalámbrico por 100 euros).

  • Comodidad: Excelente. Inalámbricos, la batería tiene una duración razonable (unas 5-7 horas), sin pilas, sin centralita, pesan poco, dan poco calor y además tiene menú en pantalla con la PS3. De todos los evaluados, son los más cómodos sin duda. La única pega es que el control de volumen es de tipo "si subes el audio bajas la voz".
  • Calidad del micro: Media. A los que llevan estos cascos tengo que subirles mucho el volumen para escucharles bien (con lo cual si entra uno con los Sharkoon me deja sordo). El amigo que tiene los Sharkoon y estos se nota con claridad cuando lleva estos porque suena peor, no sólo más bajo sino también con un sonido menos definido.
  • Calidad del sonido envolvente: Media. De los headset propiamente dichos que he evaluado, son los que más costaba determinar la dirección del sonido (unos 50 grados de precisión, a ojímetro).
  • Precio: Muy Bueno. 100 euros por unos cascos inalámbricos Sony.
  • Calidad de los materiales: Muy buena. Parecen sólidos y no tuve ningún problema.

Veredicto: si nos basta con una calidad de sonido, micro y espacialidad suficiente pero no sobresaliente y queremos unos cascos cómodos e inalámbricos sin irnos de precio, los Sony son nuestra opción.

Cuarta prueba: Turtle Beach PX5

Siguiendo en mi Santa Búsqueda del Headset Perfecto y guíado por algunas reviews muy buenas, vendí los Sony y los Sharkoon (bendito ebay) y adquirí estos. Los Turtle Beach son inalámbricos y muy superiores en calidad sonido a los Sony o Sharkoon. Además tienen una característica interesante y es que son programables con distintos presets tanto de la compañía como de terceros que alteran la forma de representar el sonido o la espacialidad. Por ejemplo, para el MW3 existen unos presets de la propia Infinity Ward (el estudio que hace el juego) que funcioban realmente bien, sobre todo los de "amplificar pasos". También hay presets para hacer el chorra poniendo voz de pato acelerado, monstruo o robot (lo que mejora mucho esos momentos compartiendo insultos con los contrarios entre partidas). Los presets se pueden descargar y si somos manitas hasta podemos crear los nuestros en el ordenador usando un editor.

Por desgracia los PX5 tienen un serio problema, y es que cuando hay una WIFI cerca transmitiendo datos se generan interferencias en el sonido y también en el micro, lo cual hace muy molesto su uso. Yo tengo el router muy cerca de la PS3, así que quedármelos no era una opción. Amazon me devolvió el dinero sin problemas.

  • Comodidad: Buena. No son tan cómodos como los Sony porque pesan un poco más, pero tampoco mucho (bastante menos que los Sharkoon en todo caso). No dan apenas calor. Tienen la desventaja de que usan pilas de tipo AA en los auriculares, pero la ventaja de que con unas pilas recargables de alta capacidad pueden llegar a aguantar 20 horas o más (en comparación con las 6-7 horas de los
    Sony). Usan centralita. La centralita se alimenta por conexión a la corriente, lo cual es un punto negativo.
  • Calidad del micro: nunca escuché a alguien con ellos, pero me comentaron que se me escuchaba bien, sobre todo cuando hacía el tonto con el cambiador de voces.
  • Calidad del sonido envolvente: Muy buena. Salvo por el kit con los Beyer + ASTRO MixAmp, es decir, de los headsets que salen de fábrica como tales, eran los que mejor dejaban identificar la dirección del sonido. A ojímetro, un ángulo de 10-20 grados de precisión.
  • Precio: Bueno. Sobre 180 euros. Es verdad que no son los 100 de los Sony o los Sharkoon, pero son mejores en casi todo a ambos.

Quinto intento: kit "artesanal" con Beyerdynamic DT770Pro + MixAmp + Micro + FiiO E5

Tras ver los problemas con los PX5 y la WIFI y devolverlos a Amazon, decidí hacer algo que tenía en mente desde hacía tiempo. El origen de la idea es que alguna vez he jugado con mis auriculares intra Westone 3. Son unos auriculares de 300 euros pero que valen cada uno de ellos porque con ellos toda la música sube a otro nivel que no se puede explicar a quien no ha probado unos auriculares de esta calidad antes. El problema de usar los Westone como auriculares es que, aparte de no tener micro, con el tipo de sonidos que se reproducen en los shooters (disparos, explosiones) las vibraciones terminan haciendo que el canal auditivo duela, por lo que para mi era imposible usarlos más de media hora seguida, pero esos minutos que jugaba eran increíbles; aunque el sonido no fuera envolvente sino estereo se podían escuchar perfectamente sonidos que es casi imposible percibir con cualquiera de los otros auriculares probados. Se escuchan los casquillos caer al suelo con un toque metálico evidente, se escucha cada disparo con una plenitud impresionante, et cétera.

Decidí probar una solución "mixta" es decir, coger unos cascos de calidad para música (pero no intraauriculares para que no duela el canal), una centralita 7.1, siendo la más popular (y compatible con PS3) la Astro MixAmp, y con la centralita pegar un micrófono de PC de calidad decente a los cascos para completar el sistema. El primer paso era consultar con alguien entendido en cuestiones audiófilas que cascos podían darme una calidad buena en el rango de aplicación de un videojuego y en el rango de precios que estaba dispuesto a gastar, que eran unos 200 euros teniendo en cuenta que además del dinero devuelto de los PX5 iba a vender los Westone 3 por resultarme incómodos y no necesitarlos con unos cascos de buena calidad que valieran también para música (de la venta de los Westone saqué otros 200 euros, así que al final la operación me salió rentable).

Como esta parte va a ser larga porque voy a explicar todos los componentes que "junté", mi análisis individual de cada uno y los precios voy a poner primero la puntuación de cada apartado por si alguien tiene prisa:

  • Comodidad: Buena. Los cascos son cómodos de llevar, pesan menos que los Sharkoon pero más que los Sony (más o menos como los PX5.) La única pega es que el material de las almohadillas puede dar algo de calor al ser textil (pero menos que los Sharkoon). El cable combinado de micro+cascos puede ser un incordio, pero se soluciona juntándolos (ver más abajo). El MixAmp se alimenta por USB por lo que no hay que enchufar nada más a la pared.
  • Calidad del micro: Buena. Mis compañeros me escuchaban bien, y lo he usado para hacer alguna grabación que se escucha bien.
  • Polivalencia: Excelente. Al usar los cascos y el micro conexiones jack, valen para el móvil, la tele o (con el MixAmp) jugar.
  • Calidad del sonido: Fantástica. Son unos cascos para bastante buenos. El sonido es pleno y definido. Los bajos potentes. La música y los juegos con un sonido cuidado se disfrutan mucho más que con otras opciones. El único problema que tienen es que los graves son un poco-demasiado fuertes, lo cual está muy bien escuchando música, viendo películas, o con juegos single player pero en multijugador competitivo tantos bajos (tiros, explosiones, etc) llegan a enmascarar cosas que nos interesa más escuchar para aumentar nuestra efectividad como los pasos de un enemigo o el sonido que hace al recargar detrás de una esquina.

  • Calidad del sonido envolvente: Excelente. El MixAmp hace un trabajo realmente bueno (es Dolby Virtual 2.0 frente al 1.0 o 1.1 de los otros headsets). Probando con mi mujer a identificar por donde venía un sonido dentro del juego Mass Effect (yo cerraba los ojos, ella le daba la vuelta a la vista con el mando, y yo tenía que identificar señalando y sin abrir los ojos de donde venía un sonido determinado), conseguía acortar la dirección del sonido con un ángulo pequeñísimo de 5 a 10 grados.

  • Precio: Bueno. De acuerdo, en total son 305 euros (142 de los Beyer, 140 del MixAmp, 8 del ampli y 15 del micro), pero hay que considerar que el headset para juegos que vende la propia Beyerdynamic usando estos auriculares, el MMX 300, vale 350 euros y sigue haciéndole falta un MixAmp para tener sonido surround y compatibilidad con PS3 (con lo cual el precio total sería de 470 euros). Además, 305 euros es lo que vienen a valer unos intrauriculares de gama media, y con estos Beyerdynamic tenemos unos cascos de calidad comparable (no necesariamente mejor, pero al menos comparable) y mucho más.
  • Calidad de materiales: Excelente. Tanto en los Beyer como en el ASTRO MixAmp se nota el precio en los materiales, detalles y acabados. De momento (junio de 2012, tres meses de uso) no he tenido ningún problema de fiabilidad; si lo tuviera actualizaría el artículo.

"Fabricación" del kit

La persona a consultar de mi círculo social sobre que cascos comprar era sin duda mi amigo Juan Prada, que entre otras cosas es un DJ con mucha experiencia y un audiófilo experto. Tiene sesiones más que recomendables tanto en su página en Tumblr como en iTunes. Aconsejo encarecídamente al lector que se pase a visitarlas porque aunque no le guste la música electrónica puede sorprenderse.

El caso es que Juan me aconsejó adquirir unos Beyerdynamic DT770Pro y tras hacerlo y hacerles el "burning" inicial reproduciendo un fichero de audio con ruído rosa durante unas horas, pude comprobar que la calidad del sonido, tanto en juegos como en música y películas, estaba a un nivel muy superior del resto de headsets comentados en este artículo.

Una vez resuelto el asunto de que auriculares usar para mi nuevo headset, faltaba adquirir un mixer que proporcionase compatibilidad con la PS3 tanto para sonido como para audio y sonido surround 7.1. Realmente no hay muchas opciones con estos requisitos, y de las que hay investigando un poco por Internet parece que hay casi unanimidad en que el mixer a comprar es el ASTRO MixAmp. Hay que decir que Astro también vende una una solución integrada (Astro A40) usando su mixer y unos auriculares con micrófono incorporado pero por lo que he leído en otras reviews (uno no puede comprarse todo y a veces tiene que fíarse de las opiniones de otros) la calidad de sus auriculares es bastante inferior a la de los Beyer. Pero para alguien a quien no le importe perder calidad de sonido ahorrando 75 euros sobre mi solución y manteniendo la espacialidad casi perfecta es una buena solución y por lo que he leído la calidad de sonido los auriculares sigue siendo superior a la de los Sharkoon o Sony.

El ASTRO MixAmp se conecta con la PS3 por un conector óptico para el audio y con un conector USB que sirve tanto para la transmisión bidireccional de la voz como para la alimentación de corriente. Al probar el ASTRO MixAmp y tiene entradas de tipo minijack tanto para los cascos como Aunque al no necesitar ser enchufado a corriente es fácil guardarlo después de jugar, la estética del cacharro en negro piano y aluminio es bastante agradable y se integra perfectamente con mi plasma LG y la PS3, por lo que yo prefiero dejarlo.

Al probar los DT770 con el ASTRO MixAmp detecté un problema: el volumen aún con el dial del ASTRO MixAmp a tope no era todo lo alto que a mi me gusta cuando quiero inmersión total. Esto se debe a que, como todos los auriculares de calidad, los Beyererdynamic tienen una resistencia más alta de lo normal, en este caso de 80 ohmios, que sin ser alta cuando nos movemos en las gamas altas, es lo suficientemente alta como para que la salida del ASTRO MixAmp se quede corta en cuanto a volumen.

Por lo tanto hacía falta un amplificador, otro cacharro más. Consulté de nuevo con Juan, que sospecho ya debía estar un poco hasta las pelotas, y me aconsejó comprar algún amplificador de la gama Fiio por ser buenos, bonitos y baratos. Yo no quería engordar mucho mi "kit" y además tampoco necesitaba muchísimo más volumen (solo un poco más) por lo que opté por la segunda opción más pequeña y barata de su gama, el Fiio E5, que cuesta 17 euros en Amazon.es. Tienen uno más barato, el E3, pero necesita pilas AA para funcionar y yo prefiero prescindir de pilas; el Fiio E5 se carga por USB y tiene batería.

Una vez recibido el Fiio comprobé con satisfacción como el volumen máximo (midiéndolo con un programa de Android) pasaba de 82 decibelios a 93. Hay que recordar que los decibelios son una escala logarítmica, por lo que el incremento fue de cuatro veces el volumen. Con eso se solucionó el problema de volumen. El E5 lo dejé pegado el ASTRO MixAmp mediante velcro; como se puede ver en la imagen, se conecta la salida de audio del ASTRO MixAmp a la entrada del E5 y conectaremos los cascos al E5 (pero el micro al ASTRO MixAmp). Con el E5 surgió un nuevo problema. Como he dicho antes el E5 tiene una batería que se recarga por USB, y mi idea era dejar el USB siempre conectado, pero noté que cuando está cargando se escucha como un susurro de fondo. Eso no pasa con otras opciones de gama más alta ni supongo que con el E3 al tener alimentación por pilas, pero no es mucho problema, simplemente desconecto el cable USB antes de jugar y el sonido se va; a pesar del pequeño tamaño la batería dura muchísimo por lo que no hay problema en ese sentido. Alguna vez me he olvidado de conectar el USB durante varios días y nunca se me ha muerto.

El paso final para tener un sistema completo era adquirir un micrófono y pegarlo a los cascos. Realmente vale cualquier micro de PC, pero ya que me había puesto quería uno que sonara bien y tuviera esa "esponjilla" (boon en inglés) que elimina los sonidos de fondo. Además para no desentonar, tenía que ser negro. Leyendo de otra gente que había hecho headsets de tipo kit, vi que el más recomendado era el Labtec LVA-7330. Por desgracia Labtec ya no lo fabrica, pero hay un vendedor de Jordania en ebay que aún tiene varios en stock por 7 euros.

Una vez recibido el micro hay que usar un cutter o un buen cuchillo para cortar la parte que iría alrededor de la cabeza dejando solo la parte donde va la base del propio micrófono que es giratoria de modo que cuando no estemos hablando o cuando estemos escuchando música podremos levantar el micro para que no moleste o acercarlo y alejarlo de la boca.

Finalmente, pegué un trozo de velcro a la base del micro (esta vez usé un velcro de los que en vez de tejido son como de plástico, más fuerte y duradero) y el otro lado del velcro a un lateral de los auriculares. La conexión se realizó sin problemas y el micro queda bien fijado. Se podría también usar un pegamento fuerte o resina epoxi para obtener una conexión más fuerte, pero yo prefiero usar velcro porque si en algún momento quiero vender alguno de los componentes basta con despegarlo y limpiar con un trapo y un poco de agua caliente para que no haya ningún resto de que ahí hubo algo. Con pegamento sería bastante más dificil y con epoxi casi imposible.

Faltaba para terminar solucionar el tema de los cables. Como el micro y el headset tienen cada uno su cable quería juntarlos porque si no ya sabemos los líos de cables que se podrían terminar haciendo. Para juntarlos y garantizar la "separabilidad" en el futuro, usé simplemente usé unas bridas de plástico.
También se podría usar silicona (más difícil de dejar "limpio" si queremos) o un agrupador de cables helicoidal (que es muy probable que se termine moviendo arriba y abajo con el ajetreo de sacar y guardar los cascos).

Una cosa que aconsejo antes de unir los cables con la brida es enlazarnos en espiral para que se muevan menos como se ve en la imagen; sino se hace así los cables entre las bridas se separarán, y aunque no afectará negativamente a la funcionalidad quedará feo. Hay que tener cuidado de que la espiral no sea muy cerrada porque sino puede que el cable del micro se nos quede corto, según la distancia a la que estemos de la TV. También recogí con un par de bridas la parte sobrante de los Beyer para que los dos minijack quedasen más o menos a la misma altura.

El resultado de todo esto es que encontré una solución que me propocionaba una calidad de sonido excelente, polivalencia para juegos, música y películas, voz, y un surround excepcional.

Quien quiera una solución más inalámbrica debe saber que Astro vende también un mixer sin cables, que además va por la frecuencia de 5GHZ por lo que es improbable que tenga muchas interferencias, pero teniendo en cuenta que juego a dos metros de la TV, que el Mixer inalámbrico es más caro y hay que andar cargando la parte que va a los cascos y que el cable de los Beyerdynamic son muy largos (y no quiero cortarlos) no tiene sentido para mi usar esa opción.

Sexto intento: Audio Technica ATH-AD700 + MixAmp + Micro

Que se le va a hacer. Parece que si no me compro unos auriculares cada tres meses me aburro. Bueno. Estaba bastante contento con mi solución con los Beyerdynamic con el MixAmp, pero con el tiempo el problema de los graves demasiado fuertes que impiden escuchar bien los pasos se me hacía cada vez más molesto porque ¿de que sirve tener una buena espacialidad si en los shooters nos sigue apuñalando por la espalda un kinki con cuchillo? Y dado que yo el 80% del tiempo que juego es a shooters, decidí buscar unos cascos más adecuados para ese tipo de sonido, que mantuvieran la calidad general de los Beyer pero tuvieran menos bajos. Investigando un poco parece que los Audio Technica ATH-AD700 cumplían con esas premisas, así que me compré unos. Quedé muy satisfecho con el resultado, así que aquí va la evaluación:

  • Comodidad: Muy buena. Son tan cómodos como los Sony 7.1, pesan poco (son de aluminio). Usan un extraño sistema de suspensión sobre la cabeza de forma que aprieten muy poco. La contrapartida es que si movemos mucho la cabeza se pueden mover. Además, como tienen menor impedancia que los Beyer, no hace falta el amplificador Fiio con lo que nos quitamos un (pequeño) cacharro de en medio.
  • Calidad del micro: buena, la misma que con los Beyer ya que uso el mismo.
  • Polivalencia: Excelente, conexión jack que vale para todo.
  • Calidad del sonido: Muy buena. Quizás un pelo por debajo de los Beyer, y los bajos son muy flojos (bueno para shooters, malo para lo demás), pero aún muy por encima de los "Gaming Headsets" comentados hasta ahora.
  • Calidad del sonido envolvente: Excelente, ya que sigue siendo con el MixAmp. Precisión de 5 a 10 grados.
  • Precio: bueno, unos 120 euros por unos auriculares de calidad.
  • Calidad de materiales: Muy buena. A pesar de la ligereza, da una buena sensación de calidad, aunque sin llegar a la solidez extrema de los Beyer.

Séptimo ¿y final? intento: Sony Pulse Elite

Estaba yo contento con mi solución del MixAmp + Micro + ATH-AD700 cuando en una tienda vi que Sony había sacado unos nuevos cascos para la PS3, los Sony Pulse Elite. Indagando por Internet vi que los cascos tenían muy buenas reviews en cuanto a la calidad del sonido (cosa que no pasaba con los anteriores de Sony) y además tenían una conexión jack para usarlos como cascos normales con equipos de música o la TV, por lo que me los compré en un sitio donde se pueden devolver las cosas sin preguntas por si no me gustaban, pero no ha hecho falta porque estos cascos de Sony me han sorprendido con una calidad de sonido similar a la de los Audio Technica pero con unos bajos mejores a pesar de los cuales los pasos no se enmascaran como pasaba con los Beyer. Así que los Audio Technica ATH-AD700 y el MixAmp están de momento a la venta (los Beyer los voy a seguir conservando para música y películas) y me quedo con los Sony Pulse para jugar (hasta que me de la vena de probar otra cosa mejor, claro).

Aparte de la calidad del sonido y la integración, una cosa que me gusta mucho de estos cascos es la estética, que es bastante resultona y como el micro va integrado en los cascos (no sobresale) por fin dejamos de parecer un teleoperador. Una característica interesante de estos cascos es que además de tener una entrada jack en los cascos para usarlos como cascos normales con reproductores de audio o la TV, el pincho USB que normalmente va a la PS3 o PC también tiene una entrada jack, por lo que si lo tenemos conectado a cualquier cosa que le de corriente, podemos conectar el reproductor o la tele y los cascos seguirán siendo inalámbricos. Bien pensado por parte de Sony.

Evaluación:

  • Comodidad: Muy buena. No son tan cómodos como los anteriores de Sony porque pesan un poco más y aprietan más la cabeza, pero siguen siendo muy cómodos, sobre todo por no tener cables de ningún tipo. La única pega es que la batería dura unas 5-6 horas por lo que hay que cargarlos con bastante frecuencia.
  • Calidad del micro: Buena. Además como va integrado, ni se ve ni molesta. Tiene botón de mute en los propios cascos.
  • Polivalencia: Fabulosa, conexión jack que vale para todo, USB para los juegos con sonido envolvente (PS3 o PC), y además el USB tiene entrada jack para usarlos con cualquier cosa de forma inalámbrica.
  • Calidad del sonido: Muy buena. Al nivel de los AD700, un poco por debajo de los Beyer, buenos bajos que no enmascaran otros sonidos, tiene varios presets aunque no he probado bien la diferencia. Con música si usamos la conexión jack se pueden amplificar un poco.
  • Calidad del sonido envolvente: Excelente, una precisión y profundidad similar al MixAmp.
  • Precio: Muy bueno, son los mejores "gaming headsets" que he probado, son más polivalentes que el resto y no son los más caros.
  • Calidad de materiales: Buena. Los cascos parecen bastante sólidos pero el material del acolchado es plástico que en verano puede dar calor.

Apéndice: otras opciones populares

Hay otras soluciones que no he probado, ni creo que pruebe por estar satisfecho de momento con los Sony Pulse Elite, pero que merecen ser comentadas por ser también bastante populares.

  • La marca Tritton es muy popular entre gamers. Tiene varios modelos compatibles con la PS3, entre ellos:

    • Tritton AX Pro: por unos 200 euros tenemos unos headset inalámbricos y con sonido 5.1 "auténtico", lo que quiere decir que no usa modelos psicoacústicos para engañar a nuestro cerebro haciéndole pensar que escuchamos los sonidos desde distintas posiciones, sino que tiene realmente distintos pequeños altavoces. Sin embargo no hay que pensar que esto es automáticamente mejor; por lo que he leído en foros de audiófilos la espacialidad que se puede conseguir con unos altavoces que realmente están separados por solo unos milímetros no es muy buena, y puede llegar a ser inferior a un buen modelo psicoacústico como el que produce el MixAmp (que a su vez sería inferior a un sistema surround de verdad, con altavoces repartidos por la habitación). El que tenga dudas de la capacidad de los algortimos psicoacústicos para representar la espacialidad del sonido, que escuche el sonido de este vídeo de Youtube con unos cascos estero.

    • Tritton AX 720: sonido 7.1 virtual y cableados. Dicen que la calidad de los auriculares es la mejor de todos los integrados, incluso alguien en reddit me juraba que es similar a los Beyerdynamic (algo que me permito dudar hasta que los pruebe). Personalmente creo que 170 euros es bastante caro para unos auriculares cableados.


« Anterior 1 2 3 4 5 6 ... 14 15 Next »