Статья о развитии X Window System

Реально "все переписать" надо начинать с протокола X11. А его менять нельзя - он священная корова.

Кстати, помимо звука нужно интегрировать USB, Fireware, LPT и COM (киски подключать), line-in, флоппарь
что еще?
а! tv-tunner in и tv-out (последний на клиенте делать не тру - лучше на сервере)

у кого будут дополнения?

> Ну а чем fb в этом смысле не устраивает?

А что, fb уже предоставляет аппаратно ускоренные функции отрисовки графических примитивов? Или предлагаешь, отдав деньги за акселератор, не юзать его, переложив все на ЦПУ?

>Кстати, а почему emacs не unix-way? (если отделить емакс и его пакеты)

Потому что пакеты емакса взаимодействуют друг с другом через вызовы лисповых функций, а не гоняют plain-текст между собой, как unix-way-ные проги.

> Реально "все переписать" надо начинать с протокола X11. А его менять нельзя - он священная корова.

Будь прогрессивнее - сделай X12

Ага. И выкини за борт тысячи приложений ценой (ну мне даже не представить их суммарную стоимость).

А ты интрегрировал яйцерезку в свой авто? А в обеденный стул?
Если нет, то объясни, пожалуйста, почему?

> Очень правильный вопрос - по поводу мыши и клавиатуры. В идеале, и их
> не надо бы внутри иксов

а что было вначале ? вначале было именно так - отдельно клавиатура, отдельно мышь, отдельно дисплей (кто помнит постскрипт дисплеи?). потом уже появились иксы которые это дело более менее интегрировали. логичным продолжением будет уже интеграция звука. и это понимал икс консорциум еще 6 лет назад.

и почему в иксах нужна интеграция звука ? да ради синхронизации. чтобы не полагаться на равенство латентностей звукового и графического канала. которое даже на локальной машине не всегда выполняется, что уж тут говорить про сетевую работу.

касательно консольных прог работающих со звуком - есть еще большая куча консольных программ которые не иксовые но тем не менее ориентированых на графику (типа imagemagick, latex, gnuplot). никто же не говорит что раз так - значит иксы не нужны. хотя сейчас же вылезет какой нибудь троль с таким лозунгом.

если альфекс требует ответа а как же все таки взаимодействует звук и графике - пусть походит с затычками пару дней - так до него быстрее дойдет что слуховой канал восприятия является с одной стороны альтернативным и неконкурентным зрительному, с другой стороны - дополнительным к нему.

> Внимательно слежу за вашими сообщениями в этой новости и могу сделать
> вывод, что самые комфортные Хсы для вас - windows.

и попал в лужу как и все остальные советчики, которые понятия при этом не имеют - есть в виндах сетевая прозрачность графики и звука или нет ?
5 лет назад, когда виндой еще немного пользовался, этого не было.

> А ты интрегрировал яйцерезку в свой авто? А в обеденный стул?
> Если нет, то объясни, пожалуйста, почему?

а ты уже дезинтегрировал свой унитаз на отдельно стул, горшок, бачок для слива и собственно слив ? если нет то почему ?

> > наличие открытого порта для X-сервера тебя не смущает?

> он открыт ТАМ, а ты мне предлагаешь открыть порт ЗДЕСЬ

Ты дурак или только лечишься? X-сервер держит открытым порт, на который приходят программы с удаленных хостов. Точно так же и esound/arts/jack/nas держат ткрытм порт на той же машине, где запущен X-сервер, и в этом отношении они ничем от него не отличаются?

> > дак и xorg с nas тоже, отлично интегрируется - в чем проблема то ?

> да не интегрируются они никак. и вообще никак не взаимодействуют.

Они и НЕ ДОЛЖНЫ взаимодействовать! Это ортогональные системы - есть вагон графических приложений без звука. Есть вагон неграфических приложений со звуком!

> То, что ssh перенаправление не отвечает за esd - это не проблемы esd и не проблемы xorg.

Это проблема Tester-а который "не изволил асилить" при запуске ssh ключик -L :-)

> Они и НЕ ДОЛЖНЫ взаимодействовать!

Они МОГУТ НЕ взаимодействовать, хотя вполне МОГЛИ БЫ, если бы такой механизм был.

> Это ортогональные системы - есть вагон графических приложений без
> звука. Есть вагон неграфических приложений со звуком!

а эшелон графических приложений со звуком должен сам разбираться со своими проблемами.

ты у нас самый умный, знаешь кучу манов - подскажи как жестко синхронизировать вывод звука при открытии окна? допускается погрешность в районе 20-30 мс, более 100-200 мс недопустимо. а я потестю - в условиях различной нагруженности как сети так и проца.

тут кто-то линк давал на этот сайт
нарыл хорошенький пдф, который предлагает вариант который я и обдумывал - прокси экстеншн

http://www.mediaapplicationserver.net/pdf/lk2002.pdf

X --- тоже асинхронный протокол.

>а эшелон графических приложений со звуком должен сам разбираться со своими проблемами

Именно так. И только так.

>а ты уже дезинтегрировал свой унитаз на отдельно стул, горшок, бачок для слива и собственно слив ? если нет то почему?

что-то меня на смех пробило представил как Тестер тащит монолитный унитаз с бачком и куском трубы

хотя почему только сам "фаянс и ко"

заодно ещё и стояк подъездный

Правда весело ...

Хотя впринципе я его понимаю

Инструмент синхронизации был бы полезен, но нужен он не везде и не всегда

я вообще мало представляю себе задач где такое может быть необходимо /специфические задачи по обработке видео|звука с участием оператора, просмотр+прослушивание мультимедиа да и всё, ну может быть подачу звуковых сообщений по определенным событиям/

кстати, весь тред не осилю щас, а есть способ синхронизировать морду X приложения и звук с минимальными погрешностями?

>а ты уже дезинтегрировал свой унитаз на отдельно стул, горшок, бачок для слива и собственно слив ? если нет то почему ?

Тестер, лично у меня унитаз и сливной бачок представляют собой ДВА предмета. Канализация у меня находится ОТДЕЛЬНО от унитаза, при желании я могу отключить унитаз от канализации, могу подключить к другой канализации.

Вы мне лучше вот что скажите - вы уже интегрировали освещение в ванной комнате с унитазом и кранами?

Хехе, так Вы хотите объединить звук и изображение ТОЛЬКО с целью синхронизации? Тогда должен Вас огорчить - иксовый протокол никогда не был реалтаймовым (что необходимо для доставки звука). Совершенно не представляю, как Вы собираетесь синхронизовать звук (для которого существены временнЫе параметры доставки байтиков) и изображение (иксы не делают НИКАКИХ обещаний по поводу того, когда сервер реально отрисует картинку).

В рамках существующего в иксах подхода синхронизация изображения и звука решаема с бооольшим трудом (если вообще решаема) ДАЖЕ если запихать код "сервера звучания" в иксовый сервер. А вот кошмар для maintenance Вы таким образом создадите, это гарантировано (и без того ужасно толстый сервер станет еще толще).

Дык, эта... звук должен прозвучать одновременно с отображением картинки. Значит решение, когда орать, должен принимать X-сервер, вернее на стороне X-сервера. В чём проблема-то?

Проблема в том, что клиент будет слать звуковой поток в реальном времени, а сервер будет их засылать в динамик "как попало". Клиент будет рассчитывать, что если между двумя звуками будет проходить секунда, то и иксовый сервер сыграет эти звуки с разницей в секунду. А иксы этого обещать не смогут. Соотв. и качество звука будет какое угодно - примерно как если на виниловом проигрывателе время от времени придерживать пластинку (а иногда даже подталкивать).

То есть нельзя отослать два связанных события? Или как-то сообщить серверу об их связанности?

(события - "открытие окна" и "громкий крик 'вау!'")

Почитал про протокол ...

<лирика>
вот не нравится мне svu
потому что ему не нравится qt
:-)
</лирика>

вынужден согласится с svu - гемор для разработчиков серьезный
вообще с синхронизацией ж..а

А как тонкие клиенты работают?
имеют X сервер + Звук.Сервер, а над их синхронизацией голову не ломают?

Мне неизвестен такой механизм, скажу честно.

На самом деле, мы тут с Вами не договорились о предмете обсуждения. Если Вы хотите просто послать серверу запрос "Издай громкий крик вау" - это еще не так страшно. Сервер, например, опубликует список известных криков (через атомы), приложение выбирает атом и засылает на сервер - допустим, разработали Вы расширение xsnd и в нем будет запрос XBattleCry(Atom). В этом случае небольшая рассинхронизация между выскакиванием окошка и звуком будет не критична - пользователь простит.

Гайки, о которых я говорю - они в другом. Если Ваше приложение САМО захочет слать на сервер звуковой поток и синхронизовать его с происходящим на экране. Вот тут будет весело...

Ну я ж не рубль, чтоб всем нравиться;)

>Если Ваше приложение САМО захочет слать на сервер звуковой поток и синхронизовать его с происходящим на экране

Не совсем понял - это как бы смотреть кино, при этом картинку слать через "X-графику", а звук через "X-звук"?

Ага.

>Гайки, о которых я говорю - они в другом. Если Ваше приложение САМО захочет слать на сервер звуковой поток и синхронизовать его с происходящим на экране. Вот тут будет весело...

Да, именно здесь закопана _кака_
интересна синхронизация именно в таком случае

Я сам неплохой кодер, но всё приходящее в голову для решения подобной задачи пахнет такими извращениями, что становится мучительно стыдно ... :-)

хорошо что для меня это просто любопытство, а не необходимость найти решение 3хТьфу

Попахивает бредом немножко... Кажется, для таких вещей нужен специальный протокол и специальный софт...

>А что, fb уже предоставляет аппаратно ускоренные функции отрисовки графических примитивов?

Да.

>Кажется, для таких вещей нужен специальный протокол и специальный софт...

Я не помню кто начал :-), но разговор был про возможность реализации подобного в пределах X протокола.
Соответственно флеймик был в пределах начальных условий.
А то что размышления об этом похожи на бред ... такова селяви.

"Синхронное изображение+звук" уже давно "изобретено" - это контейнеры типа AVI, OGM, MKV и т.п. Вот только непонятно каким боком видео-аудио контейнеры относятся к X-протоколу? Или сервер должен мультиплексировать звук и видео в OGM (например) и передавать клиетну?:)

Бред? Проигрывание _клиентских_ звуковых файлов на иксовом терминале - это бред? Нюню...

Иначе не стоит и огород городить. Т.е., конечно, можно сделать и просто бибикалку из иксов - кстати, в XKB(!!!) есть примерно такое (называется Bells - к ним только Whistles не хватает%). Но это неинтересно. И не решает исходную постановку задачи.

>"Синхронное изображение+звук" уже давно "изобретено" - это контейнеры типа AVI, OGM, MKV

Вот об этом я и говорю. Контейнеры есть, и есть давно. А бредом выглядит именно впихивание этого в X.

Вы меня не поняли :) См. предыдущее сообщение.

Контейнеры не помогут, если Вы хотите программно выводить изображение (не обязательно сплошным потоком - последовательным вызовом методов xlib API). Допустим, Вы пишите программу - видео-телефон.

Да и как охрененный контейнер передать иксам - тоже очень интересный вопрос, сам по себе.

>Допустим, Вы пишите программу - видео-телефон.

Ммм... IPTV под линуком работает, сам видел. И вебкамеры работают.

Нормально они работают локально. На удаленных иксах Вы их видели?

>> А что, fb уже предоставляет аппаратно ускоренные функции отрисовки графических примитивов?

> Да.

Нет. Если ты утверждаешь, что таки да, то покажи мне способ, как из своей программы я могу покрасить заданную область экрана в некий цвет. Или как мне скопировать содержимое одной области видеопамяти в другую (для скроллинга). В иксах это соответственно XFillRectangle и XCopyArea. А как это сделать для fb, не напрягая CPU на задачи акселератора?

Мм... а в чём проблема, если это и так нелокальное приложение? Веб-камера там, я здесь...

Веб-камера - там. Вы (Ваш иксовый терминал) - здесь. А вот приложение (иксовый клиент), которое читает данные с веб-камеры и выкидывает Вам на иксовый терминал - вообще в третьем месте. И вот тогда иксы начинают вести себя удивительно.

Еще раз - не приспособлен иксовый подход для всех этих вещей. Он не рилтаймовый.

То есть смотреть одно и то же кино с сервера всему классу не получится? Гм. И как с этим предполагается бороться? И предполагается ли?

Да нет, очень просто, загоняется сырой звук и сырое изображение в контейнер, и тупо гонится по сети этот контейнер на терминальную машину. Ну а с него - как положено, с устройств ввода информация входящая (кстати, можно тоже сырым потоком, широкие возможности для нестандартных устройств ввода). Только сеточку потолще надо :)

Дык я и не предлагаю бороться. Я как раз говорю - что нельзя обеспечить реальную синхронизацию в рамках существующей асинхронной архитектуры иксов.

Размер контейнера-то какой будет? Если большой (целое кино) - тогда никаких iptv, видео-конференций, игрушек и пр. Если маленький - мы возвращаемся к начальной проблеме синхронизации.