Osprey 230 Linux Driver Sound Patch

четвъртък, септември 24th, 2009

Реших да драсна няколко реда относно този проблем, защото информацията в нета е доста оскъдна. Накратко, capture картите на Osprey от серия 230 (и не само те), но в моя случай ставаше дума за такава имат проблем със звука. Те варират от пълната му липса до едно дразнещо бучене, макар и да се чува някакво подобие на звук. По-често срещаният проблем е вторият и причината всъщност е във високият gain. Из мейлинг листите има доста въпроси относно този проблем, но малка част от тях водят до някакво решение.

До ядро 2.6.9 Viewcast са имали собствени драйвери за Linux за своите карти, но в последствие тяхната разработка е била прехвърлена на общността и в частност на хората зад v4l/dvb. Драйверите за v4l поначало са част от linux ядрото. В ядрото идващо с CentOS 5.2, а именно 2.6.18 нужните драйвери за разпознаване и работа на Osprey картите са налице. Това са bttv за video и snd_bt87x за звука. И докато видеото може да се каже че е с перфектно качество, то както вече стана дума не можем да кажем това и за звука. При малко по-усилено търсене могат да се намерят едни стари пачове от 2006-та година, които са решавали проблема посредством btaudio, но на мен те не ми свършиха работа. Patch-ът, който всъщност работи, може да бъде намерен ето тук . (Понеже той не може да бъде видян без регистрация за v4l mail листата, то ще направя и local mirror).

И така, ако в dmesg, или /var/log/messages виждаме нещо подобно:

bttv: driver version 0.9.18 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
bttv0: Bt878 (rev 17) at 0000:0b:04.0, irq: 19, latency: 132, mmio: 0xd8000000
bttv0: detected: Osprey-200 [card=88], PCI subsystem ID is 0070:ff01
bttv0: using: Osprey 200/250 [card=88,autodetected]
bttv0: gpio: en=00000000, out=00000000 in=00ffffff [init]
bttv0: osprey eeprom: card=89 'Osprey 210/220/230' serial=5436547
bttv0: osprey eeprom: Changing card type from 88 to 89
bttv0: tuner absent
bttv0: registered device video0
bttv0: registered device vbi0

то картата ни е разпозната, модулът е зареден и можем да я ползваме по предназначение (засега без звук).

Ето и основните стъпки, по които да се ръководи човек сблъскал се с подобен род проблем, като те като цяло са малко redhat specific, но не би трябвало да бъде проблем да се ползват и за други дистрибуции.

  • Сваляваме osprey-snd-patch.
cd /usr/src/
wget http://just4nick.net/blog/wp-content/uploads/2009/09/osprey-snd.patch
  • Сваляме сорс кода на v4l-dvb и го разархивираме.
wget http://linuxtv.org/hg/~tap/bttv/archive/tip.tar.gz
tar -zxvf bttv-35ddb77b68f8.tar.gz
mv bttv-35ddb77b68f8 v4l-dvb
  • Прилагаме patch-a.
patch --dry-run -p1 -d v4l-dvb < osprey-snd.patch

Както се вижда и от самия код ползваме опцията на patch за суха тренировка –dry-run. Така се предпазваме от грешки. Ако всичко е наред, би трябвало да видим нещо от този род:

patching file linux/drivers/media/video/bt8xx/bttv-if.c
patching file linux/drivers/media/video/bt8xx/bttv.h
Hunk #1 succeeded at 302 (offset 1 line).
patching file linux/sound/pci/bt87x.c
Hunk #7 succeeded at 437 (offset 2 lines).
Hunk #9 succeeded at 778 (offset 2 lines).
Hunk #11 succeeded at 984 (offset 2 lines).
Hunk #12 succeeded at 1084 (offset 2 lines).
Hunk #13 succeeded at 1109 (offset 2 lines).

След което можем да пристъпим към същинското прилагане на patch-а с командата:

patch -p1 -d v4l-dvb < osprey-snd.patch
  • Инсталираме kernel-devel, kernel-headers, redhat-rpm-config, rpm-build.
yum -y install kernel-devel kernel-headers redhat-rpm-config rpm-build
  • Сваляме и инсталираме src rpm-a на ядрото.
cd /usr/local/src/
wget ftp://mirror.switch.ch/pool/3/mirror/centos/5.3/updates/SRPMS/kernel-2.6.18-128.4.1.el5.src.rpm
rpm -ivh kernel-2.6.18-128.4.1.el5.src.rpm
  • Билдваме модифицирания код на ядрото.
cd /usr/src/redhat/SPECS
rpmbuild -bp --target=$(arch) kernel-2.6.spec
  • Коригираме Makefile.
cd /usr/src/redhat/BUILD/kernel-2.6.18/linux-2.6.18.x86_64/
vim Makefile

където променяме

EXTRAVERSION = -prep

EXTRAVERSION = -128.4.1.el5
  • Компилираме и инсталираме driver-ите.
cp configs/kernel-2.6.18-x86_64.config .config
make modules_prepare
cd /usr/src/v4l-dvb
make all
make install
make sound-install

Ако всичко мине успешно, то при изпълняването на

ls -la /lib/modules/2.6.18-128.4.1.el5/kernel/sound/pci/snd-bt87x.ko

би трябвало да видим, че модула е налице и е с текуща дата и час.

  • Зареждаме модула.
rmmod snd_bt87x
modprobe snd_bt87x

След което би трябвало да е възможно да коригираме sound capture посресдством alsamixer и да имаме нормално работещ звук.

Допълнителна информация:

http://linux.lcpe.uni-sofia.bg/manuals/openintegra/xfs/RHEL_xfs_RPM.html
http://wiki.centos.org/HowTos/BuildingKernelModules
http://www.google.bg/#hl=bg&q=linux+audio+problem+Osprey+230&meta=&fp=e366587b524c8386
del.icio.us Digg Google Technorati Svejo.net

that was yesterday…

сряда, юни 24th, 2009

10.00 a.m. – няма ток в collocation центъра

16.00 p.m. – dmesg | grep sda:

ReiserFS: sda1: warning: vs-13060: reiserfs_update_sd: stat data of object [91527 91528 0x0 SD] (nlink == 1) not found (pos 1) – (очертава се денят да е дълъг)

17.00 p.m.:

umount /dev/sda1
reiserfsck –check /dev/sda1

Checking internal tree..finished
Comparing bitmaps..finished
Fatal corruptions were found, Semantic pass skipped
1 found corruptions
###########

17.30 p.m.:

reiserfsck –scan-whole-partition –rebuild-tree /dev/sda1 – и стискам палци

17.30 – 23:00 p.m.

три бири в приятна компания :)

едно уиски докато чакам да минем от 80% на 100%

23;10 p.m.

###########
reiserfsck finished at Tue Jun 23 23:09:32 2009
###########

23:15 p.m.:

yum upgrade

00:30 p.m. – welcome to the machine :)


del.icio.us Digg Google Technorati Svejo.net

linux convert jpg to pdf

понеделник, юни 15th, 2009

Преди няколко дни ми се наложи да редактирам pdf файл направен от някаква скенер програмка на Xerox, която обединява всички сканирани страници в един общ файл. Проблемът е, че както и да му подадеш листа, във файла в последствие някои от страниците са обърнати на 180°. Rotate от самия pdf reader не върши работа, защото завърта всичко глобално. Така че се налага да разбием файла така да се каже на съставните му части и да обърнем страниците, които имат нужда от това. Варианти да се направи това има няколко. Може да стане и графично с The GIMP,  и в command line с convert, който е част от ImageMagick.

Графично това става по следния начин:

  • отваряме желания pdf файл с GIMP
  • в менюто import from pdf избираме Select All (или Select Range ако искаме да обърнем само първите три страници да речем)
  • Open Pages As Images

и на края естествено Import така GIMP отваря всяка (или всяка посочена) страница като отделна картинка, която можем да редактираме и запишем в желания формат.

gimp-pdf-import

Втория и според мен много по-лесен начин е този с convert, като просто трябва да изпълним следното:

convert input.pdf image_%03d.tiff

или

convert input.pdf image_%03d.jpg

ако предпочитаме jpg изходни файлове, като „%03d“ означава, че в името ще имаме image_ последвано от 3 цифри, предхождани от нули от рода 001, 002 или в крайна сметка image_00x.jpg. И ако картинката, която има нужда от завъртане е 003, то стигаме до:

convert -rotate 180 image_003.jpg output.jpg

На края остава да съединим картинките и да получим първоначалния файл, но вече без страници, които са с с главата надолу :), като това става по следния начин:

convert *jpg modified.pdf

като така получаваме pdf файл, в който всяка входяща картинка е на отделна страница.

Това естествено съвсем не е всичко, което можем да направим с convert. Повече може да се види тук или в man-а.

Забележка:
Последната стъпка поне на този етап не работи и няма да работи във Fedora 11. Повече тук.

del.icio.us Digg Google Technorati Svejo.net

Tool of the Day – dmidecode

вторник, февруари 17th, 2009

Понякога се налага да добием информация за хардуера на дадена машина. Причини много.  Ако машината е наоколо винаги може да се отвори и да се провери. Но ако е през два-три етажа, или в офиса във Варна, или пък колокирана в нечие сървърно това не е опция. Още повече, че за да се отвори дадена машина, първо трябва да се спре. Когато става дума за десктоп станция, това не е проблем, но ако става дума за сървър нещата стоят по друг начин. Dmidecode върши работа и в двата случая. Цитат от страницата на проекта:

Dmidecode reports information about your system’s hardware as described in your system BIOS according to the SMBIOS/DMI standard . This information typically includes system manufacturer, model name, serial number, BIOS version, asset tag as well as a lot of other details of varying level of interest and reliability depending on the manufacturer. This will often include usage status for the CPU sockets, expansion slots (e.g. AGP, PCI, ISA) and memory module slots, and the list of I/O ports (e.g. serial, parallel, USB).

С други думи програмата чете това, което й казва BIOS-a. Ако той лъже, и тя ще излъже. Така че за съжаление не може да се вярва на изхода на 100%. Тествах я на близо 10-на машини, на повечето, от които знам с точност хардуерните характеристики и не сгреши никъде, така че лично аз й имам достатъчно доверие.

За мен най-полезната опция е -t, –type TYPE. Като съответните възможности са:

DMI TYPES
The SMBIOS specification defines the following DMI types:

Type   Information
—————————————-
0   BIOS
1   System
2   Base Board
3   Chassis
4   Processor
5   Memory Controller
6   Memory Module
7   Cache
8   Port Connector
9   System Slots
10   On Board Devices
11   OEM Strings
12   System Configuration Options
13   BIOS Language
14   Group Associations
15   System Event Log
16   Physical Memory Array
17   Memory Device
18   32-bit Memory Error
19   Memory Array Mapped Address
20   Memory Device Mapped Address
21   Built-in Pointing Device
22   Portable Battery
23   System Reset
24   Hardware Security
25   System Power Controls
26   Voltage Probe
27   Cooling Device
28   Temperature Probe
29   Electrical Current Probe
30   Out-of-band Remote Access
31   Boot Integrity Services
32   System Boot
33   64-bit Memory Error
34   Management Device
35   Management Device Component
36   Management Device Threshold Data
37   Memory Channel
38   IPMI Device
39   Power Supply

Съответно, ако ни интересува какво е дъното:

[root@Galactica ~]# dmidecode -t 2
# dmidecode 2.9
SMBIOS 2.3 present.

Handle 0×0002, DMI type 2, 8 bytes
Base Board Information
Manufacturer: ASUSTeK Computer INC.
Product Name: P5L-MX
Version: Rev x.xx
Serial Number: MB-1234567890

Aко искаме да добавим RAM памет на дадена машина dmidecode отново е наш пръв приятел:

[root@Pegasus ~]# dmidecode -t 16
# dmidecode 2.7
SMBIOS 2.33 present.

Handle 0×0016, DMI type 16, 15 bytes.
Physical Memory Array
Location: System Board Or Motherboard
Use: System Memory
Error Correction Type: Single-bit ECC
Maximum Capacity: 16 GB
Error Information Handle: Not Provided
Number Of Devices: 4

т.е. системата поддържа до 16 GB памет.
В момента имаме:

[root@Pegasus ~]# cat /proc/meminfo | grep MemTotal
MemTotal: 2059224 kB

като те са разпределени по следния начин:

[root@Pegasus ~]# dmidecode -t 17
# dmidecode 2.7
SMBIOS 2.33 present.

Handle 0×0017, DMI type 17, 27 bytes.
Memory Device
Array Handle: 0×0016
Error Information Handle: No Error
Total Width: 72 bits
Data Width: 64 bits
Size: 1024 MB
Form Factor: DIMM
Set: 1
Locator: DIMM#1A
Bank Locator: Bank 1

Type: DDR
Type Detail: Synchronous
Speed: 400 MHz (2.5 ns)
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified

Handle 0×0018, DMI type 17, 27 bytes.
Memory Device
Array Handle: 0×0016
Error Information Handle: No Error
Total Width: Unknown
Data Width: Unknown
Size: No Module Installed
Form Factor: DIMM
Set: 1
Locator: DIMM#2A
Bank Locator: Bank 2
Type: DDR
Type Detail: Synchronous
Speed: 400 MHz (2.5 ns)
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified

Handle 0x001B, DMI type 17, 27 bytes.
Memory Device
Array Handle: 0×0016
Error Information Handle: No Error
Total Width: 72 bits
Data Width: 64 bits
Size: 1024 MB
Form Factor: DIMM
Set: 1
Locator: DIMM#1B
Bank Locator: Bank 1

Type: DDR
Type Detail: Synchronous
Speed: 400 MHz (2.5 ns)
Manufacturer: Not Specified
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified

т.е. знаем точно какво и на кой слот има, което е предостатъчна информация да си направим сметката за upgrade.

dmidecode е част от RedHat базираните дистрибуции CentOS и Fedora по подразбиране.

Допълнителна информация:
man dmidecode

del.icio.us Digg Google Technorati Svejo.net

Fedora 10 / KDE 4.2

понеделник, февруари 9th, 2009

KDE 4.2 излезе на 27-ми януари, но все още го няма като официален stable update за Fedora. Пакетите са минали през koji и вече са в updates-testing. Аз понеже нямах търпение да чакам update-нах когато ги нямаше и там, като ползвах ето това хранилище, което се поддържа от Rex Dieter, който се грижи основно за поддръжката и създаването на KDE пакетите за Fedora и RHEL. Там има инструкции, но ето ги все пак и тук.

Създаваме файл /etc/yum.repos.d/kde.repo със следното съдържание:

# kde.repo, v2.1

[kde]
name=kde
mirrorlist=http://apt.kde-redhat.org/apt/kde-redhat/fedora/mirrors-stable
gpgkey=http://apt.kde-redhat.org/apt/kde-redhat/kde-redhat.RPM-GPG-KEY
#gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-kde-redhat
enabled=1

[kde-testing]
name=kde-testing
mirrorlist=http://apt.kde-redhat.org/apt/kde-redhat/fedora/mirrors-testing
gpgkey=http://apt.kde-redhat.org/apt/kde-redhat/kde-redhat.RPM-GPG-KEY
#gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-kde-redhat
enabled=0

[kde-unstable]
name=kde-unstable
mirrorlist=http://apt.kde-redhat.org/apt/kde-redhat/fedora/mirrors-unstable
gpgkey=http://apt.kde-redhat.org/apt/kde-redhat/kde-redhat.RPM-GPG-KEY
#gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-kde-redhat
enabled=0

след което изпълняваме:

yum --enablerepo=kde-testing groupupdate "KDE (K Desktop Environment)"

След като пакетите вече ги има в updates-testing, същия ефект може да се постигне и по следния начин:

yum --enablerepo=updates-testing groupupdate "KDE (K Desktop Environment)"

По принцип проблеми с failed dependencies при мен нямаше, но това не е гаранция, че ще бъде така при всеки. Така че, който реши да не чака и действа по горния начин, трябва да си има едно на ум за възможни проблеми.
Като цяло KDE 4.2 се държи много по-стабилно от 4.1 и е несравнимо по-добре от 4.0. Засега всичко при мен работи според очакванията.

del.icio.us Digg Google Technorati Svejo.net