Posts Tagged ‘card’

Raspberry Pi – Cheap portable credit-card sized single board Linux computer box

Thursday, November 7th, 2013

RaspberryPi tiny-computer running Linux and free software Logo

Not of a the latest thing out there but I believe a must know for every geek is existence of Raspberry Pi mini computer Linux board. It is a geek credit-card sized mini PC on extremely cheap price between 25$ and 35$ bucks (e.g. Raspberry Pi model A and Raspberry Pi Model B).

Raspberry Pi hardware you get for this ultra low price is as follows:

  • Broadcom BCM2835 system on chip
  • ARM Mobile processor model ARM1176JZF running at 700 Mhz (overlocking up to 1Ghz is possible – overclocked RP is called Turbo 🙂 )!
  • VideoCore IV GPU with 512 MBytes of ram
  • No Build hard disk or solid-state drive but instead designed to use SD-Card as a Storage
  • two video outputs
  • composite RCA and an HDMI port
  • 3.5mm audio output
  • 2 or 1SD/MMC/SDIO card slot (depending on device model A or model B)
  • Micro USB adapter power charger 500mA  (2.5 watts) – Model and 700mA (3.5 watts)

Raspberry PI mini computer hardware running Linux explained picture

The idea of whole device is to make cheap affordable device for pupils and people from third countries who can't afford to pay big money for a full-featured computer. Achievement is unique all you need to Raspberry Pi credit card sized device is external keyboard a mouse, SD-card and a monitor, this makes a 700Mhz featured almost fully functional computer for less than lets say 80$ whether used with a second hand monitor / mouse and kbd :). A fully functional computer or full functional thin client for as less as 80$ yes that's what RaspberryPi is!

It is recommendable that SD-Card storage on which it is installed is at least 4GB as this is part of its minimum requirement, however it is best if you can get an SD-Card of 32GBytes whether you plan to use its whole graphic functionalities.

Raspberry Pi Hardware is not too powerful to run a version of Windows as well as there is no free version of MS-Windows for ARM Processor, so basicly device is planned to run free software OSes GNU / Linux. 5 operating systems are working fine with the mini-board device as time of writting;
 

  • Raspbian – Debian "Wheezy" Linux port
  • Pidora – Fedora mixed version ported to run on Raspberry Pi
  • Risk OS port
  • Arch Linux port for ARM devices
  • Slackware Arm
    FreeBSD / NetBSD
  • QtonPi

Recommended and probably best distro port is for Debian Squeeze

To boot an OS into raspberry PI dowbnload respective image from raspberrypi.org

– Use application for copying and extracting image to SD-Card like Win32 Disk Imager – whether on Windows platform

Win32DiskImager burning raspberry PI mini Linux card board computer box image

– Or from Linux format SD-Card with gparted (N!B! format disk to be in FAT32 filesystem), extrat files and copy them to SD-CARD.

Once Raspberry Pi loads up it will drop you into Linux console, so further configuration will have to be done manually with invoking plenty of apt-get commands (which I will not talk about here as there are plenty of manuals already) – you will have to manually install your Desktop … Default shipped Web browser in Debian is Midori and due to lack of ported version of flash player for ARM streaming video websites like youtube.com / vimeo.com does not work in browser. There is a Google Chrome for Raspberry Pi port but just like with Midori heavy object loaded websites works very slow and thus not very suitable for multimedia.

raspberry pi cheaest portable linux powered computer sized of a credit card

Raspberry Pi device is very suitable for ThinClient use there is a special separate project – Raspberry ThinClient Project – using which a hobbyist can save 400$ for buying proprietary ThinClient.

RaspberryPI linux as a free software hardware thinclient picture

 

HasciiCAM supposed to stream ASCII video over the network on GNU / Linux

Tuesday, May 22nd, 2012

Richard M. Stallman (RMS) Face portrait rendered in ASCII art from a video with hasciicam
To continue with my lately ASCII centered articles I found hasciicam
hasciicam is a program to stream ASCII video over the network on Linux and probably can be easily made working on FreeBSDtoo.

The project concept is interesting in a matter of fun (play) point of view, however not too usable as we all know ASCII character looking faces doesn't look too pretty.

Below is the Debian (Squeeze) package description:

noah:~# apt-cache show hasciicam|grep -i description -A 7
Description: (h)ascii for the masses: live video as text
Hasciicam makes it possible to have live ASCII video on the web. It
captures video from a tv card and renders it into ascii, formatting the
output into an html page with a refresh tag or in a live ASCII window or
in a simple text file as well, giving the possibility to anybody that has a
bttv card, a Linux box and a cheap modem line to show a live ASCII video
feed that can be browsable without any need for plugin, java etc.
Homepage: http://ascii.dyne.org/

On hasciicam Project webpage is it is stated as a hardware you need to have:
 

"As hardware you need to have a webcam or a videocard supported by "video 4 linux", most of the gear you can buy around should work well."

To install and test it I run:

noah:~# apt-get --yes install hasciicam

Though it is stated on the project website supposed to work display video fine with most 'linux ready' webcams, it didn't with this very standard one.

Here is the exact WebCamera model as identified to the kernel:

noah:~# dmesg|grep -i camera
[ 1.433661] usb 2-2: Product: USB2.0 Camera
[ 10.107840] uvcvideo: Found UVC 1.00 device USB2.0 Camera (1e4e:0102)
[ 10.110660] input: USB2.0 Camera as /devices/pci0000:00/0000:00:1d.7/usb2/2-2/2-2:1.0/input/input11

By the way, I use the very same CAM daily on for Skype video calls as well as the Camera is working with no problems to save video or pictures inside Cheese

Here is the exact WebCamera model as identified to the kernel:

noah:~# dmesg|grep -i camera
[ 1.433661] usb 2-2: Product: USB2.0 Camera
[ 10.107840] uvcvideo: Found UVC 1.00 device USB2.0 Camera (1e4e:0102)
[ 10.110660] input: USB2.0 Camera as /devices/pci0000:00/0000:00:1d.7/usb2/2-2/2-2:1.0/input/input11

The just installed deb has one binary file only /usr/bin/hasciicam. To test it with the camera I issued:

noah:~# hasciicam -d /dev/video0
HasciiCam 1.0 - (h)ascii 4 the masses! - http://ascii.dyne.org
(c)2000-2006 Denis Roio < jaromil @ dyne.org >
watch out for the (h)ASCII ROOTS

Device detected is /dev/video0
USB2.0 Camera
1 channels detected
max size w[640] h[480] - min size w[48] h[32]
Video capabilities:
VID_TYPE_CAPTURE can capture to memory
!! error in ioctl VIDIOCGMBUF: : Invalid argument

Unfortunately as you see from the output, it failed to detect the web camera model.
The exact camera besides its kernel detection naminf is a cheap external USB 2.0 (fake brand / nonanem) "universal" Web PC Camera (SUPER .3mega pixel)

For those who have a further interest in building and installing hasciicam on other Linux platforms than Debian and Ubuntu or whoever wants to look in the code check check Project webpage is. For those who are less of programmers (like me) the project is written in C programming language and uses aa-lib in order to render the video to ASCII.

On the site you will notice two totally schizophrenic looking pictures of presumably the project head developer …

hasciiart video streamed ASCII screenshot of some crazy looking guy smoking marijuanna or smth

As I read in man hasciicam manual page it's said to be able to generate ascii plain text and html files as well as directly to write the output to console, which later probably can be streamed via the network.
Pitily as it didn't detect my camera I couldn't make some testing of its network capabilities.

A Streaming of ASCII couuld be done through pushing the .html output to a webserver and setting a php or javascript to loop through and refresh the browser over the uploaded files every sec or so.

Also I assume the ASCII video output saved in plain console could be streamed via netcat or some tiny scripted perl or bash script and directly observed via a telnet or ssh connection.
One playful way I can think of checking a stored video without the use of FTP is to login via ssh and do:

$ ssh someuser@somehost
$ watch -n 1 "cat video-ascii.html"

🙂

Well something disturbing about hasciicam from a (purely Christian point of view) is it was developed by some kind of non profit organization called RastaSoft on the project website, some of its authors has written JAH BLESS.

As I didn't succeeded seeing it working, I'll be interested to hear if someone who red this article and give it a try can report the web camera model used.

FreeBSD Jumbo Frames network configuration short how to

Wednesday, March 14th, 2012

FreeBSD Jumbo Frames Howto configure FreeBSD

Recently I wrote a post on how to enable Jumbo Frames on GNU / Linux , therefore I thought it will be useful to write how Jumbo Frames network boost can be achieved on FreeBSD too.

I will skip the details of what is Jumbo Frames, as in the previous article I have thoroughfully explained. Just in short to remind you what is Jumbo Frames and why you might need it? – it is a way to increase network MTU transfer frames from the MTU 1500 to MTU of 9000 bytes

It is interesting to mention that according to specifications, the maximum Jumbo Frames MTU possible for assignment are of MTU=16128
Just like on Linux to be able to take advantage of the bigger Jumbo Frames increase in network thoroughput, you need to have a gigabyt NIC card/s on the router / server.

1. Increasing MTU to 9000 to enable Jumbo Frames "manually"

Just like on Linux, the network tool to use is ifconfig. For those who don't know ifconfig on Linux is part of the net-tools package and rewritten from scratch especially for GNU / Linux OS, whether BSD's ifconfig is based on source code taken from 4.2BSD UNIX

As you know, network interface naming on FreeBSD is different, as there is no strict naming like on Linux (eth0, eth1, eth2), rather the interfaces are named after the name of the NIC card vendor for instance (Intel(R) PRO/1000 NIC is em0), RealTek is rl0 etc.

To set Jumbro Frames Maximum Transmission Units of 9000 on FreeBSD host with a Realtek and Intel gigabyt ethernet cards use:freebsd# /sbin/ifconfig em0 192.168.1.2 mtu 9000
freebsd# /sbin/ifconfig rl0 192.168.2.2 mtu 9000

!! Be very cautious here, as if you're connected to the system remotely over ssh you might loose connection to it because of broken routing.

To prevent routing loss problems, if you're executing the above two commands remotely, you better run them in GNU screen session:

freebsd# screen
freebsd# /sbin/ifconfig em0 192.168.1.2 mtu 9000; /sbin/ifconfig rl0 192.168.1.2 mtu 9000; \
/etc/rc.d/netif restart; /etc/rc.d/routed restart

2. Check MTU settings are set to 9000

If everything is fine the commands will return empty output, to check further the MTU is properly set to 9000 issue:

freebsd# /sbin/ifconfig -a|grep -i em0em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000freebsd# /sbin/ifconfig -a|grep -i rl0
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000

3. Reset routing for default gateway

If you have some kind of routing assigned for em0 and rl0, network interfaces they will be affected by the MTU change and the routing will be gone. To reset the routing to the previously properly assigned routing, you have to restart the BSD init script taking care for assigning routing on system boot time:

freebsd# /etc/rc.d/routing restart
default 192.168.1.1 done
add net default: gateway 192.168.1.1
Additional routing options: IP gateway=YES.

4. Change MTU settings for NIC card with route command

There is also a way to assign higher MTU without "breaking" the working routing, e.g. avoiding network downtime with bsd route command:

freebsd# grep -i defaultrouter /etc/rc.conf
defaultrouter="192.168.1.1"
freebsd# /sbin/route change 192.168.1.1 -mtu 9000
change host 192.168.1.1

5. Finding the new MTU NIC settings on the FreeBSD host

freebsd# /sbin/route -n get 192.168.1.1
route to: 192.168.1.1
destination: 192.168.1.1
interface: em0
flags: <UP,HOST,DONE,LLINFO,WASCLONED>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
0 0 0 0 0 0 9000 1009

6. Set Jumbo Frames to load automatically on system load

To make the increased MTU to 9000 for Jumbo Frames support permanent on a FreeBSD system the /etc/rc.conf file is used:

The variable for em0 and rl0 NICs are ifconfig_em0 and ifconfig_rl0.
The lines to place in /etc/rc.conf should be similar to:

ifconfig_em0="inet 192.168.1.1 netmask 255.255.255.0 media 1000baseTX mediaopt half-duplex mtu 9000"
ifconfig_em0="inet 192.168.1.1 netmask 255.255.255.0 media 1000baseTX mediaopt half-duplex mtu 9000"

Change in the above lines the gateway address 192.168.1.1 and the netmask 255.255.255.0 to yours corresponding gw and netmask.
Also in the above example you see the half-duplex ifconfig option is set insetad of full-duplex in order to prevent some duplex mismatches. A full-duplex could be used instead, if you're completely sure on the other side of the host is configured to support full-duplex connections. Otherwise if you try to set full-duplex with other side set to half-duplex or auto-duplex a duplex mismatch will occur. If this happens insetad of taking the advantage of the Increase Jumbo Frames MTU the network connection could become slower than originally with standard ethernet MTU of 1500. One other bad side if you end up with duplex-mismatch could be a high number of loss packets and degraded thoroughout …

7. Setting Jumbo Frames for interfaces assigning dynamic IP via DHCP

If you need to assign an MTU of 9000 for a gigabyt network interfaces, which are receiving its TCP/IP network configuration over DHCP server.
First, tell em0 and rl0 network interfaces to dynamically assign IP addresses via DHCP proto by adding in /etc/rc.conf:

ifconfig_em0="DHCP"
ifconfig_rl0="DHCP"

Secondly make two files /etc/start_if.em0 and /etc/start_if.rl0 and include in each file:

ifconfig em0 media 1000baseTX mediaopt full-duplex mtu 9000
ifconfig rl0 media 1000baseTX mediaopt full-duplex mtu 9000

Copy / paste in root console:

echo 'ifconfig em0 media 1000baseTX mediaopt full-duplex mtu 9000' >> /etc/start_if.em0
echo 'ifconfig rl0 media 1000baseTX mediaopt full-duplex mtu 9000' >> /etc/start_if.rl0

Finally, to load the new MTU for both interfaces, reload the IPs with the increased MTUs:

freebsd# /etc/rc.d/routing restart
default 192.168.1.1 done
add net default: gateway 192.168.1.1

8. Testing if Jumbo Frames is working correctly

To test if an MTU packs are transferred correctly through the network you can use ping or tcpdumpa.) Testing Jumbo Frames enabled packet transfers with tcpdump

freebsd# tcpdump -vvn | grep -i 'length 9000'

You should get output like:

16:40:07.432370 IP (tos 0x0, ttl 50, id 63903, offset 0, flags [DF], proto TCP (6), length 9000) 192.168.1.2.80 > 192.168.1.1.60213: . 85825:87285(1460) ack 668 win 14343
16:40:07.432588 IP (tos 0x0, ttl 50, id 63904, offset 0, flags [DF], proto TCP (6), length 9000) 192.168.1.2.80 > 192.168.1.1.60213: . 87285:88745(1460) ack 668 win 14343
16:40:07.433091 IP (tos 0x0, ttl 50, id 63905, offset 0, flags [DF], proto TCP (6), length 9000) 192.168.1.2.80 > 192.168.1.1.60213: . 23153:24613(1460) ack 668 win 14343
16:40:07.568388 IP (tos 0x0, ttl 50, id 63907, offset 0, flags [DF], proto TCP (6), length 9000) 192.168.1.2.80 > 192.168.1.1.60213: . 88745:90205(1460) ack 668 win 14343
16:40:07.568636 IP (tos 0x0, ttl 50, id 63908, offset 0, flags [DF], proto TCP (6), length 9000) 192.168.1.2.80 > 192.168.1.1.60213: . 90205:91665(1460) ack 668 win 14343
16:40:07.569012 IP (tos 0x0, ttl 50, id 63909, offset 0, flags [DF], proto TCP (6), length 9000) 192.168.1.2.80 > 192.168.1.1.60213: . 91665:93125(1460) ack 668 win 14343
16:40:07.569888 IP (tos 0x0, ttl 50, id 63910, offset 0, flags [DF], proto TCP (6), length 9000) 192.168.1.2.80 > 192.168.1.1.60213: . 93125:94585(1460) ack 668 win 14343

b.) Testing if Jumbo Frames are enabled with ping

Testing Jumbo Frames with ping command on Linux

linux:~# ping 192.168.1.1 -M do -s 8972
PING 192.168.1.1 (192.168.1.1) 8972(9000) bytes of data.
9000 bytes from 192.168.1.1: icmp_req=1 ttl=52 time=43.7 ms
9000 bytes from 192.168.1.1: icmp_req=2 ttl=52 time=43.3 ms
9000 bytes from 192.168.1.1: icmp_req=3 ttl=52 time=43.5 ms
9000 bytes from 192.168.1.1: icmp_req=4 ttl=52 time=44.6 ms
--- 192.168.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 2.397/2.841/4.066/0.708 ms

If you get insetad an an output like:

From 192.168.1.2 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.1.2 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.1.2 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.1.2 icmp_seq=1 Frag needed and DF set (mtu = 1500)

--- 192.168.1.1 ping statistics ---
0 packets transmitted, 0 received, +4 errors

This means a packets with maximum MTU of 1500 could be transmitted and hence something is not okay with the Jumbo Frames config.
Another helpful command in debugging MTU and showing which host in a hop queue support jumbo frames is Linux's traceroute

To debug a path between host and target, you can use:

linux:~# traceroute --mtu www.google.com
...

If you want to test the Jumbo Frames configuration from a Windows host use ms-windows ping command like so:

C:\>ping 192.168.1.2 -f -l 8972
Pinging 192.168.1.2 with 8972 bytes of data:
Reply from 192.168.1.2: bytes=8972 time=2ms TTL=255
Reply from 192.168.1.2: bytes=8972 time=2ms TTL=255
Reply from 192.168.1.2: bytes=8972 time=2ms TTL=255
Reply from 192.168.1.2: bytes=8972 time=2ms TTL=255
Ping statistics for 192.168.1.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 2ms, Average = 2ms

Here -l 8972 value is actually equal to 9000. 8972 = 9000 – 20 (20 byte IP header) – 8 (ICMP header)

Boost local network performance (Increase network thoroughput) by enabling Jumbo Frames on GNU / Linux

Saturday, March 10th, 2012

Jumbo Frames boost local network performance in GNU / Linux

So what is Jumbo Frames? and why, when and how it can increase the network thoroughput on Linux?

Jumbo Frames are Ethernet frames with more than 1500 bytes of payload. They can carry up to 9000 bytes of payload. Many Gigabit switches and network cards supports them.
Jumbo frames is a networking standard for many educational networks like AARNET. Unfortunately most commercial ISPs doesn't support them and therefore enabling Jumbo frames will rarely increase bandwidth thoroughput for information transfers over the internet.
Hopefully in the years to come with the constant increase of bandwidths and betterment of connectivity, jumbo frames package transfers will be supported by most ISPs as well.
Jumbo frames network support is just great for is small local – home networks and company / corporation office intranets.

Thus enabling Jumbo Frame is absolutely essential for "local" ethernet networks, where large file transfers occur frequently. Such networks are networks where, there is often a Video or Audio streaming with high quality like HD quality on servers running File Sharing services like Samba, local FTP sites,Webservers etc.

One other advantage of enabling jumbo frames is reduce of general server overhead and decrease in CPU load / (CPU usage), when transferring large or enormous sized files.Therefore having jumbo frames enabled on office network routers with GNU / Linux or any other *nix OS is vital.

Jumbo Frames traffic is supported in GNU / Linux kernel since version 2.6.17+ in earlier 2.4.x it was possible through external third party kernel patches.

1. Manually increase MTU to 9000 with ifconfig to enable Jumbo frames

debian:~# /sbin/ifconfig eth0 mtu 9000

The default MTU on most GNU / Linux (if not all) is 1500, to check the default set MTU with ifconfig:

linux:~# /sbin/ifconfig eth0|grep -i mtu
UP BROADCAST MULTICAST MTU:1500 Metric:1

To take advantage of Jumbo Frames, all that has to be done is increase the default Maximum Transmission Unit from 1500 to 9000

For those who don't know MTU is the largest physical packet size that can be transferred over the network. MTU is measured by default in bytes. If a information has to be transferred over the network which exceeds the lets say 1500 MTU (bytes), it will be chopped and transferred in few packs each of 1500 size.

MTUs differ on different netework topologies. Just for info here are the few main MTUs for main network types existing today:
 

  • 16 MBit/Sec Token Ring – default MTU (17914)
  • 4 Mbits/Sec Token Ring – default MTU (4464)
  • FDDI – default MTU (4352)
  • Ethernet – def MTU (1500)
  • IEEE 802.3/802.2 standard – def MTU (1492)
  • X.25 (dial up etc.) – def MTU (576)
  • Jumbo Frames – def max MTU (9000)

Setting the MTU packet frames to 9000 to enable Jumbo Frames is done with:

linux:~# /sbin/ifconfig eth0 mtu 9000

If the command returns nothing, this most likely means now the server can communicate on eth0 with MTUs of each 9000 and therefore the network thoroughput will be better. In other case, if the network card driver or card is not a gigabit one the cmd will return error:

SIOCSIFMTU: Invalid argument

2. Enabling Jumbo Frames on Debian / Ubuntu etc. "the Debian way"

a.) Jumbo Frames on ethernet interfaces with static IP address assigned Edit /etc/network/interfaces and you should have for each of the interfaces you would like to set the Jumbo Frames, records similar to:

Raising the MTU to 9000 if for one time can be done again manually with ifconfig

debian:~# /sbin/ifconfig eth0 mtu 9000

iface eth0 inet static
address 192.168.0.5
network 192.168.0.0
gateway 192.168.0.254
netmask 255.255.255.0
mtu 9000

For each of the interfaces (eth1, eth2 etc.), add a chunk similar to one above changing the changing the IPs, Gateway and Netmask.

If the server is with two gigabit cards (eth0, eth1) supporting Jumbo frames add to /etc/network/interfaces :

iface eth0 inet static
address 192.168.0.5
network 192.168.0.0
gateway 192.168.0.254
netmask 255.255.255.0
mtu 9000

iface eth1 inet static
address 192.168.0.6
network 192.168.0.0
gateway 192.168.0.254
netmask 255.255.255.0
mtu 9000

b.) Jumbo Frames on ethernet interfaces with dynamic IP obtained via DHCP

Again in /etc/network/interfaces put:

auto eth0
iface eth0 inet dhcp
post-up /sbin/ifconfig eth0 mtu 9000

3. Setting Jumbo Frames on Fedora / CentOS / RHEL "the Redhat way"

Enabling jumbo frames on all Gigabit lan interfaces (eth0, eth1, eth2 …) in Fedora / CentOS / RHEL is done through files:
 

  • /etc/sysconfig/network-script/ifcfg-eth0
  • /etc/sysconfig/network-script/ifcfg-eth1

etc. …
append in each one at the end of the respective config:

MTU=9000

[root@fedora ~]# echo 'MTU=9000' >> /etc/sysconfig/network-scripts/ifcfg-eth


a quick way to set Maximum Transmission Unit to 9000 for all network interfaces on on Redhat based distros is by executing the following loop:

[root@centos ~]# for i in $(echo /etc/sysconfig/network-scripts/ifcfg-eth*); do \echo 'MTU=9000' >> $i
done

P.S.: Be sure that all your interfaces are supporting MTU=9000, otherwise increase while the MTU setting is set will return SIOCSIFMTU: Invalid argument err.
The above loop is to be used only, in case you have a group of identical machines with Lan Cards supporting Gigabit networks and loaded kernel drivers supporting MTU up to 9000.

Some Intel and Realtek Gigabit cards supports only a maximum MTU of 7000, 7500 etc., so if you own a card like this check what is the max MTU the card supports and set it in the lan device configuration.
If increasing the MTU is done on remote server through SSH connection, be extremely cautious as restarting the network might leave your server inaccessible.

To check if each of the server interfaces are "Gigabit ready":

[root@centos ~]# /sbin/ethtool eth0|grep -i 1000BaseT
1000baseT/Half 1000baseT/Full
1000baseT/Half 1000baseT/Full

If you're 100% sure there will be no troubles with enabling MTU > 1500, initiate a network reload:

[root@centos ~]# /etc/init.d/network restart
...

4. Enable Jumbo Frames on Slackware Linux

To list the ethernet devices and check they are Gigabit ones issue:

bash-4.1# lspci | grep [Ee]ther
0c:00.0 Ethernet controller: D-Link System Inc Gigabit Ethernet Adapter (rev 11)
0c:01.0 Ethernet controller: D-Link System Inc Gigabit Ethernet Adapter (rev 11)

Setting up jumbo frames on Slackware Linux has two ways; the slackware way and the "universal" Linux way:

a.) the Slackware way

On Slackware Linux, all kind of network configurations are done in /etc/rc.d/rc.inet1.conf

Usual config for eth0 and eth1 interfaces looks like so:

# Config information for eth0:
IPADDR[0]="10.10.0.1"
NETMASK[0]="255.255.255.0"
USE_DHCP[0]=""
DHCP_HOSTNAME[1]=""
# Config information for eth1:
IPADDR[1]="10.1.1.1"
NETMASK[1]="255.255.255.0"
USE_DHCP[1]=""
DHCP_HOSTNAME[1]=""

To raise the MTU to 9000, the variables MTU[0]="9000" and MTU[1]="9000" has to be included after each interface config block, e.g.:

# Config information for eth0:
IPADDR[0]="172.16.1.1"
NETMASK[0]="255.255.255.0"
USE_DHCP[0]=""
DHCP_HOSTNAME[1]=""
MTU[0]="9000"
# Config information for eth1:
IPADDR[1]="10.1.1.1"
NETMASK[1]="255.255.255.0"
USE_DHCP[1]=""
DHCP_HOSTNAME[1]=""
MTU[1]="9000"

bash-4.1# /etc/rc.d/rc.inet1 restart
...

b.) The "Universal" Linux way

This way is working on most if not all Linux distributions.
Insert in /etc/rc.local:

/sbin/ifconfig eth0 mtu 9000 up
/sbin/ifconfig eth1 mtu 9000 up

5. Check if Jumbo Frames are properly enabled

There are at least two ways to display the MTU settings for eths.

a.) Using grepping the MTU from ifconfig

linux:~# /sbin/ifconfig eth0|grep -i mtu
UP BROADCAST MULTICAST MTU:9000 Metric:1
linux:~# /sbin/ifconfig eth1|grep -i mtu
UP BROADCAST MULTICAST MTU:9000 Metric:1

b.) Using ip command from iproute2 package to get MTU

linux:~# ip route get 192.168.2.134
local 192.168.2.134 dev lo src 192.168.2.134
cache mtu 9000 advmss 1460 hoplimit 64

linux:~# ip route show dev wlan0
192.168.2.0/24 proto kernel scope link src 192.168.2.134
default via 192.168.2.1

You see MTU is now set to 9000, so the two server lans, are now able to communicate with increased network thoroughput.
Enjoy the accelerated network transfers 😉

 

How to increase brightness on Fujitsu Siemens Amilo PI22515 notebook with Slackware Linux

Friday, March 9th, 2012

Increase LCD screen brightness on Fujitsu Siemens Amilo laptop with Linux Slackware

A friend of mine has Fujitsu Siemens Amilo laptop and is full time using his computer with Slackware Linux.

He is quite happy with Slackware Linux 13.37 on the laptop, but unfortunately sometimes his screen brightness lowers. One example when the screen gets darkened is when he switch the computer on without being plugged in the electricity grid. This lowered brightness makes the screen un-user friendly and is quite tiring for the eye …

By default the laptop has the usual function keys and in theory pressing Function (fn) + F8 / F7 – should increase / decrease the brightness with no problems, however on Slackware Linux (and probably on other Linuxes too?), the function keys are not properly recognized and not responding whilst pressed.
I used to have brigtness issues on my Lenovo notebook too and remember how irritating this was.
After a bit of recalling memories on how I solved this brightness issues I remembered the screen brigthness on Linux is tunable through /proc virtual (memory) filesystem.

The laptop (Amilo) Fujitsu Siemens video card is:

lspci |grep -i vga
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 03)

I took a quick look in /proc and found few files called brightness:
 

  • /proc/acpi/video/GFX0/DD01/brightness
  • /proc/acpi/video/GFX0/DD02/brightness
  • /proc/acpi/video/GFX0/DD03/brightness
  • /proc/acpi/video/GFX0/DD04/brightness
  • /proc/acpi/video/GFX0/DD05/brightness

cat-ting /proc/acpi/video/GFX0/DD01/brightness, /proc/acpi/video/GFX0/DD03/brightness, /proc/acpi/video/GFX0/DD04/brightness all shows not supported and therefore, they cannot be used to modify brightness:

bash-4.1# for i in $(/proc/acpi/video/GFX0/DD0{1,3,4,5}/brightness); do \
cat $i;
done
<not supported>
<not supported>
<not supported>
<not supported>

After a bit of testing I finally succeeded in increasing the brightness.
Increasing the brightness on the notebook Intel GM965 video card model is done, through file:

/proc/acpi/video/GFX0/DD02/brightness

To see all the brightness levels the Fujitsu LCD display supports:

bash-4.1# cat /proc/acpi/video/GFX0/DD02/brightness
levels: 13 25 38 50 63 75 88 100
current: 25

As you can see the dark screen was caused cause the current: brightness is set to a low value of 25.
To light up the LCD screen and make the screen display fine again, I increased the brightness to the maximum level 100, e.g.:

bash-4.1# echo '100' > /proc/acpi/video/GFX0/DD02/brigthness

Just for the fun, I've written also a two lines script which gradually increases LCDs brightness 🙂

bash-4.1# echo '13' > /proc/acpi/video/GFX0/DD02/brightness;
bash-4.1# for i in \
$(cat /proc/acpi/video/GFX0/DD02/brightness|grep 'levels'|sed -e 's#levels:##g'); do \
echo $i > /proc/acpi/video/GFX0/DD02/brightness; sleep 1; \done

fujitsu_siemens_brightness_fun.sh script is fun to observe in changing the LCD screen gradually in one second intervals 🙂

Here is also a tiny program that reduces and increases the notebook laptop brightness written in C. My friend Dido, coded it in just few minutes just for the fun 🙂
To permanently solve the issues with darkened screen on boot time it is a good idea to include echo '100' > /proc/acpi/video/GFX0/DD02/brigthness in /etc/rc.local:

bash-4.1# echo '100' > /proc/acpi/video/GFX0/DD02/brigthness

I've also written another Universal Linux Increase laptop screen brightness Shell script which should be presumable also working for all Laptop models running Linux 🙂

My maximize_all_linux_laptops_brightness.sh "universal increase Linux brightness" script is here
I'll be glad to hear from people who had tested the script on other laptops and can confirm it works fine for them.
 

How to fix “Out of Range” resolution problems with NVIDIA Riva TNT2 Model 64/Model 64Pro with BENQ FP61E

Friday, January 20th, 2012

Today I had a task to change an old CRT Monitor to LCD BENQ Model FP61E on a computer running Microsoft Windows XP SP3.

Changing phyiscally the monitors and restarting the computer to load with the new BENQ monitor ended up with the LCD Monitor showing a blank screen with error:

Out of Range

making the computer completely unusable.

Thanksfully in Windows Safe Mode the monitor was able to display the screen properly, so I had an option to operate somehow on the pc

My guess was that the Out of Range monitor problems were caused by an incorrect (monitor unsupported resolution).

Therefore what I tried as a fix to make it work was:

1. Enter Windows Safe Mode and change (lower the resolution) to 640×480, and restart the PC.
Unfortunately using this classical way to fix such issues failed… so I thought of some options.
2. Disable the video card NVIDIA Riva TNT2 Model 64 driver and check if this will make any difference.

I come up with the idea the Out of Range LCD issues might be caused by the Video card driver cause I've noticed in safe mode a standard VESA like VGA Driver shipped with Windows worked just fine.
To Disable the currently loaded NVIDIA Riva TNT2 Model 64/ Model 64Pro I used:

System -> Device Manager -> Hardware (Tab) -> Display Adapters

Clicking on Display Adapters the NVIDIA Riva TNT2 Model 64 appears using the option menu on it one can choose to disable the driver.

Further on restart Windows, to test if the XP will load properly with disabled NVidia video drivers.
Onwards it was clear the whole Out of Range issues were caused by some kind of conflict between the LCD BENQ FP61E Monitor and the NVIDIA Riva TNT2 Model 64

Often latest video drivers solves hardware incompitability issues and fix many bugs, upgrading the driver to latest is always a good idea.

3. Therefore I Upgraded the NVIDIA Riva TNT2 64 driver (using Safe Mode) to the latest available from Nvidia's official site.

Weirdly Upgrading NVidia Riva TNT2 drivers to the latest did not fix the Out of Range blank screen error.
After a bit of thinking on what to do to make the Monitor work fine with the Nvidia driver, I thought of completely uninstalling the Nvidia drivers and installing them again might be a fix.
In my previous experience with Windows at many occasions, uninstalling a driver failing to properly work and installing it again with a working version was a good fix.

4. Uninstall the NVIDIA Riva TNT2 Model and Install the latest driver.

Uninstalling and Installing the Video driver had to be done in Windows Safe Mode again, in normal mode the windows was not displaying anything.

After The driver installation program completes the installation it requires a restart. After the restart the Video driver gets loaded fine and Windows loaded up in Normal mode as usual 😉

How to solve ALSA sound problems with old Linux programs and games depending on (OSS)’s /dev/dsp / fix wine games and pulseaudio problems – My few thoughts on OSS and ALSA

Wednesday, January 11th, 2012

 

ALSA OSS Pulseaudio ESD Some fixes workaround to gnu linux audio messI remember GNU / Linux, 11 years from now, times when ALSA was not standardly shipped with Linux.
Back then ALSA still lacked good support for many SoundCards and was still a "baby project".
In that time what we used to have sound on Linux was OSSOpen Sound System. OSS emerged right after the first ever Linux sound system VoxWare (formerly known as the Linux Sound Driver).

Back in those days OSS was used for multimedia support on both GNU / Linux and BSD based free OSes. It was few years later when I heard and used ALSA for a fist time and it wasn't really a love from first sigth.

One can easily find out by the name ALSA it is a system especially built for the Linux kernel and that's one of the reasosn why *BSD systems has their custom separate sound system.
There is plenty of reasons why OSS was substituted with ALSA. Main reason was its commercial like license, OSS wasn't completely "open source" GPLed (free software), there was resctions on use of OSS for commercial goals.

With its emerge ALSA started to push away OSS slowly. Somewhere in 2003, alsa has officially entered the Linux kernel source and until 2005 it was the default standard for all GNU / Linux operating systems.

As of time of writting ALSA has become the only sound system to have support for multiple sound card devices for Linux.
My experiences with ALSA, however ain't so nice if I take a look in my past experiences.
Since the very beginning of using ALSA, I had plenty of troubles with configuring properly my sound card not to mention, even after configuring it the MIDI support was not there.
Besides all the troubles main problems were stemming from the many applications still written to use OSS as sound system and hence with those sound was impossible with ALSA.The most problematic thing about apps written with OSS in mind was all of them tried to stream sound via /dev/dsp (OSS Digital Sound Processor), since alsa did not used /dev/dsp those programs was soundless.

On the other hand OSS was creating issues as well, one severe problem with OSS was the inability to stream multiple sounds simultaneously, because each sound stream required to pass voice through /dev/dsp and usually there was only one /dev/dsp.

The message;

/dev/dsp: Device or resource busy
and the proceeding irritation that used to annoy us in the early GNU / Linux days had of course some raw workarounds hacks but generally the workaround did not fix problems always.

Introduction of alsa free us from /dev/dsp issues but on the other handy has created a whole ocean of new BIG problems …
ALSA has modular structure and this imposes a great problem nowdays. The modular architecture is generally a good idea, however the way this was implemented within ALSA is far away from clear and easy to understand by the end user and therefore makes it very unintuitive and obscure.
Alsa misses simplicity which somehow was partially in the days of OSS. Thinking over the general situation with Linux multimedia nowdays, I believe it was exactly ALSA Project responsible for the so delayed mass Desktop Linux adoption.

Many long year standing Linux users had certainly had the alsa troubles during new system installs (correct me if I'm wrong).
The only fix to multiple soundcard initialization problems was to download alsa source and compile from source and hence made it hard and discouraging for people giving Linux a try.
This kind of ALSA "brokenness" pattern continues even to this very day (in Debian) Linux and probably building the alsa system from source is among the good practices to have a functional Linux sound system…

With all said the historic reason why ALSA was not quickly adopted and still is not a preferred default system for many applications ported to Free Software OSes by commercial company vendors is clear. Its simply not working out of the box …

Hope some ALSA developers will read this post work on changing the crazy structure of ALSA over complexity. ALSA needs automate way to solve issues with itself, the configuration should be more trivial and unified if Linux has to become more attractive for Desktop adoption.

Anyways, after the few words of history and indicating my pesonal observations on ALSA. I will proceed and explain few things on how ALSA can be configured to support and play nice with OSS dependant programs as well some basic explanations on common incompatibility between esd and pulseaudio and how this can be fixed;.

To assure nowdays OSS API built programs and games would work with Alsa its necessery to have installed;

ALSA wrapper for OSS applications

On Debian, Ubuntu, Fedora and most Linux distributions the Alsa OSS compatability layer comes under a (deb / rpm) package named alsa-oss

To install OSS compatability on Debian, Ubuntu and the like Debian based distributions issue:

debian:~# apt-get install alsa-oss alsaplayer-oss
...

On Fedora and other rpm based distributions install is with:

[root@fedora ~]# yum install alsa-oss alsaplayer-oss
...

alsa-oss provides with a command called aoss that should be used to work around some issues with old applications still depending on OSS:

hipo@debian:~$ aoss programName

Using aoss is helpful especially in situations if you have to run programs which deal with MIDI and others which somehow want to use /dev/dsp

There is also alternative way to enable alsa native support for MIDI and OSS by loading 3 kernel modules:

debian:~# modprobe snd-seq-oss
debian:~# modprobe snd-pcm-oss
debian:~# modprobe snd-mixer-oss

Note! The three modules has to be separately build using kernel source at most cases and does not come with most Linux distributions, so on many installations (including my current), they will be missing. If for you they load properly or you have customly build them add them also to load on system boot, like so:

echo 'snd-seq-oss' >> /etc/modules
echo 'snd-pcm-oss' >> /etc/modules
echo 'snd-mixer-oss' >> /etc/modules

The Linux sound situation becomes even more messy when ESD enters the scene. Many of the novice new Linux users certainly don't remember (Enlightened Sound Daemon) . ESD historically preceded PulseAudio . Hence it will be good to mention ESD was used for few years in GNOME and in around 2006-2007 it was substituted by PulseAudio.
Many applications, however who was ported or written for Linux especially (the proprietary ported ones) was already built to work with ESD and even though newer GNOME releases was fully using pulseaudio, this (non free software apps and games) were still depending on ESD.

The situation was partially fixed by creation of module for pulseaudio which added emulation support for esd . This was done by a module library for pulseaudio called libprotocol-esound.so
The package for almost all Linux distributions which does the esd emulation via pulse is pulseaudio-esound-compat . In latest Fedora Linux pulseaudio-esound-compat is installed by default.
In Debian and other Linux distributions it might need to be installed via apt with;

debian:~# apt-get install pulseaudio-esound-compat
...

pulseaudio-esound-compat solves some of the ESD app incompability but not always …
Handy tool also worthy to mention in solving PulseAudio, OSS incompatibility issues is padsp

padsp is helpful in solving obsolete issues with OSS applications (trying to access /dev/dsp) and therefore unable to communicate with Pulseaudio
padsp – is a PulseAudio OSS Wrapper.

An example where padsp is helpful is in case of /dev/dsp errors like:

/dev/dsp: Device or resource busy
Could not open /dev/dsp

Another common problem with sound on Linux is when running windows applications (running windows games with wine).
Quite often sound fails to work since wine tries to directly communicate with alsa and fails because alsa sound channel is taken by pulseaudio.

To workaround wine issues with pulseaudio, one of the solutions is to temporary stop pulseaudio, before running the wine emulated application:

hipo@debian:~$ pulseaudio --kill

Later on when the windows wine emulation is completed, pulseaudio has to be started once again in order to make Pulseaudio applications produce sound again, e.g. one has to issue:

hipo@debian:~$ pulseaudio --start
Alternative way to workaround wine sound issues is by using a script to kill pulseaudio every second. Here is fix_pulseaudio_wine_sound_probs.sh script

This script was reported by many people as fix to problems with wine games failing to play sounds and music, anyhow I personally prefer using the stop / start pulseaudio method.

The picture below is taken from Wikipedia and illustrates, clearly the intergalactical complexity of sound systems on Gnu / Linux and BSD

I just hope one day this (OSS, ALSA, esd, Pulseaudio) mess will be over! In the mean time I hope my suggested work arounds helps someone. If someone has a better more unified script or solution please share in comments

Solve ALSA audio and mic issues on Lenovo Thinkpads on Debian and Ubuntu Linux

Wednesday, January 11th, 2012

Since I've blogged about my recent skype issues. I've played a lot with pulseaudio, alsa, alsa-oss to experimented a lot until I figured out why Skype was failing to properly delivery sound and record via my embedded laptop mic.

Anyways, while researching on the cause of my Thinkpad r61 mic issues, I've red a bunch of blog posts by people experiencing microphone oddities with Lenovo Thinkpads

Throughout the search I come across one very good article, which explained that in many cases the Thinkpad sound problems are caused by the snd-hda-intel alsa kernel module. snd-hda-intel fails to automatically set proper sb model type argument during Linux install when the soundcard is initialized with some argument like options snd-hda-intel model=auto

Hence, the suggested fix which should resolve this on many Thinkpad notebooks is up to passing the right module argument:

To fix its neceessery to edit /etc/modprobe.d/alsa-base.conf .

debian:~# vim /etc/modprobe.d/alsa-base.conf

Find the line in the file starting with:
options snd-hda-intel model=

and substitute with:

options snd-hda-intel model=thinkpad

Finally a restart of Advaned Linux Sound Architecture (alsa) is required:

debian:~# /etc/init.d/alsa restart
...

At most cases just restarting the alsa via its init script is not enough, since the ssnd-hda-intel kernel module is already in use by some program or something, so its best to do a reboot to make sure the module is loaded with the new model=thinkpad argument.

My exact laptop sound card model is:

debian:~# lspci |grep -i audio
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)

After changing the module and using alsamixer and aumix to make sure mic is unmuted and its volume is high enough, mic sound rec works fine.

Upgrading Skype 2.0 to Skype 2.2 beta on Debian GNU / Linux – Skype Mic hell

Saturday, December 31st, 2011

Making Skype work with Alsa on Debian GNU / Linux

Though, I'm GNU / Linux user for many years now. I have to say, everything is not so perfect as many people present it.
Configuring even simple things related to multimedia on Linux is often a complete nightmare.
An example, today I've decided to upgrade my 32 bit Skype version 2.0 beta for Linux to 64 bit Skype 2.2 beta .
The reason I was motivated to upgrade skype was basicly 2.

a) My Skype run through 32 bit binary emulation with /usr/bin/linux32

b) I had issues with my skype if someone give me a Skype Call, while I have a flash video or some other stream in Browser (let's say Youtube).
Actually being unable to receive a skype call or initiate one while I have some kind of music running in the background or just some kind of Youtube video paused was really annoying. Hence until now, everytime I wanted to speak over skype I had to close all Browser windows or tabs that are using my sound card and then restart my Skype program ….

Just imagine how ridiculous is that especially for a modern Multimedia supporting OS as Linux is. Of course the problems, I've experienced wasn't directly a problem of Linux. The problems are caused by the fact I have to use the not well working proprietary software version of Skype on my Debian GNU / Linux.
I would love to actually boycott Skype as RMS recommends, but unfortunately until now I can't, since many of my friends as well as employers use Skype to connect with me on daily basis.
So in a way I had to migrate to newer version of skype in order to make my Linux experience a bit more desktop like …

Back to the my skype 2.0 to 2.2. beta upgrade story, the overall Skype upgrade procedure was easy and went smootlhy, setting correct capturing later on however was a crazy task ….
Here is the step by step to follow to make my upgraded skype and internal notebook mic play nice together:

1. Download 64 bit Skype for Debian from skype.com

For the sake of preservation in case it disappears in future, I've made a mirror of skype for debian you can download here
My upgrade example below uses directly the 64 bit Skype 2.2beta binary mirror:

Here are the cmds once can issue if he has to upgrade to 2.2beta straight using my mirrored skype:

debian:~# wget http://www.pc-freak.net/files/skype-debian_2.2.0.35-1_amd64.deb
...

2. Remove the old version of skype

In my case I have made my previous skype installation using .tar.bz2 archive and not a debian package, however for some testing I also had a version of skype 2.0beta installed as a deb so for the sake of clarity I removed the existing skype deb install:

debian:~# dpkg -r skype
...

3. Install skype-debian_2.2.0.35-1_amd64.deb downloaded deb

debian:~# dpkg -i skype-debian_2.2.0.35-1_amd64.deb
...

After installing skype, I installed pavucontrol A volume control for the PulseAudio sound server

4. Install pavucontrol

debian:~# apt-get install pavucontrol

PavUcontrol PulseAudio mixer screenshot

Pavucontrol has plenty of sound configurations and enables the user to change many additional settings which cannot be tuned in alsamixer

pavucontrol was necessery to play with until I managed to make my microphone able to record.

5. Build and install latest Debian (Testing) distribution alsa driver

debian:~# aptitude install module-assistant
debian:~# m-a prepare
debian:~# aptitude -t testing install alsa-source
debian:~# m-a build alsa
debian:~# m-a install alsa
debian:~# rmmod snd_hda_intel snd_pcm snd_timer snd soundcore snd_page_alloc
debian:~# modprobe snd_hda_intel
debian:~# echo 'options snd-hda-intel model=auto' >> /etc/modprobe.d/alsa-base.conf

In my case removing the sound drivers and loading them once again did not worked, so I had to reboot my system before the new compiled alsa sound modules gets loaded …
The last line echo 'options snd-hda-intel model=auto' … was necessery for my Thinkpard r61 Intel audio to work out. For some clarity my exact sb model is:

debian:~$ lspci |grep -i audio
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)

For other notebooks with different sound drivers echo 'options snd-hda-intel model=auto' … should be omitted.

6. Tune microphone and sound settings in alsamixer

debian:~$ alsamixer

Alsamixer Select Soundcard Debian Linux Screenshot
Right after launching alsamixer I had to press F6: Select Sound Card and choose my sound card (0 HDA Intel).

Following my choice I unmuted all the microphones and enabled Microphone Boost as well as did some adjustments to the MIC volume level.

Alsamixer My Intel SoundCard Debian Linux

Setting proper MIC Volume levels is absolutely necessery, otherwise there is a constant noise getting out of the speakers …

7. Use aumix to set some other sound settings

For some unclear reasons, besides alsamixer , I often had to fix stuff in aumix . Honestly I don't understand where exactly aumix fits in the picture with Alsa and my loaded alsa sound blaster module?? If someone can explain I'll be thankful.

Launch aumix to further adjust some sound settings …

debian:~$ aumix

Aumix Debian GNU Linux Squeeze Screenshot

In above screenshot you see, my current aumix settings which works okay with mic and audio output.

9. Test Microphone the mic is capturing sounds correctly

Set ~/.asoundrc configuration for Skype

Edit ~/.asoundrc and put in:

pcm.pulse {
type pulse
}
ctl.pulse {
type pulse
}
pcm.!default {
type pulse
}
ctl.!default {
type pulse
}
pcm.card0 {
type hw
card 0
}
ctl.card0 {
type hw
card 0
}
pcm.dsp0 { type plug slave.pcm "hw:0,0" }
pcm.dmixout {
# Just pass this on to the system dmix
type plug
slave {
pcm "dmix"
}
}
pcm.skype {
type asym
playback.pcm "skypeout"
capture.pcm "skypein"
}
pcm.skypein {
# Convert from 8-bit unsigned mono (default format set by aoss when
# /dev/dsp is opened) to 16-bit signed stereo (expected by dsnoop)
#
# We cannot just use a "plug" plugin because although the open will
# succeed, the buffer sizes will be wrong and we will hear no sound at
# all.
type route
slave {
pcm "skypedsnoop"
format S16_LE
}
ttable {
0 {0 0.5}
1 {0 0.5}
}
}
pcm.skypeout {
# Just pass this on to the system dmix
type plug
slave {
pcm "dmix"
}
}
pcm.skypedsnoop {
type dsnoop
ipc_key 1133
slave {
# "Magic" buffer values to get skype audio to work
# If these are not set, opening /dev/dsp succeeds but no sound
# will be heard. According to the ALSA developers this is due
# to skype abusing the OSS API.
pcm "hw:0,0"
period_size 256
periods 16
buffer_size 16384
}
bindings {
0 0
}
}
I'm not 100% percent if putting those .asoundrc configurations are necessery. I've seen them on archlinux's wiki as a perscribed fix to multiple issues with Skype sound in / out.

Onwardds, for the sake of test if my sound settings set in pavucontrol enables the internal mic to capture sound I used two programs:

1. gnome-sound-recorder
2. arecord

gnome-sound-recorder GNU / Linux Screenshot
gnome-sound-recorder

gnome-sound-recorder is probably used by most GNOME users, though I'm sure Linux noviced did not play with it yet.

arecord is just a simple console based app to capture sound from the microphone. To test if the microphone works I captured a chunk of sounds with cmd:

debian:~$ arecord cow.wav
Recording WAVE 'cow.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono

Later on I played the file with aplay (part of alsa-utils package in Debian), to check if I'll hear if mic succesfully captured my voice, e.g.:

debian:~$ play cow.wav
cow.wav:
File Size: 22.0k Bit Rate: 64.1k
Encoding: Unsigned PCM
Channels: 1 @ 8-bit
Samplerate: 8000Hz
Replaygain: off
Duration: 00:00:02.75
In:100% 00:00:02.75 [00:00:00.00] Out:22.0k [-=====|=====-] Clip:0
Done.

By the way, the aplay ASCII text equailizer is really awesome 😉 aplay is also capable of playing (Ogg Vorbis .ogg) free sound format.

Further on, I launched the new installed version of skype and tested Skype Calls (Mic capturing), with Skype Echo / Sound Test Service
I'll be glad to hear if this small article, helped anybody to fix any skype Linux related issues ?. I would be happy to hear also from people who had similar issues with a different fixes for skype on Linux.
Its also interesting to hear from Ubuntu and other distributions users if following this tutorial had somehow helped in resolving issues with Skype mic.

How to renew IP address, Add Routing and flush DNS cache on Windows XP / Vista / 7

Friday, November 25th, 2011

There are two handy Windows commands which can be used to renew IP address or flush prior cached DNS records which often create problems with resolving hosts.

1. To renew the IP address (fetch address from DHCP server)C:> ipconfig /release
C:> ipconfig /renew

In above cmd ipconfig /release will de-assign the IP address configured on all Windows LAN and Wireless interfaces, whether ipconfig /renew will send request for IP address to the DNS server.

To unassign and assign again IP address from DHCP server only for a particular LAN or WLAN card:

C:> ipconfig /release LAN
C:> ipconfig /renew LAN
C:> ipconfig /release WLAN
C:> ipconfig /renew WLAN

2. Adding specific routing to Windows

Windows has a Route command similar by syntax to Linux’s route command.
To add routing via a specific predefined IP addresses on Windows the commands should be something like:

C:> Route add 192.168.40.0 mask 255.255.255.0 192.168.41.253
C:> Route add 0.0.0.0 mask 0.0.0.0 192.168.41.254
The first command adds IP 192.168.40.0 in the network of 255 hosts to be routed via 192.168.41.253
The second one adds 192.168.41.254 as a default gateway for all outbound traffic from the Windows host.
To make permanent routing -p switch is used.
3. To clear Windows DNS cache (flush DNS cached records) C:> ipconfig /flushdns
This will clear all IP records corresponding to hostnames previously cached on the Windows host. Using ipconfig /flushdns is especially handy when IP address for a specific DNS host is changed. Flushing the Windows DNS cache can save us a lot of waiting before the domain example.com starts resolving to the new IP address let’s say 1.2.3.4 instead of the old one 2.2.2.2