Звуковых дров под пингвина 2а: OSS и ALSA. Недавно в кернелы стали поставляться с ALSA звуковыми дровами (они посовременее). Вот и поддержку им сделали...
Давить надо программы, которые ориентируются на OSS и ALSA,
вместе с программерами... Мля, ну ведь написали нормальные
саунд сервера - ESD и ARTS, че мешает делать по современному?
У всех карты поддерживают виртуальное микширование с нескольких источников на один /dev/dsp? Или очень приглядна
надпись - "/dev/dsp кем то занят, заходите позже"? Если от esd
потихоньку начинают отказываться, то уж arts будет стандартом
в KDE и будущем Gnome2 навеки, так как возможностей у arts
просто охренительны, да и писать под него гораздо проще, чем
под OSS и ALSA!!! Короче, саундсервера рулят, так как их для
этого и придумали!!! Всякие низкоуровневую интеграцию
в прогах поддерживающих саунд - давить как тараканов!
P.S. Вообщем, я посмотрю на это безобразие еще немного,
и переделаю поддержку звука в wine/winex под arts, мля,
to McMCC: Блин если бы эти серверы (esd & arts) нормально работали народ юзал б их, и всякие там OSS и ALSA просто не юзали, их просто бы не существовало.
>Блин если бы эти серверы (esd & arts) нормально работали народ >юзал б их, и всякие там OSS и ALSA просто не юзали, их просто бы >не существовало.
2Drolyk: Мы о разных вещах вообще-то... OSS и ALSA - это
головная боль саундсерверов, незачем программам знать о
тонкостях API низкого уровня, сервер вот он, крутится поверх
OSS и ALSA, зачем растрачивать силы при написании програм на
совместимость с драйверами? Где логика? Я пишу, к примеру,
какой-нибудь плеер и хочу, что бы он играл не затрачивая
внимания через какой тип системы, OSS или ALSA, он будет
у меня играть. Arts давно у меня не вызывает нареканий в
работе, все стабильно и чисто, главное это то, что код программы
не заморачивается большим колличеством ненужных действий,
кто хоть раз писал поддержку под arts, тот меня поймет....
Что же касается "их просто бы не существовало", то у вас не
верное представление, о том, что я пытаюсь доказать, какраз
саунд сервера не могут работать без OSS и ALSA, все ключевые
моменты и тонкости при работе с этими системами и берут на
себя саунд сервера, а вот со стороны клиента этого 100% не
нужно и не требуется, и так везде делается, в любых современных
ОС...
А как там с синхронизацией звука? Т.е. capture видео/звука сделать не
получится, или это уже как-то хитро обошли (but I doubt it)
Опять же, mplayer через esd - такое Г.
Время реакции при выводе через саунд сервера не может быть таким же, как
при выводе напрямую через драйвера. Опыт показывает, что разница во времени
офигительная. По крайней мере с esd.
>А как там с синхронизацией звука? Т.е. capture видео/звука сделать не
>получится, или это уже как-то хитро обошли (but I doubt it)
Получится, esd конечно не пригоден для этого, но его и никто не
рекомендует, я больше всего склонен в сторону arts (analog realtime synthesizer), так как это больше чем просто саунд сервер, умеет
делать все, в том числе Midi synthesis, Full duplex audio processing,
решены проблемы с latency, и многое другое. Полее подробно
можно почитать на http://www.arts-project.org
>Время реакции при выводе через саунд сервера не может быть таким же, как
>при выводе напрямую через драйвера. Опыт показывает, что разница во
>времени офигительная. По крайней мере с esd.
Вот именно поэтому и рекомендую использовать arts....
P.S. Есть специальные выпуски standalone arts, которые не привязаны
к каким либо оконным менеджерам...
Хотел немного добавить, сам я предпочитаю использовать Сишное API
aRts - artsc.h, так вот там есть специальные функции для play/record
arts_stream_t arts_play_stream(int rate, int bits, int channels, const char *name
);
arts_stream_t arts_record_stream(int rate, int bits, int channels, const char *na
me);
Так что не вижу особых проблем....
2McMCC Все таки wine не совсем прикладное приложение - в том смысле что ему видимо надо общатся с железом как можно ближе к ядру. Я не специалист в звуковых API по этому вопрос чисто теоретический :-) Вы сравнивали звуковые API ALSA, Arts и Win32 и уверены что все, что понадомится эмулировать, действительно возможно с помощью "упрощенного" API Arts ?
2kernel: Шутишь? Нафига wine общаться со звуковухой на уровне драйверов?
>Вы сравнивали звуковые API ALSA, Arts и Win32 и уверены что все, что
>понадомится эмулировать, действительно возможно с помощью "упрощенного"
>API Arts ?
Давайте сразу оговоримся - ALSA и OSS - это драйвера, или все то, сверху
которых крутятся саунд сервера...
API Arts я бы не сказал, что упращенный, наоборот, довольно расширенный
по возможностям, а вот для С API Arts - действительно упращен куда некуда.
Я вот, к примеру, написал примочку для esd, что бы он работал через arts!
Прикол в том, что некоторые проги, коммерческие, используют esd, типа
таких как реалплеер и win4lin, так вот, теперь в KDE нет никаких проблем,
весь звук идет через arts, даже если прога использует esd, и нет драки за
один /dev/dsp.
McMCC - а патч оборачивает весь API esd или только его часть? Достоин ли он проталкивания в дистрибьютив esd ?
Насчет патча - хотелось бы посмотреть, выяснить может ли он быть включен в esd as is или нужна доп. доработка до соответствия стандартам (вопросы - он допускает режим, в котором esd работает без arts (то есть enabling/disabling proxying at runtime)? Патч предлагают направить на gnome-cyr (at) gnome.org - мы там его посмотрим (рекомендую на этот список подписаться). Архивы и подписка на mail.gnome.org
Спасибо за патч.
>а патч оборачивает весь API esd или только его часть?
Он лишь заменяет вывод/ввод с OSS/ALSA на arts, поэтому
не мешает API esd, т.е. если раньше esd садилось на /dev/dsp
непосредственно, то теперь он подключается к arts, а так как
arts реалтаймный, то потерь и задержек при воспроизведении
или записи быть не должно.
>Насчет патча - хотелось бы посмотреть, выяснить может ли он
>быть включен в esd as is или нужна доп. доработка до
>соответствия стандартам (вопросы - он допускает режим, в
>котором esd работает без arts (то есть enabling/disabling proxying at
>runtime)?
Патч я написал за 10-ть минут, как говорится - сделал на коленке,
благодаря тому, что код esd очень удобочитаемый, поэтому
не составило труда быстро сделать за место OSS/ALSA поддержку
через arts. Что же касается переключения, т.е. делать выбор
опциями при запуске esd, что использовать в качестве
воспроизведения или записи, я конечно могу, но так как не у
каждого есть в системе OSS и ALSA одновременно, они между собой
просто передеруться, то логично доделать патч таким образом,
чтобы была возможность переключения только между aRts-OSS или
aRts-ALSA. Я уже этот вопрос изучил, и буквально сегодня-завтра
сделаю такую фичу...
>Патч предлагают направить на gnome-cyr (at) gnome.org - мы там
>его посмотрим (рекомендую на этот список подписаться). Архивы
>и подписка на mail.gnome.org
Постараюсь его прилизать побыстрому и тогда пошлю...
чтобы была возможность переключения только между aRts-OSS или
aRts-ALSA. Я уже этот вопрос изучил, и буквально сегодня-завтра
сделаю такую фичу...
OK. В идеале конечно надо еще уметь автодетектить - запущен ли arts, и если да,
пытаться играть через него. Может еще проверив переменные окружения - kdm
ведь должен что-то выставлять. Но и иметь возможность отключить этот
автодетект тоже надо иметь (посредством опций в конфиге - у новых esd
есть конфигурационный файл).
Спасибо заранее.
2McMCC: Почему aRts, а не NAS (Network Audio System который) ? У него идеология такая же как у Х-ов, он не обременен всякими наворотами как aRts (типа GUI, CORBA). И обратной связью обладает (может сказать, сколько уже проиграно, а то мало ли что там в сети произошло).
2Agweb: arts тоже не обременен, есть standalone версия, которой
не нужно гуй, а CORBA можно не использовать, к тому же, NAS не сильно популярен, как arts или esd.
2hvv: Я немного прогнал, насчет легкой реализации переключения,
но в принципе, я сделал как автодетект, если arts не загружен,
то esd пытается подключится к OSS или ALSA, вроде бы все
работает, но, как стоит сделать exit(); из программы, то выдает
Segmentation fault, скорее всего функция инициализации для
проверки есть arts или его нет, делает что то некорректо в памяти,
и при exit что то с ней происходит,хотя, возможно, это очередной
глюк в glibc 2.2.5 от RH. Просто я уже сталкивался с проблемами
arts_init()+glibc.... Давай сделаем проще, я вышлю патч, а вы
его попробуете и потом скажете чего и как?
Сегфолт при выходе можно поймать в отладчике - где он происходит?
Короче, патч лучше кинуть в gnome-cyr@ (предварительно подписавшись) - кто-нибудь может найдет время его протестировать у себя.
Да знаю я, что гуй и корбу отключить можно. Не в этом дело. А в том, что аРтс - слишком глобальная штука. Это не sound server, а какой-то конструктор, который пытается хорошим быть во всем. Это как за >1 зайцами гнаться. А NAS - это именно sound server, да еще с отличными сетевыми возможностями. Использовать aRts просто для вывода - это как из пушки по воробьям, это как писать скрипт из 5 строчек на перле вместо 1 на awk да и то в командной строке. aRts популярен потому что в KDE встроен и везде светится. А NAS собираются включать в поставку Х-ов в будущем. Он уже встраивается в Х-терминалы. По мне, так aRts должен оставаться синтезатором-большим-конструктором-без-аудио-вывода, а вывод звука передавать в NAS. NAS поддерживается XMMSом и mpg123. В нем есть wrapper для OSS-only прог, типа как runsocks для socks: "wrapper ./proga".
