Сфотографировал свою кухню, пока на ней никто не бренчал. Люблю её.

Итак, что мы имеем на фото.

Нижняя клавиатура - рабочая станция Korg Trinity. Почтенный пожилой японец, родоначальник обширного семейства Trinity/Triton и их многочисленных производных. Несмотря на почтенный возраст (ориентировочно 15-20 лет, точнее сказать не могу, брал с рук), на синтезаторе ни царапинки, работает идеально. С него я обычно играю и пишу всякие пианинки, электропианинки, органы, пады, колокольчики, вот это всё - очень густое, жирное звучание. Электронные тембры, разумеется, по большей части морально устарели и годятся разве что воссоздавать дух эпохи. На таких машинках в конце девяностых - первой половине нулевых было сделано куча радио-хитов, благо, эта техника позволяет делать аранжировки, не задействую какой-либо дополнительный инструментарий: в наличие навороченный секвенсор, большой тачскрин, флоппи-дисковод, а также возможность расширять функционал за счёт установки дополнительного железа - жёстких дисков, плат, реализующих дополнительные алгоритмы синтеза, дополнительных входов/выходов, и т. д. Само собой, сейчас такой функционал гораздо проще реализуется с помощью десктопа и программного секвенсора, так что такие специализированные устройства постепенно уходят в прошлое.

На втором этаже разместилась миди-клавиатура CME UF50. Добротное устройство с кучей контроллеров и возможностью их перенастраивать как угодно под себя, с приятной упругой клавиатурой, хотя, к сожалению, достаточно шумной. Подсоединяется это миди-устройство к ноутбуку через беспроводной USB-свисток. С миди-клавиатуры я обычно играю то, что выигрышнее звучит через программный секвенсер, в основном живые акустические инструменты - скрипочки, дудочки, этнику, иногда рояльки, хотя четырёх октав маловато для комфортной игры на рояле.

На отдельном пюпитре расположился ноутбук Acer Aspire V5. На ноутбуке установлена Slackware 14.2 с Xfce, потому что ультрастабильно и легко пересобрать нужные компоненты системы под себя. Ядро пересобрано с настройками для лучшей отзывчивости, наложены патчи, добавляющие планировщик MuQSS (бывший BFS). Включен rtirq - демон, дающий высокий приоритет реального времени псевдопроцесам ядра, ответственным за работу с аудио, а также компонентам системы, отвечающим за вывод звука, и аудиоприложениям.

На ноутбуке запущен DAW - Reaper, нативный, звук выводится через бэкэнд ALSA. От использования JACK я отказался, при том же размере буфера он иногда потрескивает. Задержка ввода/вывода при игре с миди-клавиатуры составляет чуть больше 11 миллисекунд. Внутри DAW загружено несколько инстанций секвенсера Kontakt. На отдельные дорожки повешены отдельные пресеты/тембры, переключаясь между дорожками через контроллеры миди-клавиатуры или хоткеи, я переключаю тембры.

На заднем плане в кадр попали микшер, здоровенный басовый кабинет, два гитарных кабинета один на другом в углу, барабанка сбоку, в общем, типичное оборудование для «тяжёлой» комнаты на репетиционной базе.

Так и живём.

>>> Просмотр (4160x2336, 1648 Kb)

Пьер Луи Боссарт из Intel просит желающих потестировать новый аудио-драйвер для Intel Bay Trail CR. Требуется планшет на Bay Trail CR, умение собирать ядро и свежие прошивки.

Исходники: https://github.com/plbossart/sound/commits/t100taf-3
UCM-файлы: https://github.com/plbossart/UCM/tree/t100-test/bytcr-rt5640
snd-soc-sst-acpi нужно заблеклистить, чтобы загружался bytcr-rt5640 вместо depricated by-rt5640.

Что тестировать:
В dmesg должно появиться «Detected Baytrail-CR platform» и что-то типа

[    5.407676] bytcr_rt5640 bytcr_rt5640: snd-soc-dummy-dai <-> media-cpu-dai mapping ok
[    5.407908] bytcr_rt5640 bytcr_rt5640: snd-soc-dummy-dai <-> deepbuffer-cpu-dai mapping ok
[    5.408138] compress asoc: snd-soc-dummy-dai <-> compress-cpu-dai mapping ok
[    5.424785] bytcr_rt5640 bytcr_rt5640: rt5640-aif1 <-> ssp0-port mapping ok

Кристиан Шаллер (Christian Schaller), возглавляющий группу по развитию десктоп-систем в компании Red Hat и Fedora Desktop Team, официально анонсировал проект PipeWire, в рамках которого развивается мультимедийный сервер нового поколения, расширяющий возможности PulseAudio средствами для обработки потоков видео, и в будущем идущий на замену PulseAudio. Первым этапом внедрения станет поставка PipeWire в Fedora 27 для обработки видео, в то время как PulseAudio пока продолжит применяться для звука. Код проекта написан на языке Си и распространяется под лицензией LGPLv2.1.

Изначально проект развивался одним из создателей фреймворка GStreamer под именами PulseVideo и Pinos (в честь испанского города), но позднее было выбрано более подходящее имя. PipeWire расширяет область применения PulseAudio обработкой любых мультимедийных потоков и способен смешивать и перенаправлять потоки с видео. PipeWire также предоставляет возможности для управления источниками видео, такими как устройства захвата видео, web-камеры или выводимое приложениями содержимое экрана. Например, PipeWire позволяет организовать совместную работу нескольких приложений с веб-камерой и решает проблемы с безопасным захватом содержимого экрана и удалённым доступом к экрану в окружении Wayland.

PipeWire также может выступать в роли звукового сервера, обеспечивающего минимальные задержки и предоставляющего функциональность комбинирующую возможности PulseAudio и JACK, в том числе учитывающую потребности систем профессиональной обработки звука, на которую не мог претендовать PulseAudio. Кроме того, PipeWire предлагает расширенную модель безопасности, позволяющую управлять доступом на уровне отдельных устройств и конкретных потоков и упрощающую организацию проброса звука и видео из изолированных контейнеров и в них. Одной из главных целей является поддержка самодостаточных приложений в формате Flatpak и работа в графическом стеке на базе Wayland.

Основные возможности:

• захват и воспроизведение звука и видео с минимальными задержками;
• средства для обработки видео и звука в режиме реального времени;
• многопроцессная архитектура, позволяющая организовать совместный доступ к контенту нескольких приложений;
• модель обработки на основании графа мультимедийных узлов с поддержкой циклов обратной связи и атомарных обновлений графа;
• возможность подключение обработчиков как внутри сервера, так и внешних плагинов;
• эффективный интерфейс доступа к видеопотокам через передачу файловых дескрипторов и доступа к звуку через совместно используемые кольцевые буферы (shared ringbuffer);
• возможность обработки мультимедийных данных от любых процессов;
• наличие плагина к GStreamer для упрощения интеграции с существующими приложениями;
• поддержка изолированных окружений и Flatpak;
• поддержка плагинов в формате SPA (Single Page Application) и возможность создания плагинов, работающих в режиме жесткого реального времени;
• гибкая система согласования используемых мультимедийных форматов и выделения буферов;
• использование одного фонового процесса для маршрутизации звука и видео, а также возможность работы в форме звукового сервера, хаба для предоставления видео приложениям (например, для gnome-shell screencast API) и сервера для управления доступом к аппаратным устройствам захвата видео.

>>> Подробности

Давным давно я покупал всей семье аппараты UMI-X2 (mt6589). Время этих телефонов прошло, апдейтов на них уже не прилетит, некоторые трубки частично убиты. К UMI-X2 еще и добавился еще и мой старый iOcean-X8 (mt6592) с убитым SIM-слотом. Выкидывать весьма производительные железки мне не хотелось, потому я сделал для аппаратов кастомные ядра и портировал Debian Stretch.

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

Бокс отпечатан из пластика PLA, крышка держится на пазах+магнитах. Сверху стоит вентилятор, под ним проложен фильтр от пыли, между «этажами» предусмотрены отверстия для вентиляции. На дне дырки, через которые выходит воздух.
В виде ножек использованы силиконовые антиударные самоклеющиеся накладки для мебели, которые легко можно купить в любом леруа.

Время печати всего удовольствия - около 30 часов на моем Flying Bear P902. Моделировал в SolveSpace.

Каждый аппарат по USB определяется как композитное устройство в составе которого: сетевая карта (cdc-eem), виртуальный последовательной порт с консолью и usb mass_storage (если потребуется прямой доступ к SD/eMMC).

На данный момент аппараты планируется использовать как ферму для сборки debian-пакетов под arm через Jenkins CI. Тут два варианта: если удастся завести docker, то узлы будут эквивалентны, с контейнерами под debian armhf/armel и raspbian armhf. А если нет - то на каждый аппарат по своему дистру. Нет только аппарата на aarch64, но что-то подсказывает мне, что если второй раз разобью экран своего K6000 Pro, будет и эта архитектура в этой чудной зомби-ферме.

Кстати, за время с прошлой новости, я добавил в MediaDeb поддержку WiFi для UMI-X2, перевел систему сборки проекта на cmake, добавил в ядро все необходимое для поддержки iotop, оптимизировал систему для работы с еMMC и еще сделал много мелких доделок, включая еженедельные сборки для поддерживаемых аппаратов. А еще сделал бенчмарки

>>> Просмотр (1920x3237, 2079 Kb)

Сегодня Марк Шаттлворт на insights.ubuntu.com объявил о прекращении разработки Unity 8 и дисплейного сервера Mir. Говорится, что в Ubuntu 18.04 LTS будет использоваться GNOME с Wayland или X Server. Также будет прекращена разработка Ubuntu Phone. Правда, стоит отметить, что компания Canonical не планирует останавливать разработку Ubuntu для IoT-устройств. Вместо Ubuntu Phone и Ubuntu Touch на базе click-пакетов будет Ubuntu Personal на базе snap-приложений.

>>> Подробности

Эта статья является переводом статьи из блога главного разработчика композитного менеджера KWin (используется в KDE) Мартина Гресслина. Оригинал вы можете прочесть по ссылке. Далее идёт повествование от автора. Прошу сильно не пинать за качество перевода.

В этой заметке я хотел бы поделиться мыслями о том, как улучшить игровой опыт в Linux.

Ситуация с X11

В X11 главная проблема для игр, это композитор. Играм необходим прямой доступ к графическому процессору (видеокарте), без каких либо посредников. Для сравнения, возьмём игровую консоль Playstation: когда вы запускаете игру, вы можете быть уверены, что она получила полный доступ к графическому процессору (GPU). Композитинг X11 предоставить такого не может. Композитор в X11 должен полностью скомпоновать сцену. Выглядит это так:

• Игра рендерится через OpenGL/GLX;
  
• X-сервер уведомляет композитор через расширение Xdamage;
  
• Композитор рассчитывает область для перерисовки;
  
• Композитор использует расширение Xcomposite для получения пиксельной карты для игрового окна;
  
• Композитор связывает пиксельную карту с текстурой OpenGL;
  
• Композитор рендерит текстуру, используя OpenGL/GLX поверх игрового окна;
  
• X-сервер предоставляет готовое изображение из композитора через KMS.

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

Обходные пути в X11

Существует готовое решение чтобы исправить это, известное как «unredirection full-screen window (отключить перенаправление для полноэкранных окон)». Идея заключается в том, что композитор не будет работать для полноэкранного приложения, и будет использована обычная, «не композитная» функциональность X-сервера.

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

В KWin/Plasma, у нас есть лучшее решение: блокировка композитора. Мы можем это сделать, так как не требуем композитинга, в отличии от окружений с обязательным композитингом, где можно использовать только unredirection. У нас даже есть высокоуровневый API для игр, для того чтобы они могли сообщать, что необходимо заблокировать композитинг.

Это также объясняет, почему в KWin/Plasma не включена по умолчанию опция отключения полноэкранного композитинга. Это может вызвать проблемы в работе неигровых приложений (например тиринг в видеоплеере. прим.перев.), но рекомендуется для игр. Также это объясняет почему мне пофиг на тесты PTS (Phoronix Test Suite), так как по моему мнению они проводятся с неправильными настройками. Если бы нас это волновало, то можно было бы просто убедиться, что используемые в PTS игры, отключают композитинг.

Ситуация с Wayland.

В Wayland всё гораздо лучше, так как теперь нет X11-прослоек. Теперь процесс выглядит так:

• Игра рендерится через OpenGL/EGL;
  
• Композитор получает уведомление через wl_surface;
  
• Композитор напрямую представляет wl_buffer через KMS, так как знает что тут больше не на что смотреть.

Так что ситуация значительно улучшилась. Хочу отметить, что KWin пока не поддерживает эти этапы и всё ещё рендерит через OpenGL, но мы движемся в этом направлении.

Однако, я думаю, ещё есть проблемы. Наш композитор (KWin) по-прежнему получает события от других окон, может «проснуться» и так далее. Запуск игры в режиме рабочего стола означает, что будут другие процессы в системе, с которыми игра должна разделить ресурсы. Мы хотим пойти по примеру Playstation: игре всё, остальным - ничего. Я не хочу чтобы KWin отбирал ресурсы CPU/GPU у игры.

Управление видеорежимами в ядре (Kernel Mode-Setting, KMS) в играх.

Итак, что мы можем сделать? Я думал об этом и предлагаю кардинально решить проблему с играми в Linux: убрать оконную систему! Игры должны общаться с KMS напрямую, игры должны взаимодействовать с libinput (библиотека ввода, прим. перев.) напрямую. Давайте удалим все лишние прослойки, нам это не нужно, это только мешает игровой производительности.

Когда игра запустится в полноэкранном режиме, можно создать отдельную сессию на другом виртуальном терминале (tty) и предоставить управление этой сессией через logind. Это позволит игре открыть файлы для рендеринга и обработки ввода также, как это делает композитор Wayland. Рендеринг может быть осуществлён через EGL поверх DRM/GBM, также как в композиторе Wayland. Игра получит полный контроль над KMS. Нужно другое разрешение экрана? Без проблем, бери и выставляй. В режиме рабочего стола, это всегда проблематично (гораздо хуже в X11, но лучше в Wayland). Для игр в оконном режиме ничего не изменится, они так и будут запускаться в режиме рабочего стола. (Прим.перев. По сути автор предлагает давно известную концепцию «запуска в отдельных иксах», но лишённую кучи недостатков).

Конечно, это должно убрать все взаимодействия с окружением рабочего стола. Это то, что нужно рассматривать в первую очередь, например, как заставить, скажем, Mumble (программа для аудиоконференций, прим. перев.) работать с такой конфигурацией? Может игре нужно запускать собственный Wayland-сервер?

Это также сломает Alt+Tab (сворачивание игры, прим.перев.). Ну, не совсем, правда. Для X11, который захватывает клавиатуру в некоторых играх, Alt+Tab всё равно не работает, так что тут особо ничего не потеряешь. Но конечно, всегда можно будет переключиться через Ctrl+Alt+F1 в рабочую сессию. Игры также должны иметь общий путь для достижения этой цели, на мой взгляд.

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

Это вольный перевод статьи, намедни размещённой на phoronix. Оринальная статья — обзор недостатков, их исправлений и преимуществ между X и Wayland. Её написал Eric Griffith, при участии Daniel Stone, специально для ресурса phoronix. Работа собрана по кусочкам из презентаций Keith Packard, David Airlie, Kristian Høgsberg, из страниц про X11, X12, Wayland в вики и на freedesktop.org, из прямых интервью с разработчиками.

Оригинал выпущен под Creative Commons версия 3, с указанием авторства; перевод доступен на тех же условиях (с указанием на авторов оригинала, как мне кажется).

( читать дальше... )

>>> Подробности