CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
17.12.2018

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Заметки :: Блогометки :: Системы

Звук в Linux

http://www.slackguide.com/

Под звуковой подсистемой понимается инфраструктура операционной системы, отвечающая за работу установленных в компьютере устройств для обработки звуки, а именно — звуковых карт, а также различных подключаемых извне (по USB или Firewire) интерфейсов. Эта инфраструктура включает в себя не только драйверы к той или иной звуковой карте, загружаемые ядром операционной системы, но и интерфейс для разработки прикладных приложений (API), предназначенных для записи, воспроизведения и обработки звукового сигнала.

В настоящее время в GNU/Linux существует две конкурирующие звуковые подсистемы — OSS (старая) и ALSA (новая). Под OSS здесь подразумевается свободная версия этой кроссплатформенной звуковой подсистемы, которую можно свободно распространять — в отличие от коммерческой версии OSS. OSS издавна входит в состав ядер Linux.

Однако, при разработке ядер версий 2.5.x/2.6.x в качестве стандартной звуковой подсистемы была выбрана сравнительно новая ALSA, имеющая ряд конструктивных преимуществ перед OSS и во многом созданная по мотивам технологически удачных смежных звуковых подсистем ОС Mac OS X — CoreAudio и CoreMidi.

Разработчики OSS продолжают обеспечивать поддержку современных ядер ветки 2.6.x, однако количество приложений, спроектированных для работы именно с ALSA, неуклонно продолжает расти. Также, благодаря существованию OSS-эмуляции в подсистеме ALSA, старые приложения, рассчитанные на использование с OSS (например некоторые игры) можно использовать и с ALSA. Еще стоит отметить, что появилась и эмуляция ALSA в последних версиях OSS.

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

Исторически сложилось так, что разработка каждой новой мощной графической оболочки рано или поздно начинает требовать создания собственного звукового сервера. Так, благодаря графической среде Enlightenment появился популярный до сих пор звуковой сервер EsounD (ESD, Enlightened Sound Daemon). В ходе разработки KDE был создан сервер aRts (analog realtime synthesizer). До версии 2.0 в GNOME использовался ESD, после чего произошёл переход не просто на новый звуковой сервер, а на новую модульную мультимедийную инфраструктуру под названием GStreamer, позволяющую не просто смешивать звуки, а буквально строить из модулей как из кирпичиков свою систему передачи мультимедийных данных разного типа — звук, видео, изображения.

В некоторых случаях между звуковыми серверами возникают конфликты. Хрестоматийным является пример, когда приложение, основанное на библиотеках графической оболочки KDE, вместе с собой запускает звуковой сервер aRts, который отнимает у работающего сервера ESD доступ к файлу устройства звуковой карты (/dev/dsp), вследствие чего музыка, воспроизводившаяся в XMMS, стихает.

Поскольку GStreamer является решением, позволяющим подружить один звуковой сервер с другим, существует немалая вероятность того, что в будущем он станет стандартом для различных графических оболочек. Во всяком случае, в настоящее время aRts является официально неподдерживаемым проектом, а в качестве его замены рассматривается именно GStreamer. Ряд приложений для KDE уже использует Gstreamer для вывода звука. К таким приложениям, например, относятся популярные проигрыватели звуковых файлов amaroK и YuK.

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




Комментарии

Страницы комментариев: 1 :: 2 :: 3 :: 4 :: следующая

анонимус, Thu Apr 10 16:36:56 2008:
2 VolCh, среда, 9 апреля 2008 г. 18:48:12:
>>Ну автоматом он не может знать какие файлы я только что отредактировал
______________________________________________
Время доступа к файлу, ни о чем не говорит?

>>И если с первым (локальный файл) шелл еще может помочь автодополнением и т. п., то со вторым (удаленный хост) нет (на моем уровне знаний)
________________________________________________
Оболочке, глубоко пофиг локальный или удаленный хост.
Вообще Вы как то путанно объясняете и спрашиваете. Трудно понять в чем проблема.
Кстати просто Konqueror можно настроить как привычный файлменагер, а то и по круче. С консолькой, панельками и т.п.
Дерзайте:)
аноним, Thu Apr 10 15:30:17 2008:
2 VolCh, среда, 9 апреля 2008 г. 18:48:12:
Вот не могу я Вас понять. Что в винде Total Commander - часть этой операционной системы? Хотите в линуксе функциональный двухпанельный файловый менеджер: Krusader, Konqueror, Gentoo. Выбирайте! Или мало? Чем жаловаться лучше бы совета спросили. Вас же ни кто не заставляет наутилусом пользоваться.
nusgul, Thu Apr 10 09:36:23 2008:
2 VolCh, среда, 9 апреля 2008 г. 18:48:12:
>набирать каждую команду для каждого файда (ну или перечислять несколько файлов там где это допустимо синтаксисом) в консоли

Вы, как разработчик, конечно же слышали про переменные?

>- то же, но с использованием регулярных выражений и прочих прелестей bash (ну или другого шелла)
- разработка программы/скрипта на любом другом языке программирования, который можно использовать (например из доступных мне "с ходу" под CLI С/С++/PHP, ну и Java, хотя тут с ходу точно не получится, надо будет разбираться с нюансами)

Вытекает из предыдущего. Пишите на php, Вы же на нем как я понял кодируете? Что вообще не дает сделать вебинтерфейс для заливки файлов на веб и фтп?

Если уж так нужен именно Командер, попробуйте Krusader. Вполне приятная, для человека с выньпривычками штучка.
аноним, Wed Apr 9 21:16:36 2008:
>работать надо, а сгенту это врядли бы произошло скоро

Стереотип:) Можно и бинарные пакеты юзать. Или взять готовое решение - sabayon linux.
Алексей Федорчук, Wed Apr 9 19:55:09 2008:
2 Доброжелатель
> В корень зрите.
___
И от этого очень грустно...
Доброжелатель, Wed Apr 9 19:20:32 2008:
_
2 Алексей Федорчук, среда, 9 апреля 2008 г. 11:34:03:

// Но ведь нынешний чукча ни с какой стороны не читатель - он писатель (постов на форумах с просьбами о помощи).
Да и гугл у него, скорее всего, сломан с самого начала...


В корень зрите.
_
VolCh, Wed Apr 9 18:48:12 2008:
VolCh, вторник, 8 апреля 2008 г. 20:06:24:
>А какие ещё варианты?
Ну как мне видится:
- набирать каждую команду для каждого файда (ну или перечислять несколько файлов там где это допустимо синтаксисом) в консоли
- то же, но с использованием регулярных выражений и прочих прелестей bash (ну или другого шелла)
- разработка шелл скрипта
- разработка программы/скрипта на любом другом языке программирования, который можно использовать (например из доступных мне "с ходу" под CLI С/С++/PHP, ну и Java, хотя тут с ходу точно не получится, надо будет разбираться с нюансами)
- использование IDE - вполне допускаю, что укомплектование эклипса плагинами вполне может решить задачу намного более эффективно, но поиск нужных плагинов, их связь и т. п. ...
- использование "нестандартных" файл менеджеров типа разичных Commander'ов
- использование "стандартных" файл менеджеров (в моем случае наутилус)

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

Описал свой стандартный цикл на этапе внесения мелких изменений в логику/форматирование, когда дополнительные программы и не нужны обычно. Понятно, что полный процесс разработки более сложный
>Далее - все делать мышькой не получится все равно, и, например, вводить имя создаваемого файла(и адрес сервака для заливки файла) надо с клавиатуры.
Есть разница между вбить имя файла в предназначенное для этого поле, соблюдая только правила ФС, и вбивать команду с ключами и именем файла, соблюдая ее синтаксис (про опечатки, пользование --help и man даже не вспоминаю). Но и совсем без мышки, по-моему, не обойтись, хотя наверное можно и из консоли в браузере функционирование imagemap проверять :)
>А это означает , что надо переносить руку с мыши(а потом обратно), теряя время; либо набирать одной рукой, но при этом медленнее....
лет 20 назад я вообще не понимал зачем нужна мышка, когда проще в аналоге NC нажать F5 или в "консоли" набить "copy filename1 filename2", потом познакомился с DOS 3.30 (вроде бы, 3 точно, подверсию уже не помню, довольно быстро до 5, а потом 6.22 дело дошло, ну а дальше) и теперь без мышки жить не могу :)
>я уж молчу о том, что может возникнуть необходимость изменить права на файл или что-то в этом роде
в файл менеджерах можно :) причем опять-таки не напрягаясь в попытках вспомнить синтаксис chmod (какая там опция для рекурсии используется, -r или -R, каков порядок аргументов и т. п.)

>а, кстати позволяет ли ИЕ менять права на фтп?
Гейтс его знает, я под виндой-то его запускал только для проверки как он в очередной раз отреагирует на стандартный код

>И вообще, чем использование линуха (без консоли) в конкресно это плане отличается от использования винды? Вроде есть аналогичные редакотры, фтп клиенты, файл менеджеры и прочее. Каждый волен выбирать то, что ему удобнее.

Вроде есть, с первого взгляда, а приглядишься - функциональности не хватает привычной. Если в винде Total Commander у меня использовался как DE практически, то GNOME Commander'у еще очень далеко до этого. Да и вряд ли вообще будет "расти" в этом направлении, не тот "вэй" :)

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

С радостью бы сделал, чтобы устраивало, но не знаю как и возможно ли это в принципе без разработки своих программ/плагинов. Взял, кстати, Ubuntu, хотя особо не выбирал, понял, что 500 дистров в принципе это как 500 вариантов разных сборников "Все для офиса" от разных "производитлей", а постичь нюансы различий не научившись работать хотя бы в одном не реально. Хотя если бы винт не умер физичеcки начинал бы наверное с gentoo, сначала на вирт машине, потом и до полноценнубю ОС может быть дожил, а так хороший повод был для "полного погружения", но работать надо, а сгенту это врядли бы произошло скоро

2 nusgul, среда, 9 апреля 2008 г. 09:43:51:
2 VolCh
Поймите простую вещь, совсем не обязательно "еще один язык изучать, потом анализировать задачу, разрабатывать универсальный алгоритм ", те команды которые Вы выполняете каждый день, по нескольку раз, можно просто собрать в один файл и все, будет Вам скрипт делающий все автоматом.

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

Сорри, бежать надо, остальным завтра отвечу :)
анонимус, Wed Apr 9 11:56:56 2008:
2 VolCh, вторник, 8 апреля 2008 г. 18:10:51:
>>Угу, ему проекты надо делать, а не еще один язык изучать, потом анализировать задачу, разрабатывать универсальный алгоритм
___________________________________________________
Ага, если учесть что скрипты можно писать на php, вообще не подъемная задача получается:)
Алексей Федорчук, Wed Apr 9 11:34:03 2008:
2 Zaraki, среда, 9 апреля 2008 г. 10:22:30:33051Удалить
2 VolCh, вторник, 8 апреля 2008 г. 20:18:07:
>>
Наверное, имеет смысл [виртуально] собраться пользователям разных юниксов, у которых уже есть кое-какой опыт использования системы и решения разнообразных задач, и составить что-то вроде методички на полсотни страниц: что и как предпочтительно читать, основы философии юникса, простейшие приёмы работы в системе, использование конвейеров и перенаправления ввода/вывода, использование традиционных утилит.
>>

См. А.Федорчук. Доступный UNIX...
___
Ага, точно, читайте меня, как говаривал Бернард Шоу :)
А кроме меня, на эту тему писали Володя Попов, Сергей Кузнецов (и многие другие наши соотечественники), Армстронг, Керниган с Пайком.
И не нужно лазать по сотням сайтов - достаточно этого.
Ну или просто в нормальный книжный магазин зайти.
В общем, написано много.
Но ведь нынешний чукча ни с какой стороны не читатель - он писатель (постов на форумах с просьбами о помощи).
Да и гугл у него, скорее всего, сломан с самого начала...
Zaraki, Wed Apr 9 10:22:30 2008:
2 VolCh, вторник, 8 апреля 2008 г. 20:18:07:
>>
Наверное, имеет смысл [виртуально] собраться пользователям разных юниксов, у которых уже есть кое-какой опыт использования системы и решения разнообразных задач, и составить что-то вроде методички на полсотни страниц: что и как предпочтительно читать, основы философии юникса, простейшие приёмы работы в системе, использование конвейеров и перенаправления ввода/вывода, использование традиционных утилит.
>>

См. А.Федорчук. Доступный UNIX...

Страницы комментариев: 1 :: 2 :: 3 :: 4 :: следующая

Комментарии заморожены.

Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds