Чувствительности в Windows хватает (там тоже добавлял чувствительности, не помню сколько, но ни намека на шум).
В Debian же в alsamixer для Rear Mic Boost увеличение громкости стоит на отметке в 22 единицы. Шум прямопропорционален чувствительности: если не слышно такого шума, то голоса тоже нет.
Увы, причина шума неизвестна. Шумит на основном ПК под управлением Debian 8, чуть меньше на ноутбуке с той же ОС. Пробовал звуковую USB-карту — тот же эффект. На винде все прекрасно.
Скайп первые секунд 5 тоже передает шум, а потом отсекает его до терпимого уровня.
Собственно, вот.
Если бы мои собеседники согласилишь слушать адские шумы, то я бы тоже слез прямо сейчас.
В пределах города у меня работало шустро. А вот когда я связываюсь через полстраны с человеком, у которого ростелеком паршивого качества — почти безальтернативный провайдер…
Шум — личная проблема, ни на одном из моих ПК мне так и не удалось настроить ни один дистрибутив линукса, чтобы не было очень громкого шума. На любой звуковой карте. С пульсом и без. Так вот, у меня только скайп умеет гасить этот шум.
Видимо, я недостаточно ясно описал задумку. Я имею в виду, что клиент, запущенный на ПК/сервере/где угодно выступал бы в роли сервера для мобильного клиента. Соответственно, нагрузка на телефон значительно снизилась бы.
В качестве аналогии: для использования XMPP мне не нужен установленный на телефоне XMPP-сервер.
Хотелось бы видеть в протоколе токса подобную функциональность.
Качество звука по сравнению со скайпом — ужас (скайп — единственная программа, которая корректно глушит эхо и шумы у меня на ПК). Качество видео — аналогично.
Синхронизации (как упомянули выше) и оффлайн сообщений нет. Мобильный клиент жрет уйму энергии (а можно было бы сделать так, чтобы он лишь подключался к запущенному, скажем, на ПК клиенту и через него общался).
И так далее, работы прорва, и будет ли когда-нибудь готово — не факт.
А Вы серьезно? Я без иронии спрашиваю. Закладки нельзя по-человечьи сортировать по алгоритму: сначала по алфавиту папки на латинице, затем на кириллице, затем цифры и прочие символы, затем закладки на латинице, кириллице и цифры-и-прочее.
Нельзя сделать автосортировку, чтобы в любой момент закладки были отсортированы по указанному правилу.
При поиске нельзя узнать даже через свойства закладки (!) в какой папке она находится.
И так далее.
Этой магии я не понимаю. Отображается в базе точно так же (смотрел через phpmyadmin), но сообщения из базы приходят корректно. Т.е. я (например) удаляю профиль Gajim'а, заново вбиваю учетные данные, и логи в корректном виде появляются в свежесозданном профиле.
> Лучше уж просто отправлять картинку в тексте исходящего сообщения, тогда все проблемы решаются автоматически.
Такая простая и эффективная идея мне в голову не пришла. Изначально да, была идея что в клиенте много смайлов таскать.
Только как ее реализовать? В том же Gajim'е картинка посылается только отдельным сообщением, посреди текста ее не вставишь. В psi, насколько я помню, тоже.
Вот (парсер ест ссылку):
https://trac.gajim.org/ticket/8123
После фикса все сообщения стали литься в БД.
Попробую другими словами про смайлы.
Сейчас, если смайлы включены, то вместо :) будет картинка. Это далеко не всегда удобно (например, если шлю код с встречающимся там :) )
Поэтому такой механизм преобразования предлагаю выключить. После сбора большой коллекции смайлов назначить каждому смайлу идентификатор подлиннее, например: «smile#kolobok-animated#smileROFL»
В идеальном мире все разработчики клиентов пишут плагин, который бы эти идентификаторы преобразовывал в картинки.
Теперь есть выбор:
1. По старинке печатать :) получая в итоге картинку. В этом случае неизвестно какая картинка будет отображена у собеседника, потому что у него другой смайл-пак.
2. :) так и остается двоеточием со скобкой, зато есть одинаковые у всех клиентов смайлы. Какой смайл отправил, тот (точно такой же) будет отображен у собеседника.
В данном случае разработчик утверждает, что XEP поддерживается, а по факту нет.
> In-band-файл — да
А разработчик Gajim уверяет что нет. Не спорю, просто как факт.
Про те слова, где вы разделяете протокол и реализацию: в каком-нибудь идеальном мире, может, я и стану рассматривать их отдельно.
По факту же стандарт так и остается недосягаемым идеалом уже много лет. На словах поддерживают все необходимые XEP'ы и ничего менять не собираются.
> А что там, в History++?
Слева даты, сгруппированные по годам, месяцам и дням (можно почти мгновенно перейти к нужной дате). Вся история полностью (с первого сообщения до последнего) справа. Экспорт в 5 форматов. Закладки.
Не знаю, смогу ли прикрепить скрин.
Скриншот
> Как вы определяете живость?
Насколько проект движется вперед. Прошлые года я это отслеживал: в psi и psi+ была активность в тикетах, но разработчики молчали. Нет новых версий, нет поддержки XEP'ов, без фикса багов.
Примерно та же картина была по другим клиентам.
Какой клиент вы разрабатываете? Я стал лишь изредка следить за новостями xmpp, мог упустить.
> Я тоже могу категорично послать, если
Я указал автору Gajim'а на некорректную работу с XEP-0313, он ответил что это не баг, и не слушая моих объяснений закрыл тикет как invalid.
С этим же тикетом я пришел к разработчиками ejabberd. Один из них зашел на багтрекер Gajim'а, все подробно расписал и указал место в коде где надо поправить. Только после этого баг поправили.
И такая дребедень… очень часто; руки опускаются репорты слать.
Предупреждая вопросы и отвечая на ваши призывы: деньгами не богат, питон только начал изучать.
> Ваш клиент не поддерживает стили сообщений?
Настраиваемо, но в очень небольших пределах.
> Я бы с интересом послушал про возможные варианты решения этой проблемы.
Примерный план (наивно, конечно, ждать такое):
0. Сделать настройку (в тех клиентах, где ее нет), чтобы обычно применяемые для смайлов символы не превращались в картинку.
А то код и ссылки слать жуть как неудобно. Выключишь интерпретацию — останешься без смайлов.
1. Собрать крупную базу смайлов из самых разных наборов.
2. Каждому смайлу назначить длинную комбинацию символов + назначить экранирующие символы, чтобы можно было послать идентификатор смайла и как текст.
3. *надеваю розовые очки*
Участники каждого проекта делают соответствующий плагин к своему клиенту.
4. Сделать соответствующий XEP (совсем нереально)
В итоге кто хочет — пользуется смайлами (какие нравятся!), кто не хочет — остается на традиционных рельсах замены двоеточия со скобкой на картинку.
А сейчас получается, что хочу я отправить собеседнику дружелюбного пони, а он у себя видит бездушного желтого колобка.
Не претендую на единственно верный подход, но подобные исправления я бы очень рад был видеть.
> Чем message delivery receipts нечеловеческие?
Привожу схему по памяти:
1. Алиса открывает клиент (Gajim, скажем), шлет Бобу соообщение. Появляется значок доставки сообщения.
2. У Боба в этот момент 2 клиента в онлайне, Gajim и Conversations, оба почти одновременно принимают сообщения. Боб отвечает Алисе из Gajim'а, затем закрывает Gajim
3. Алиса шлет сообщение Бобу. Conversations Боба принимает сообщение, но Алиса не получает подтверждение доставки.
> Тут чуть сложнее, да.
Неужели это настолько титаническая работа — сделать и реализовать соответствующий XEP?
Гарантированная доставка — краеугольный камень IM (по моему мнению, конечно).
> Этого замечания я не понял.
Мне бы хотелось иметь возможность выбрать как отправить файл:
— в потоке сообщений (когда файл бьется на куски, переводится в base64 и отправляется как сообщение)
— через прокси по XEP-0065
— через Jingle
и т.д.
Сейчас клиенты сами выбирают и случае если отправка не удалась совсем неясно, на каком этапе произошел затык и как это исправить.
> Вопрос клиента. OTR отображается в известных мне, например, PGP — тоже.
Шифруется ли передаваемый мной файл? Шифруются ли аудио- и видеозвонки? Шифруется ли моя переписка? (см. строкой ниже)
Кстати, у Gajim не OTR, а бутафория (тоже по памяти пишу):
1. Алиса и Боб шифруют переписку OTR
2. Боб дополнительно включает Conversations и с него отправляет Алисе незашифрованное сообщение
3. Теперь у Алисы будет отображаться что шифрование OTR включено, а по факту ее дальнейшие сообщения не зашифрованы.
> Message carbons.
Это одновременная доставка входящего сообщения на все устройства. Исходящие сообщения будут видны лишь на том устройстве, откуда были отправлены.
Настолько простая и элементарная, казалось бы, вещь, которой только ленивый мессенджер не пользуется, а у нас и не предвидится.
Например, в скайпе на всех устройствах отображается полная версия диалога.
> А расскажите ещё что-нибудь!
Чтобы два раза не вставать, расскажу немного про Conversations:
1. Нет истории в привычном понимании этого слова. Да, XEP-0313 якобы поддерживается, но где посмотреть сообщения из истории — неясно.
2. В случае если Conversations потерял связь с сервером, он может тихо и долго молчать, продолжая попытки подключения. Вполне так может целый день держаться (дольше не тестировал).
3. Нет возможности назначать собеседнику gpg-ключ. Остается лишь молится, что он сам угадает (а угадывает 1 раз из трех).
4. Это не интерфейс, а адский ад.
5. Разработчик весьма груб, послал меня в весьма категоричной манере. Еще добавил что клиент хороший и нечего тут вякать (скорее придирка, но до него реально не достучаться)
— Механизм транспортов слабоват. Например, для libpurple есть библиотека для связи с Telegram. В родном для libpurple Pidgin'е можно войти в конференцию, а если подключено в качестве транспорта — нельзя.
— Текущий XEP по шифрованию openpgp отменили, назвали, емнип, кривым и дырявым. Нового XEP'а нет. Что будет с логами (как локальными, так и на сервере) после ввода нового XEP'а — непонятно. Кстати, в базе mysql зашифрованные логи хранятся в очень странном режиме.
— После пробуждения ПК из сна Gajim далеко не всегда выходит в онлайн сам.
— Если в Gajim подключено более одной учетной записи и одна/несколько отвалились, иконка в трее этого не покажет. То же самое с транспортами. Отключился — и молчок. Также иконка у окна чата и в панели задач не зависит от того, в онлайне собеседник или нет.
— История сообщений в Gajim неюзабельна, найти что-нибудь сложно. Блекло, неинформативно. Близкую к идеалу историю видел лишь в миранде, плагин History++
— При отправке в Gajim картинки в чат, нужно ручками уменьшить файл до ~40 kb
— Оные картинки идут неприлично долгое время. Даже если оба клиента и сервер в локальной сети и нет шейпинга.
— В Gajim нельзя в произвольный момент самому создать группу контактов
— Нет возможности использовать разные закрытые ключи для разных контактов/групп контактов
— Разброд и шатание в поддерживаемых XEP'ах. Они или не все указаны, или фактически реализованы в версии, отличной от указанной в readme.
— По факту лишь 2 живых проекта — Gajim и Conversations. У обоих весьма закрытые и категоричные ведущие разработчики. Другие клиенты еле-еле шевелятся (в том же PSI нет Message carbons, МАМ и много чего еще)
— Невозможно (без правки исходного кода) существенно изменить стиль сообщений.
— Система работы со смайлами родом из нулевых. У разных людей могут быть разные паки смайлов, а одинаковые по коду смайлы часто сильно отличаются в передаваемой эмоции. Нельзя ли сделать что-то более универсальное?
В стане XMPP болото. Отсутствие IPv6 не мешает другим отраслям (например, по-человечески работающее подтверждение доставки сообщения, гарантированная доставка сообщения, выбор способа отправки файла, данные о шифровании соединения, одновременное отображение диалога на всех устройствах, и это только вершина).
Вплоть до того что использование Conversations (единственный живой клиент на андроид) — испытание на прочность нервов.
Эта новость, пожалуй, кошмарнее всего вышенаписанного. Ждем реактивного взлета цен на интернет и анекдотчиков.
В Debian же в alsamixer для Rear Mic Boost увеличение громкости стоит на отметке в 22 единицы. Шум прямопропорционален чувствительности: если не слышно такого шума, то голоса тоже нет.
https://drive.google.com/file/d/0B1nelwS0wp5JNEVqX2o2T1l5SFk/view?usp=sharing
Тем не менее, Windows 7 такие проблемы оказались по плечу.
Скайп первые секунд 5 тоже передает шум, а потом отсекает его до терпимого уровня.
Собственно, вот.
В пределах города у меня работало шустро. А вот когда я связываюсь через полстраны с человеком, у которого ростелеком паршивого качества — почти безальтернативный провайдер…
Шум — личная проблема, ни на одном из моих ПК мне так и не удалось настроить ни один дистрибутив линукса, чтобы не было очень громкого шума. На любой звуковой карте. С пульсом и без. Так вот, у меня только скайп умеет гасить этот шум.
В качестве аналогии: для использования XMPP мне не нужен установленный на телефоне XMPP-сервер.
Хотелось бы видеть в протоколе токса подобную функциональность.
Синхронизации (как упомянули выше) и оффлайн сообщений нет. Мобильный клиент жрет уйму энергии (а можно было бы сделать так, чтобы он лишь подключался к запущенному, скажем, на ПК клиенту и через него общался).
И так далее, работы прорва, и будет ли когда-нибудь готово — не факт.
А Вы серьезно? Я без иронии спрашиваю. Закладки нельзя по-человечьи сортировать по алгоритму: сначала по алфавиту папки на латинице, затем на кириллице, затем цифры и прочие символы, затем закладки на латинице, кириллице и цифры-и-прочее.
Нельзя сделать автосортировку, чтобы в любой момент закладки были отсортированы по указанному правилу.
При поиске нельзя узнать даже через свойства закладки (!) в какой папке она находится.
И так далее.
И врачи бессильны.
Этой магии я не понимаю. Отображается в базе точно так же (смотрел через phpmyadmin), но сообщения из базы приходят корректно. Т.е. я (например) удаляю профиль Gajim'а, заново вбиваю учетные данные, и логи в корректном виде появляются в свежесозданном профиле.
> Лучше уж просто отправлять картинку в тексте исходящего сообщения, тогда все проблемы решаются автоматически.
Такая простая и эффективная идея мне в голову не пришла. Изначально да, была идея что в клиенте много смайлов таскать.
Только как ее реализовать? В том же Gajim'е картинка посылается только отдельным сообщением, посреди текста ее не вставишь. В psi, насколько я помню, тоже.
Вот (парсер ест ссылку):
https://trac.gajim.org/ticket/8123
После фикса все сообщения стали литься в БД.
Попробую другими словами про смайлы.
Сейчас, если смайлы включены, то вместо :) будет картинка. Это далеко не всегда удобно (например, если шлю код с встречающимся там :) )
Поэтому такой механизм преобразования предлагаю выключить. После сбора большой коллекции смайлов назначить каждому смайлу идентификатор подлиннее, например: «smile#kolobok-animated#smileROFL»
В идеальном мире все разработчики клиентов пишут плагин, который бы эти идентификаторы преобразовывал в картинки.
Теперь есть выбор:
1. По старинке печатать :) получая в итоге картинку. В этом случае неизвестно какая картинка будет отображена у собеседника, потому что у него другой смайл-пак.
2. :) так и остается двоеточием со скобкой, зато есть одинаковые у всех клиентов смайлы. Какой смайл отправил, тот (точно такой же) будет отображен у собеседника.
В данном случае разработчик утверждает, что XEP поддерживается, а по факту нет.
> In-band-файл — да
А разработчик Gajim уверяет что нет. Не спорю, просто как факт.
Про те слова, где вы разделяете протокол и реализацию: в каком-нибудь идеальном мире, может, я и стану рассматривать их отдельно.
По факту же стандарт так и остается недосягаемым идеалом уже много лет. На словах поддерживают все необходимые XEP'ы и ничего менять не собираются.
> А что там, в History++?
Слева даты, сгруппированные по годам, месяцам и дням (можно почти мгновенно перейти к нужной дате). Вся история полностью (с первого сообщения до последнего) справа. Экспорт в 5 форматов. Закладки.
Не знаю, смогу ли прикрепить скрин.
> Как вы определяете живость?
Насколько проект движется вперед. Прошлые года я это отслеживал: в psi и psi+ была активность в тикетах, но разработчики молчали. Нет новых версий, нет поддержки XEP'ов, без фикса багов.
Примерно та же картина была по другим клиентам.
Какой клиент вы разрабатываете? Я стал лишь изредка следить за новостями xmpp, мог упустить.
> Я тоже могу категорично послать, если
Я указал автору Gajim'а на некорректную работу с XEP-0313, он ответил что это не баг, и не слушая моих объяснений закрыл тикет как invalid.
С этим же тикетом я пришел к разработчиками ejabberd. Один из них зашел на багтрекер Gajim'а, все подробно расписал и указал место в коде где надо поправить. Только после этого баг поправили.
И такая дребедень… очень часто; руки опускаются репорты слать.
Предупреждая вопросы и отвечая на ваши призывы: деньгами не богат, питон только начал изучать.
> Ваш клиент не поддерживает стили сообщений?
Настраиваемо, но в очень небольших пределах.
> Я бы с интересом послушал про возможные варианты решения этой проблемы.
Примерный план (наивно, конечно, ждать такое):
0. Сделать настройку (в тех клиентах, где ее нет), чтобы обычно применяемые для смайлов символы не превращались в картинку.
А то код и ссылки слать жуть как неудобно. Выключишь интерпретацию — останешься без смайлов.
1. Собрать крупную базу смайлов из самых разных наборов.
2. Каждому смайлу назначить длинную комбинацию символов + назначить экранирующие символы, чтобы можно было послать идентификатор смайла и как текст.
3. *надеваю розовые очки*
Участники каждого проекта делают соответствующий плагин к своему клиенту.
4. Сделать соответствующий XEP (совсем нереально)
В итоге кто хочет — пользуется смайлами (какие нравятся!), кто не хочет — остается на традиционных рельсах замены двоеточия со скобкой на картинку.
А сейчас получается, что хочу я отправить собеседнику дружелюбного пони, а он у себя видит бездушного желтого колобка.
> Чем message delivery receipts нечеловеческие?
Привожу схему по памяти:
1. Алиса открывает клиент (Gajim, скажем), шлет Бобу соообщение. Появляется значок доставки сообщения.
2. У Боба в этот момент 2 клиента в онлайне, Gajim и Conversations, оба почти одновременно принимают сообщения. Боб отвечает Алисе из Gajim'а, затем закрывает Gajim
3. Алиса шлет сообщение Бобу. Conversations Боба принимает сообщение, но Алиса не получает подтверждение доставки.
> Тут чуть сложнее, да.
Неужели это настолько титаническая работа — сделать и реализовать соответствующий XEP?
Гарантированная доставка — краеугольный камень IM (по моему мнению, конечно).
> Этого замечания я не понял.
Мне бы хотелось иметь возможность выбрать как отправить файл:
— в потоке сообщений (когда файл бьется на куски, переводится в base64 и отправляется как сообщение)
— через прокси по XEP-0065
— через Jingle
и т.д.
Сейчас клиенты сами выбирают и случае если отправка не удалась совсем неясно, на каком этапе произошел затык и как это исправить.
> Вопрос клиента. OTR отображается в известных мне, например, PGP — тоже.
Шифруется ли передаваемый мной файл? Шифруются ли аудио- и видеозвонки? Шифруется ли моя переписка? (см. строкой ниже)
Кстати, у Gajim не OTR, а бутафория (тоже по памяти пишу):
1. Алиса и Боб шифруют переписку OTR
2. Боб дополнительно включает Conversations и с него отправляет Алисе незашифрованное сообщение
3. Теперь у Алисы будет отображаться что шифрование OTR включено, а по факту ее дальнейшие сообщения не зашифрованы.
> Message carbons.
Это одновременная доставка входящего сообщения на все устройства. Исходящие сообщения будут видны лишь на том устройстве, откуда были отправлены.
Настолько простая и элементарная, казалось бы, вещь, которой только ленивый мессенджер не пользуется, а у нас и не предвидится.
Например, в скайпе на всех устройствах отображается полная версия диалога.
> А расскажите ещё что-нибудь!
Чтобы два раза не вставать, расскажу немного про Conversations:
1. Нет истории в привычном понимании этого слова. Да, XEP-0313 якобы поддерживается, но где посмотреть сообщения из истории — неясно.
2. В случае если Conversations потерял связь с сервером, он может тихо и долго молчать, продолжая попытки подключения. Вполне так может целый день держаться (дольше не тестировал).
3. Нет возможности назначать собеседнику gpg-ключ. Остается лишь молится, что он сам угадает (а угадывает 1 раз из трех).
4. Это не интерфейс, а адский ад.
5. Разработчик весьма груб, послал меня в весьма категоричной манере. Еще добавил что клиент хороший и нечего тут вякать (скорее придирка, но до него реально не достучаться)
— Механизм транспортов слабоват. Например, для libpurple есть библиотека для связи с Telegram. В родном для libpurple Pidgin'е можно войти в конференцию, а если подключено в качестве транспорта — нельзя.
— Текущий XEP по шифрованию openpgp отменили, назвали, емнип, кривым и дырявым. Нового XEP'а нет. Что будет с логами (как локальными, так и на сервере) после ввода нового XEP'а — непонятно. Кстати, в базе mysql зашифрованные логи хранятся в очень странном режиме.
— После пробуждения ПК из сна Gajim далеко не всегда выходит в онлайн сам.
— Если в Gajim подключено более одной учетной записи и одна/несколько отвалились, иконка в трее этого не покажет. То же самое с транспортами. Отключился — и молчок. Также иконка у окна чата и в панели задач не зависит от того, в онлайне собеседник или нет.
— История сообщений в Gajim неюзабельна, найти что-нибудь сложно. Блекло, неинформативно. Близкую к идеалу историю видел лишь в миранде, плагин History++
— При отправке в Gajim картинки в чат, нужно ручками уменьшить файл до ~40 kb
— Оные картинки идут неприлично долгое время. Даже если оба клиента и сервер в локальной сети и нет шейпинга.
— В Gajim нельзя в произвольный момент самому создать группу контактов
— Нет возможности использовать разные закрытые ключи для разных контактов/групп контактов
— Разброд и шатание в поддерживаемых XEP'ах. Они или не все указаны, или фактически реализованы в версии, отличной от указанной в readme.
— По факту лишь 2 живых проекта — Gajim и Conversations. У обоих весьма закрытые и категоричные ведущие разработчики. Другие клиенты еле-еле шевелятся (в том же PSI нет Message carbons, МАМ и много чего еще)
— Невозможно (без правки исходного кода) существенно изменить стиль сообщений.
— Система работы со смайлами родом из нулевых. У разных людей могут быть разные паки смайлов, а одинаковые по коду смайлы часто сильно отличаются в передаваемой эмоции. Нельзя ли сделать что-то более универсальное?
Вплоть до того что использование Conversations (единственный живой клиент на андроид) — испытание на прочность нервов.