У меня одно из требований по безопасности — это отсутствие привязки только к устройствам, на которых обычно водятся вирусы, и отсутствие необходимости ставить какой-либо дополнительный софт на компьютер. По этому требованию подходят фиксированный код (который небезопасен по другой причине), таблица одноразовых кодов и Hardware OTP.
Сам пользуюсь аппаратным генератором кодов подтверждения, который мне выдали в банке. Он, в отличие от сфотографированного в статье, при работе еще требует карточку и спрашивает PIN — т.е. еще один уровень безопасности. Итого, для перевода денег я должен правильно ввести логин и пароль от интернет-банка (раз фактор), взять в руки генератор кодов и карточку (факторы два и три), ввести PIN (фактор четыре), последние цифры счета и сумму, нажать OK, и ввести получившийся одноразовый пароль в соответствующее поле в интернет-банке. Достаточно удобно и в то же время безопасно, и еще работоспособно за границей.
Вот и надо понять (и самому, и другим объяснить), что надо при уменьшении громкости микрофона уменьшать на уровне ALSA в первую очередь, а что во вторую. Сейчас код написан «как проще», без учета особенностей, связанных с шумом.
Как я понимаю, это помогает на вашем ноутбуке. Давайте сделаем, чтобы это было по умолчанию? Нужно только прислать мне на e-mail убедительное доказательство, что это правильно:
1. Вывод amixer -c0 с настройками по умолчанию, которые делает PulseAudio для микрофона.
2. Одну секунду записи микрофонного шипения с этими настройками в wav-файл.
3. Вывод amixer -c0 после предложенных манипуляций с alsamixer, чтобы я мог посмотреть, что общее усиление не изменилось.
4. Одну секунду записи микрофонного шипения с этими настройками в wav-файл, чтобы я мог посмотреть, что шума действительно стало меньше.
По wi-fi у меня баг с затыком воспроизводится, удалось заснять wireshark'ом и разобраться.
По поводу latency — этот sink не позволяет ей управлять вручную вообще никак, а применяет общие правила для DYNAMIC_LATCNCY: выставляет в latency от самого требовательного проигрываемого потока, или потока, записываемого с monitor source. Поэтому совет: закройте pavucontrol, чтобы избавиться от записи с monitor source (а там по умолчанию стоит latency = 10 ms), и воспользуйтесь плеером, который не выставляет на своем потоке latency = 20 ms. Только тогда другой баг вылезет: mpv начнет отсчет времени с "-10 секунд". Причина этого бага тоже известна и будет обсуждаться с разработчиками вживую 15 октября.
Все универсальные элементы proplist'ов можно посмотреть в src/pulse/proplist.h (или онлайн тут: freedesktop.org/software/pulseaudio/doxygen/proplist_8h.html#details ). Только там много лишнего, и, например, на device.latency сам PulseAudio не реагирует (только сам ставит, когда захочет). Это в основном для информирования других приложений и для отладки.
ALSA-специфичные элементы можно посмотреть в src/modules/alsa/alsa-ucm.h — но это только для UCM, который работает только на мобильных платформах. Т.е. для десктопов и ноутбуков совсем нерелевантно.
А вот это неправда. Проблемы в ALSA есть, и они нерешаемые, кроме как путем переписывания всего слоя преобразования-микширования. Что и пытался сделать PulseAudio, безуспешно. Я понимаю, что PulseAudio плох, но возврат к dmix — это тоже не вариант.
А проблемы в ALSA такие (причем это только то, что задело лично меня):
1. Все кишки вынесены наружу в конфиг. В итоге по интернету разбрелось множество глупых конфигов. А авторам приложений ни на какие гарантии надеяться стало просто невозможно, т.к. pcm.default может быть чем угодно — в том числе голым hw без микширования, регулировки громкости и преобразования форматов.
2. Для микширования поверх HDMI или SPDIF приходится писать конфиг.
3. dmix работает только поверх устройств с очень специфичными требованиями: они должны (а) поддерживать mmap и (б) правильно работать, даже если приложение не уведомляет нижестоящие слои о том, куда именно в этот mmap оно записало. Т.е. без вызовов snd_pcm_mmap_begin() и snd_pcm_mmap_commit(). А такие устройства — это, по сути, только классические аппаратные PCI-карты (причем 6-канальная emu10k1 уже не является классической, т.к. физически состоит из трех стереокарт, к которым надо применять плугин multi, который уже не удовлетворяет второму требованию). И по той же причине никаких тебе bluetooth и софтовых многоканальных кодеков для spdif (P.S. я являюсь автором одного из двух таких кодеков) — т.е. смикшировать звук поверх 6-канального DTS-кодека для SPDIF средствами ALSA просто невозможно!
1. Потому что для приведения проекта в нормальное состояние таких продуктивных программистов, как Леннарт, еще поискать надо.
2. Потому что вообще в любом проекте разрушение уже сделанного — задача практически невыполнимая по политическим причинам. Это означает опровержение всех первоначальных доводов, ломку всей накопившейся пропаганды и переубеждение прозомбированных разработчиков.
3. Потому что патчи вида «обойти баг в другой библиотеке» не принимаются. А это именно баг в alsa-lib.
По поводу пункта 2 у меня план такой: убеждать их для разных случаев, что tsched и rewind неприменимы в данном конкретном случае. Почле достаточного количества итераций от них останется (утрирую) только один случай (воспроизведение одного источника без обработки на snd-hda-intel), который работает.
А давайте не будем зря теоретизировать и напрямую проверим гипотезу, что ваши проблемы действительно связаны с snd_pcm_rewind? Мне самому интересно, т.к. этот факт может понадобиться для дискуссии на конференции.
Прошу пересобрать и установить PulseAudio (ровно ту же версию, что в дистрибутиве, и с теми же патчами и опциями сборки) из исходников с одним изменением: в src/modules/alsa/alsa-util.c, надо заменить тело функции pa_alsa_pcm_is_hw() на «return false;». Тогда он вообще никогда не будет пытаться отматывать.
Кроме того, в /etc/pulse/daemon.conf прошу выставить:
и отдельно еще попробовать, чтобы нагрузить процессор:
resample-method = speex-float-5
Если глюки не пропадут, то надо будет разбираться дальше. Только желательно не на хабре, а через почту или XMPP.
Ну и еще насчет вашей карты: там особо хитрый тип элемента управления «Master» (6 каналов вместо обычных одного или двух), который PulseAudio пока не поддерживает. Поэтому управление громкостью получается полностью софтовым и 16-битным, что тоже может давать слышимые искажения в особо тихой комнате. Это баг.
При чем здесь аппаратный микшер? Его уже давно нет ни на одной из выпускаемых звуковых карт для портебительского сегмента (а в профессиональном сегменте на энергосбережение наплевать). Речь идет о сравнении цепочки plug:softvol:dmix и pulseaudio.
[весь текст ниже является пропагандой]
В цепочке plug:softvol:dmix размеры периода и буфера заданы жестко в конфиге, а приложение их как-либо поменять не может. Раз в период процессор должен проснуться. Соответственно, при настройках по умолчанию он должен проснуться 47 раз в секунду, даже если приложению такая отзывчивость (21 мс) не нужна. А не нужна она даже видеоплееру (там достаточно 33 мс). Лишние пробуждения процессора = лишний расход батарейки. Но в то же время такая схема с линейной записью в буфер и с фиксированным размером периода очень простая, и поэтому практически не имеет шансов нарваться на баги драйвера или оборудования. Все то же самое относится к JACK.
В случае с PulseAudio, прерывания от звуковой карты вообще выключены. Пробуждение процессора осуществляется по таймеру, частоту срабатывания которого (в отличие от частоты прерываний от звуковой карты) можно менять на лету. Поэтому от лишнего расхода батарейки, связанного с излишне высокой частотой пробуждений процессора, можно избавиться. А чтобы кукушку от ICQ вы слышали сразу, а не через пару секунд, приходится идти на такой трюк («динамическую задержку»): при появлении нового звука для микширования, необходимо записать новый смикшированный звук поверх уже отправленного для воспроизведения. Т.е. отмотать буфер назад с помощью функции snd_pcm_rewind(). Вот эта функция и является плохо отлаженной, и может при неправильной реализации приводить к глюкам при воспроизведении. К тому же известно несколько ситуаций, когда PulseAudio, за неимением правильной информации о состоянии буфера и ограничениях оборудования, пытается перемотать назад больше, чем можно.
Происхождение пшика при записи до конца не известно. У меня его нет, но у меня нет и скайпа. Улики до сих пор ни мне, ни в рассылку, никто не прислал. Если не пришлют в течение месяца — буду считать проблему выдуманной. См. также bugs.freedesktop.org/show_bug.cgi?id=83557 — если workaround в виде проигрывания тишины через module-echo-cancel помогает, то это оно (согласно этой теории, пшик в записанном появляется, когда Skype закрывает и переоткрывает свой поток проигрывания).
Сейчас у меня есть план, как функцию snd_pcm_rewind починить, а также дать PulseAudio правильную информацию о состоянии буфера и ограничениях оборудования. Я над этим работаю, но, к сожалению, натыкаюсь либо на непонимание, либо на неконструктивную (но справедливую) критику со стороны разработчиков ALSA. Подробности тут: comments.gmane.org/gmane.linux.alsa.devel/127246
Потому что каждое второе приложение на вашем компьютере полагается на размеры периода и буфера по умолчанию, доставшиеся в наследство от dmix'а (в смысле не выставляет совсем и совершенно зря надеется на результаты, гарантирующие приемлемую отзывчивость). А выставлять малое значение задержки по умолчанию нельзя, так как при этом вы же будете жаловаться на больший расход батарейки, чем в других операционных системах.
P.S. Понимаю, что проблема на самом деле социальная (непонимание того, что перерасход батарейки мнимый, т.к. его в вашем и не только в вашем случае не избежать). Решать социальные проблемы не умею.
Никого пинать не надо. Модуль для туннелирования звука по сети сейчас переписывают. Результат доступен как module-tunnel-sink-new в PulseAudio 5.0, и он лучше справляется с плохой сетью. А вот почему новая реализация не используется по умолчанию: bugs.freedesktop.org/show_bug.cgi?id=73426
Написать в рассылку pulseaudio-discuss. Или мне лично на patrakov@gmail.com. Приложить улики:
1. 1 секунду записи микрофонного шипения через PulseAudio (parec) в wav.
2. 1 секунду записи микрофонного шипения через ALSA (arecord) в wav. Обе записи должны быть с теми же параметрами касательно частоты дискретизации и числа каналов, как делает Skype. Подсмотреть можно в pacmd list-source-outputs.
3. Конфиг PulseAudio: /etc/pulse/*
4. Настройки ALSA-микшера как во время записи через ALSA, так и во время записи через PulseAudio: amixer -c0
5. Вывод pacmd list-sources
Основной кандидат в виновники шипения — это неоптимальное раскидывание усиления по ступеням в звуковой карте.
Еще есть маловероятная гипотеза, что это плохой ресемплер скидывает весь шум от микрофона в узкий диапазон, используемый для VoIP. Попробуйте заменить на speex-float-5 в /etc/pulse/daemon.conf.
Еще вариант, когда вылезает глупая комбинация — это когда пользователь настроил не до конца работающий обход провайдерских блокировок. Например, прописал у себя DNS от antizapret.prostovpn.org/ и оставил, несмотря на то, что в его случае смена DNS не помогает.
bugzilla.kernel.org/show_bug.cgi?id=85581
P.S. Готовый образ btrfs, на котором воспроизводится проблема, до сих пор скачал только один гуглобот и начал качать один пользователь Mac OS X.
Сам пользуюсь аппаратным генератором кодов подтверждения, который мне выдали в банке. Он, в отличие от сфотографированного в статье, при работе еще требует карточку и спрашивает PIN — т.е. еще один уровень безопасности. Итого, для перевода денег я должен правильно ввести логин и пароль от интернет-банка (раз фактор), взять в руки генератор кодов и карточку (факторы два и три), ввести PIN (фактор четыре), последние цифры счета и сумму, нажать OK, и ввести получившийся одноразовый пароль в соответствующее поле в интернет-банке. Достаточно удобно и в то же время безопасно, и еще работоспособно за границей.
1. Вывод amixer -c0 с настройками по умолчанию, которые делает PulseAudio для микрофона.
2. Одну секунду записи микрофонного шипения с этими настройками в wav-файл.
3. Вывод amixer -c0 после предложенных манипуляций с alsamixer, чтобы я мог посмотреть, что общее усиление не изменилось.
4. Одну секунду записи микрофонного шипения с этими настройками в wav-файл, чтобы я мог посмотреть, что шума действительно стало меньше.
По поводу latency — этот sink не позволяет ей управлять вручную вообще никак, а применяет общие правила для DYNAMIC_LATCNCY: выставляет в latency от самого требовательного проигрываемого потока, или потока, записываемого с monitor source. Поэтому совет: закройте pavucontrol, чтобы избавиться от записи с monitor source (а там по умолчанию стоит latency = 10 ms), и воспользуйтесь плеером, который не выставляет на своем потоке latency = 20 ms. Только тогда другой баг вылезет: mpv начнет отсчет времени с "-10 секунд". Причина этого бага тоже известна и будет обсуждаться с разработчиками вживую 15 октября.
Все универсальные элементы proplist'ов можно посмотреть в src/pulse/proplist.h (или онлайн тут: freedesktop.org/software/pulseaudio/doxygen/proplist_8h.html#details ). Только там много лишнего, и, например, на device.latency сам PulseAudio не реагирует (только сам ставит, когда захочет). Это в основном для информирования других приложений и для отладки.
ALSA-специфичные элементы можно посмотреть в src/modules/alsa/alsa-ucm.h — но это только для UCM, который работает только на мобильных платформах. Т.е. для десктопов и ноутбуков совсем нерелевантно.
А проблемы в ALSA такие (причем это только то, что задело лично меня):
1. Все кишки вынесены наружу в конфиг. В итоге по интернету разбрелось множество глупых конфигов. А авторам приложений ни на какие гарантии надеяться стало просто невозможно, т.к. pcm.default может быть чем угодно — в том числе голым hw без микширования, регулировки громкости и преобразования форматов.
2. Для микширования поверх HDMI или SPDIF приходится писать конфиг.
3. dmix работает только поверх устройств с очень специфичными требованиями: они должны (а) поддерживать mmap и (б) правильно работать, даже если приложение не уведомляет нижестоящие слои о том, куда именно в этот mmap оно записало. Т.е. без вызовов snd_pcm_mmap_begin() и snd_pcm_mmap_commit(). А такие устройства — это, по сути, только классические аппаратные PCI-карты (причем 6-канальная emu10k1 уже не является классической, т.к. физически состоит из трех стереокарт, к которым надо применять плугин multi, который уже не удовлетворяет второму требованию). И по той же причине никаких тебе bluetooth и софтовых многоканальных кодеков для spdif (P.S. я являюсь автором одного из двух таких кодеков) — т.е. смикшировать звук поверх 6-канального DTS-кодека для SPDIF средствами ALSA просто невозможно!
2. Потому что вообще в любом проекте разрушение уже сделанного — задача практически невыполнимая по политическим причинам. Это означает опровержение всех первоначальных доводов, ломку всей накопившейся пропаганды и переубеждение прозомбированных разработчиков.
3. Потому что патчи вида «обойти баг в другой библиотеке» не принимаются. А это именно баг в alsa-lib.
По поводу пункта 2 у меня план такой: убеждать их для разных случаев, что tsched и rewind неприменимы в данном конкретном случае. Почле достаточного количества итераций от них останется (утрирую) только один случай (воспроизведение одного источника без обработки на snd-hda-intel), который работает.
2. Леннарта там уже давно нет.
Прошу пересобрать и установить PulseAudio (ровно ту же версию, что в дистрибутиве, и с теми же патчами и опциями сборки) из исходников с одним изменением: в src/modules/alsa/alsa-util.c, надо заменить тело функции pa_alsa_pcm_is_hw() на «return false;». Тогда он вообще никогда не будет пытаться отматывать.
Кроме того, в /etc/pulse/daemon.conf прошу выставить:
default-fragments = 4
default-fragment-size-msec = 10
и отдельно еще попробовать, чтобы нагрузить процессор:
resample-method = speex-float-5
Если глюки не пропадут, то надо будет разбираться дальше. Только желательно не на хабре, а через почту или XMPP.
Ну и еще насчет вашей карты: там особо хитрый тип элемента управления «Master» (6 каналов вместо обычных одного или двух), который PulseAudio пока не поддерживает. Поэтому управление громкостью получается полностью софтовым и 16-битным, что тоже может давать слышимые искажения в особо тихой комнате. Это баг.
[весь текст ниже является пропагандой]
В цепочке plug:softvol:dmix размеры периода и буфера заданы жестко в конфиге, а приложение их как-либо поменять не может. Раз в период процессор должен проснуться. Соответственно, при настройках по умолчанию он должен проснуться 47 раз в секунду, даже если приложению такая отзывчивость (21 мс) не нужна. А не нужна она даже видеоплееру (там достаточно 33 мс). Лишние пробуждения процессора = лишний расход батарейки. Но в то же время такая схема с линейной записью в буфер и с фиксированным размером периода очень простая, и поэтому практически не имеет шансов нарваться на баги драйвера или оборудования. Все то же самое относится к JACK.
В случае с PulseAudio, прерывания от звуковой карты вообще выключены. Пробуждение процессора осуществляется по таймеру, частоту срабатывания которого (в отличие от частоты прерываний от звуковой карты) можно менять на лету. Поэтому от лишнего расхода батарейки, связанного с излишне высокой частотой пробуждений процессора, можно избавиться. А чтобы кукушку от ICQ вы слышали сразу, а не через пару секунд, приходится идти на такой трюк («динамическую задержку»): при появлении нового звука для микширования, необходимо записать новый смикшированный звук поверх уже отправленного для воспроизведения. Т.е. отмотать буфер назад с помощью функции snd_pcm_rewind(). Вот эта функция и является плохо отлаженной, и может при неправильной реализации приводить к глюкам при воспроизведении. К тому же известно несколько ситуаций, когда PulseAudio, за неимением правильной информации о состоянии буфера и ограничениях оборудования, пытается перемотать назад больше, чем можно.
Происхождение пшика при записи до конца не известно. У меня его нет, но у меня нет и скайпа. Улики до сих пор ни мне, ни в рассылку, никто не прислал. Если не пришлют в течение месяца — буду считать проблему выдуманной. См. также bugs.freedesktop.org/show_bug.cgi?id=83557 — если workaround в виде проигрывания тишины через module-echo-cancel помогает, то это оно (согласно этой теории, пшик в записанном появляется, когда Skype закрывает и переоткрывает свой поток проигрывания).
Сейчас у меня есть план, как функцию snd_pcm_rewind починить, а также дать PulseAudio правильную информацию о состоянии буфера и ограничениях оборудования. Я над этим работаю, но, к сожалению, натыкаюсь либо на непонимание, либо на неконструктивную (но справедливую) критику со стороны разработчиков ALSA. Подробности тут: comments.gmane.org/gmane.linux.alsa.devel/127246
ответ:пропаганда: они есть, просто вы их не замечаете, так как не с чем сравнивать.Edit: ответил не совсем в тему (т.к. сеть в этом баге ни при чем), но пусть будет.
P.S. Понимаю, что проблема на самом деле социальная (непонимание того, что перерасход батарейки мнимый, т.к. его в вашем и не только в вашем случае не избежать). Решать социальные проблемы не умею.
1. 1 секунду записи микрофонного шипения через PulseAudio (parec) в wav.
2. 1 секунду записи микрофонного шипения через ALSA (arecord) в wav. Обе записи должны быть с теми же параметрами касательно частоты дискретизации и числа каналов, как делает Skype. Подсмотреть можно в pacmd list-source-outputs.
3. Конфиг PulseAudio: /etc/pulse/*
4. Настройки ALSA-микшера как во время записи через ALSA, так и во время записи через PulseAudio: amixer -c0
5. Вывод pacmd list-sources
Основной кандидат в виновники шипения — это неоптимальное раскидывание усиления по ступеням в звуковой карте.
Еще есть маловероятная гипотеза, что это плохой ресемплер скидывает весь шум от микрофона в узкий диапазон, используемый для VoIP. Попробуйте заменить на speex-float-5 в /etc/pulse/daemon.conf.