domingo, abril 18, 2010

Cómo obtener la URL verdadera hacia un sitio usando el buscador Google?

Es tan fácil esto, se supone que cuando nosotros ponemos el mouse (puntero) sobre en enlace, este muestra la URL verdadera, pero cuando ponemos "copiar" usando el mouse... esta simplemente se distorsiona mostrando un enlace totalmente diferente, esto se debe a que google utiliza un método de direccionamiento, probablemente para mejorar su método de indexación osea mostrar el sitio que tenga más accesos más arriba entre sus listas de búsquedas...

SOLUCIÓN:
Si usas un navegador que permita extensiones, instala algún programa para evitar los scripts... así podrás bloquear los scripts que usa Google en su buscador web.

Si usas Mozilla Firefox, es tan fácil como instalar NoScript, QuickJava, o cualquiera que bloquee los scripts... en mi caso me ha funcionado de maravilla "NoScript".

Seamonkey, Opera ni Google Chrome son afectados.
Por defecto no realizan ese "redireccionamiento"... así que quienes usen esos navegadores no deberían tener ese problema...

jueves, abril 15, 2010

Cómo Solucionar el problema que bajo linux el micrófono no captura?

La línea mágica para mi caso es:

options snd-hda-intel model=eapd probe_mask=1 position_fix=1


Esta linea la ponemos dentro de un archivo con nombre a gusto en:

/etc/modprobe.d/pulseaudio.conf



Muy bien, esto es un problema que me estuvo molestando por unos buenos meses, todo debido a un problema en el reconocimiento de mi tarjeta, expliquemos el problema...

el sonido funciona excelente... pero Skype, gnome-Sound-recorder y arecord simplemente NO CAPTURAN NADA!, inclusive yendo al gestor de sonido o "preferencias de sonido" en la pestaña "ENTRADA" la cual cuando hablo no se mueve(la barra que indica la captura de sonido), ahora la solución es tan increíble, pero tan simple, que te caes de poto al saber que una línea te soluciona el problema... Un detalle, esta línea me sirvió a mí en mi laptop Gateway NV5214u bajo Fedora 12, espero que sirva en varios o todos los modelos, el chipset que incorpora este laptop es un AMD 690 o 780, no estoy seguro, pero la tarjeta es la siguiente:

[maximi89@gateway ~]$ lspci|grep -i audio
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA)
01:05.1 Audio device: ATI Technologies Inc RS780 Azalia controller

[maximi89@gateway ~]$ cat /proc/asound/hwdep
00-00: HDA Codec 0
01-00: HDA Codec 0
[maximi89@gateway ~]$ cat /proc/asound/card0/codec#0 |grep -i codec
Codec: Conexant CX20561 (Hermosa)
[maximi89@gateway ~]$ cat /proc/asound/card1/codec#0 |grep -i codec
Codec: ATI RS690/780 HDMI


Cómo pueden apreciar, el codec es Conexant CX20561, Tarjeta de audio Azalia (Intel HDA).
Además, si al hacer un "dmesg|grep -i hda-intel"
este arroja el siguiente mensaje (como era en mi caso...):

hda_intel: azx_get_response timeout, switching to polling mode:
last cmd=0x12345678
hda_intel: azx_get_response timeout, switching to single_cmd mode:
last cmd=0x12345678


Para el mensaje anterior, deben ir probando diferentes configuraciones usando "position_fix=" 0, 1 y 2 según se aprecia en el capítulo 2.2 pegado aquí mismo más abajo, según entiendo serían esos valores, esto se debe a que la tarjeta de audio no es reconocida correctamente a través de la BIOS, usen esta opción para corregirlo:
"position_fix="

Deben probarla poniéndola en un archivo en /etc/modprobe.d/XXXda


Enlace a los documentos del Kernel Linux:
http://www.kernel.org/pub/linux/kernel/people/tiwai/docs/HD-Audio.html

Deben agregarla en un archivo en /etc/modprobe.d/, en mi caso creé el siguiente archivo /etc/modprobe.d/snd-hda-intel


La línea mágica es:

options snd-hda-intel model=eapd probe_mask=1 position_fix=1

No tengo idea que es lo que hace esa línea exactamente, pero existen diferentes modelos (model=) a usar, al parecer según el codec.... o circuitería del chip de audio...
http://ubuntuforums.org/archive/index.php/t-314383.html

Para el MODEL= vean el siguiente enlace...
http://www.mjmwired.net/kernel/Documentation/sound/alsa/ALSA-Configuration.txt

Ahí salen diferentes configuraciones para diferentes computadores... así que ustedes vean cual les sirve para sus usos.

Según el primer enlace dado, en el texto a continuación podrán apreciar en el capítulo 2.1 la variable position_fix=X, capítulo 2.2 probe_mask=X, capítulo model=X donde la X corresponde a la opción ingresada.



2.1. DMA-Position Problem

The most common problem of the controller is the inaccurate DMA pointer reporting. The DMA pointer for playback and capture can be read in two ways, either via a LPIB register or via a position-buffer map. As default the driver tries to read from the io-mapped position-buffer, and falls back to LPIB if the position-buffer appears dead. However, this detection isn’t perfect on some devices. In such a case, you can change the default method via position_fix option.

position_fix=1 means to use LPIB method explicitly. position_fix=2 means to use the position-buffer. 0 is the default value, the automatic check and fallback to LPIB as described in the above. If you get a problem of repeated sounds, this option might help.

In addition to that, every controller is known to be broken regarding the wake-up timing. It wakes up a few samples before actually processing the data on the buffer. This caused a lot of problems, for example, with ALSA dmix or JACK. Since 2.6.27 kernel, the driver puts an artificial delay to the wake up timing. This delay is controlled via bdl_pos_adj option.

When bdl_pos_adj is a negative value (as default), it’s assigned to an appropriate value depending on the controller chip. For Intel chips, it’d be 1 while it’d be 32 for others. Usually this works. Only in case it doesn’t work and you get warning messages, you should change this parameter to other values.


2.2. Codec-Probing Problem

A less often but a more severe problem is the codec probing. When BIOS reports the available codec slots wrongly, the driver gets confused and tries to access the non-existing codec slot. This often results in the total screw-up, and destructs the further communication with the codec chips. The symptom appears usually as error messages like:

hda_intel: azx_get_response timeout, switching to polling mode:
last cmd=0x12345678
hda_intel: azx_get_response timeout, switching to single_cmd mode:
last cmd=0x12345678

The first line is a warning, and this is usually relatively harmless. It means that the codec response isn’t notified via an IRQ. The driver uses explicit polling method to read the response. It gives very slight CPU overhead, but you’d unlikely notice it.

The second line is, however, a fatal error. If this happens, usually it means that something is really wrong. Most likely you are accessing a non-existing codec slot.

Thus, if the second error message appears, try to narrow the probed codec slots via probe_mask option. It’s a bitmask, and each bit corresponds to the codec slot. For example, to probe only the first slot, pass probe_mask=1. For the first and the third slots, pass probe_mask=5 (where 5 = 1 | 4), and so on.

Since 2.6.29 kernel, the driver has a more robust probing method, so this error might happen rarely, though.

On a machine with a broken BIOS, sometimes you need to force the driver to probe the codec slots the hardware doesn’t report for use. In such a case, turn the bit 8 (0x100) of probe_mask option on. Then the rest 8 bits are passed as the codec slots to probe unconditionally. For example, probe_mask=0x103 will force to probe the codec slots 0 and 1 no matter what the hardware reports.


3. HD-AUDIO CODEC
3.1. Model Option

The most common problem regarding the HD-audio driver is the unsupported codec features or the mismatched device configuration. Most of codec-specific code has several preset models, either to override the BIOS setup or to provide more comprehensive features.

The driver checks PCI SSID and looks through the static configuration table until any matching entry is found. If you have a new machine, you may see a message like below:

hda_codec: ALC880: BIOS auto-probing.

Meanwhile, in the earlier versions, you would see a message like:

hda_codec: Unknown model for ALC880, trying auto-probe from BIOS...

Even if you see such a message, DON’T PANIC. Take a deep breath and keep your towel. First of all, it’s an informational message, no warning, no error. This means that the PCI SSID of your device isn’t listed in the known preset model (white-)list. But, this doesn’t mean that the driver is broken. Many codec-drivers provide the automatic configuration mechanism based on the BIOS setup.

The HD-audio codec has usually "pin" widgets, and BIOS sets the default configuration of each pin, which indicates the location, the connection type, the jack color, etc. The HD-audio driver can guess the right connection judging from these default configuration values. However — some codec-support codes, such as patch_analog.c, don’t support the automatic probing (yet as of 2.6.28). And, BIOS is often, yes, pretty often broken. It sets up wrong values and screws up the driver.

The preset model is provided basically to overcome such a situation. When the matching preset model is found in the white-list, the driver assumes the static configuration of that preset and builds the mixer elements and PCM streams based on the static information. Thus, if you have a newer machine with a slightly different PCI SSID from the existing one, you may have a good chance to re-use the same model. You can pass the model option to specify the preset model instead of PCI SSID look-up.

What model option values are available depends on the codec chip. Check your codec chip from the codec proc file (see "Codec Proc-File" section below). It will show the vendor/product name of your codec chip. Then, see Documentation/sound/alsa/HD-Audio-Models.txt file, the section of HD-audio driver. You can find a list of codecs and model options belonging to each codec. For example, for Realtek ALC262 codec chip, pass model=ultra for devices that are compatible with Samsung Q1 Ultra.

Thus, the first thing you can do for any brand-new, unsupported and non-working HD-audio hardware is to check HD-audio codec and several different model option values. If you have any luck, some of them might suit with your device well.

Some codecs such as ALC880 have a special model option model=test. This configures the driver to provide as many mixer controls as possible for every single pin feature except for the unsolicited events (and maybe some other specials). Adjust each mixer element and try the I/O in the way of trial-and-error until figuring out the whole I/O pin mappings.

Note that model=generic has a special meaning. It means to use the generic parser regardless of the codec. Usually the codec-specific parser is much better than the generic parser (as now). Thus this option is more about the debugging purpose.


NOTA: esta configuración se realizó sobre un GATEWAY NV5214U usando Fedora 12 y pulseaudio 0.9.21