[sisyphus] Видеоконференции на ноутбуках ( лаптопах )

[sisyphus] Видеоконференции на ноутбуках ( лаптопах )

[info]

Имел я тут веселую работку - ставить Linux на 6 ноутбуков в 
локальной сети одной фирмы, да так, чтобы с видеоконференцией.

Впечатлениями и хочу поделиться. Может, кому-то окажется 
полезным.

1.

Прежде всего, в ALTLinux только одна видеоконференция, и та под 
Gnome. Под KDE gnomemeeting ставится кривовато, посему поискал 
в инете - и нашел видеоконференцию под KDE в составе одного 
малоизвестного дистрибутива (ARK Linux). Продукт так и 
называется - videoconference. Правда, собрать его 
самостоятельно из сырцов не сумел (.configure проходило 
нормально, а дальше почему-то компилер не мог найти ptlib.h), а 
готовые rpm-ы поставить нельзя: в Сизифусе glibc 2.2.6, а эти 
rpm-ы собраны уже под следующую версию glibc.

Cсылка, откуда я взял srpm этого пакета (а потом вытащил из него 
tar.gz) - http://darkstar.ist.utl.pt/arklinux.  

Может, кто попробует, что это за зверь?

2. 

Далее. На ноутбуках обнаружен следующий эффект: вебкамера, после 
некоторого весьма непродолжительного времени нормальной работы, 
вдруг останавливает видеограббинг. Долгие поиски позволини 
найти причину: ACPI. Любое обращение к 
/proc/acpi/battery/BAT0/state (это проверка 
заряда батарей) приводит к срыву видеограббинга на любом 
приложении v4l - даже xawtv, который, если его запустить из 
консоли в режиме debug, выдает вот такое сообщение:

v4l: timeout (got SIGALRM), hardware/driver problems?
ioctl: VIDIOCSYNC(int=0): Interrupted system call
v4l: timeout (got SIGALRM), hardware/driver problems?
ioctl: VIDIOCSYNC(int=1): Interrupted system call 

Остальные не выдают ничего, просто картинка останавливается.

Имейте это в виду все, кто захочет запускать видеокамеру на 
ноутбуках.

Workаround-решение - перед запуском видеоприложения на лаптопе 
убивать нах всё то, что проверяет заряд батарей (klaptopdaemon, 
например). Так, я вынужден запускать gnomemeeting не напрямую, 
а из shell-скрипта:

#! /bin/bash
kill `ps -C "kdeinit" x | grep -v "grep" | grep "kdeinit: 
klaptopdaemon" | cut -d " " -f2`
kill `ps x | grep -v "grep" | grep "artsd" | cut -d " "  -f2`
exec /usr/bin/gnomemeeting&

3.
Этот же скрипт, как видно, убивает artsd, без чего gnomemeeting 
под KDE не запустится. Пытаться делать что-нибудь вроде artsdsp 
gnomemeeting бесполезно: gnomemeeting - не единый процесс, у 
него штук пять подпроцессов, и до них artsdsp не доходит. 

Как workaround-решение сие вполне проходит, но сидеть с 
gnomemeeting в трее в ожидании возможного вызова, и попутно 
слушать mp3 - не получится. 

4.
Далее, Gnomemeeting использует gnome events для звукового 
сигнала при поступлении вызова, а под KDE гномовские события, 
естественно, не обрабатываются. Посему - звонок при вызове не 
работает. Как заставить его заработать - не разобрался. Если 
кто знает - посоветуйте.

5. И последнее. По крайней мере в той версии gnomemeeting, 
которая в Сизифусе, видеокамера на останавливается, когда 
gnomemeeting свернут в трей. Сие дает бесцельную загрузку 
процессора примерно в 10%. Также не ставится на mute и 
микрофон. 


Я уже написал все это в gnomemeeting-list@gnome.org; посмотрим, 
как среагируют.

Георгий

[sisyphus] Дополнение к " Видеоконференции на ноутбуках ( лаптопах )"

[info]

Довожу до сведени
 тех, кому это интересно, результаты обсуждени
 аналогичной темы на gnomemeeting-list@gnome.org.
1. Дл
 сведени
 всех использующих gnomemeeting: нажимать кнопку "Камера", так, чтобы в окне без соединени
 увидеть себ
 - не надо. Это просто preview. Передача видео при вызове осуществл
етс
, если вы указали соответствующую позицию в настройках. Если же вы включите превью, то при свертывании в трей видеокамера не отключитс
, и будет кушать без толку где-то около 10% процессорного времени.Я попыталс
 было убедить майнтейнера гномемиитинга Damien Sandras <damien.sandras@it-optics.com>, что и превью надо бы автоматически отключать при свертывании в трей, но - не сумел.Может, кто будет более удачливым?
2.Звонок вызова, не завис
ща
 от обработчика событий Гнома. Эта фича есть в последних CVS-верси
х.
3.По
вление проблемы с остановкой видеограббинга на лаптопах сильно зависит от конкретной моджели лаптопа и еще кучи всего. Кое-у кого, как вы
снилось, ее нет. У мен
 была: ноутбуки iRu Bravo и Intro на чипсете SiS, 
дро 2.4.23
Информаци
 по проблеме от Malcolm Caldwell <malcolm.caldwell@ntu.edu.au>:
There is a well known problem with acpi on some laptops - basically the system takes AGES to respond when asked to check the laptop battery. This would very easily cause timeouts for things like video grabbing.
I don't know about KDE, but there is a patch for the gnomebattstat-applet that changes it to work with acpi events - this means that the applet gets notified by the system of battery changes and the applet no longer needs to poll.  Maybe there is an equivalent patch for kde?
If not, something that *may* help is to run a recent kernel withpreemption turned on.  My impression is that my system seemed to be more responsive while running an unpatched battstat-applet.  As I said, this is just my impression, and even if it is true it does not necessarily mean that v4l will work any better.
(Of course, even with a preempting kernel the unpatched battstat-applet uses heaps of cpu)
I am no expert on acpi etc. but my feeling is this is your problem.