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

Изучив некоторые интернет-материалы и ассортимент, сложилось впечатление, что такие наушники либо невозможны из-за физических ограничений, так как, насколько я понимаю, для разных частот нужны разные динамики и резонаторные камеры, либо такие вполне себе существуют, отвечают всем требованиям, маленькие-красивые, но цена одной пары в десять раз больше годового бюджета РФ.

Основной причиной поиска служит то, что мне надоели полноразмерные наушники: давят на голову, даже если подвижные амбушуры (с неподвижными вообще ужас), портят причёску и волосы, а ещё почти всегда делаются с каким-нибудь дишманским кожзамом, который быстро отслаивается и ищи потом его кусочки на голове, за ушами и на шее.

Удалось найти только такие, но они либо выглядят отстойно, либо провода у них это нитки или углеродные нано-трубки, при чём один провод короче другого, чтобы возле подбородка висела какая-то фигня и бесила, либо очень много подделок на эти наушники, либо они портятся за пару недель: • Moondrop Quarks • Sennheiser CX 300-II Precission Ещё не довелось купить и попробовать их, потому что боюсь потратить деньги на фигню.

Вообще, никогда не доводилось использовать современные внутриканальные наушники, поэтому мало понимания, какого они сейчас качества. Доводилось покупать только в десятых годах, и они были такие себе: многим требовался разогрев в пару дней, быстро выходил из строя провод (думаю, все помнят ситуацию «поверни на нужную долю градуса чтобы услышать хоть что-то»).

По интернету ходят легенды про некие проводные затычки от Эппл, и те, кто видели цену на них - теряли рассудок.

Беспроводные наушники дают сильную задержку, она компенсируется только в медиаплеерах, и то не всех, в игры играть невозможно. Радиоканал получше, но только если есть хорошее шифрование, такие наверное вообще никто не делает. Так что ищу проводные.

Есть у кого-нибудь опыт по поиску и использованию современных внутриканальных наушников? Какие можно посоветовать, попадающие под такие критерии? Или идеальные ещё не скоро изобретут?

Перемещено dataman из linux-hardware

Кажется, в X11 с чувствительностью мыши происходит какая-то неразбериха, каждый понимает под разными понятиями что-то своё.

Вот что я понимаю, надеюсь что правильно:

• DPI - Количество опросов сенсора мыши за единицу времени
• Чувствительность - насколько каждый опрос влияет на положение курсора
• Ускорение - дополнительное движение курсора в зависимости от скорости движения мыши по всяким сложным моделям

Мне нужна очень высокая точность, поэтому «ускорение» (согласно вышеуказанной терминологии) было вырублено под корень, потому что нафиг не надо, мне нужна высокая точность, а не ощущение, что с моей мышкой что-то не так.

На моей мышке есть 4 режима DPI:

• Очень мало опросов в секунду (сотня от силы)
• Среднее количество опросов в секунду
• Много опросов в секунду
• Дофига опросов в секунду

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

Но это малое количество опросов сенсора мыши очень больно чувствуется: я могу двигать мышь на доли миллиметров (для меня вполне ощутимое расстояние), и курсор не двигается вообще.
Он двигается очень дёрганно.
Я прямо вижу, насколько «блочно» курсор двигается.
Я двигаю мышь, а курсор будто бы snap’ится к определённым точкам.
Это происходит из-за малого количества опросов сенсора мыши.

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

Очевидное решение - повысить частоту опроса сенсора мыши (DPI) до максимума, чтобы использовать свою мышь по-полной (деньги же не за 10 опросов в час уплачены) а чувствительность мыши в игре (напоминаю мою терминологию, чувствительность - это то, насколько сильно влияет движение сенсора на курсор) установить что-то типа 0.001. Ещё желательно включить «прямое подключение к мыши» если это игра на движке Source.

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

Но стоит открыть меню или свернуть игру - как мышь начинает нарушать законы физики и метаться от одного края экрана до другого за доли секунд.

Очевидное решение - уменьшить чувствительность мыши (не забываем терминологию) в X11.
А вот фиг.
На все поиски в интернете, поисковики предлагают абсолютно рандомные решения, зачастую это работа с «ускорением» (не забываем терминологию), которое просто не совместимо с понятием «точность», потому что делает скорость курсора нелинейной.

Решения по типу изменить параметр «Device Accel Constant Deceleration» неактуальны уже как много лет, либо с моей мышью что-то не так (Logitech G102). И звучит как-то очень сложно.

Уменьшить «чувствительность мыши» помогает только одно решение:

$ xinput set-prop "моя-мышь" "Coordinate Transformation Matrix"    $sensivity 0 0    0 $sensivity 0     0 0 1

И по-началу кажется, что вот оно - решение.
Вот только это напрочь ломает захват мыши в программах по-типу Blender или даже на сайте по проверке DPI: https://mousedpianalyzer.com

Захват мыши сначала работает, но стоит отпустить ПКМ - как курсор отправляется в левый верхний угол.
А если чувствительность мыши наоборот увеличена - то в правый нижний угол.

И тут я не знаю что делать. Хочу просто спросить вас, кто шарит, что можно сделать.

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

Либо, это нерешаемая проблема, потому что когда программы пытаются захватить курсор - они считывают чуть ли не аппаратно информацию с сенсора, в обход установленного параметра «Coordinate Transformation Matrix». И я понять не могу - за это какая-то кривая библиотека отвечает, или все разработчики в мире разом забыли, что существует понятие «чувствительность мыши»?

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

Перемещено hobbit из general

Я запускаю FL Studio в такой комбинации: В среде Firejail запускается Wine-GE, который запускает FL Studio.

Раньше всё было отлично, но после обновления FL перестала запускаться по следующей причине:

X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  130 (MIT-SHM)
  Minor opcode of failed request:  3 (X_ShmPutImage)
  Value in failed request:  0x150
  Serial number of failed request:  1302
  Current serial number in output stream:  1305

FL Studio на долю секунды открывается, видно фрукт, но затем работа FL прекращается.

Система: Arch Linux, NVidia RTX 3070, OpenBox

В комбинации Firejail -> Lutris ровно та же самая проблема, при чём другие игры и программы работают отлично, и FL после десятков попыток запустить, бывает, запускается, и работает отлично, но после перезагрузки снова не работает по той же самой причине.

Я правильно понимаю, что проблема связана с распределяемой памятью, и Firejail не настроен на работу с ней? Как его настроить? Никакой информации в интернете найти не удалось, только о MIT-SHM - что это «расширение X Window System для обмена видеоданными между клиентом и сервером с использованием общего поля памяти».

Может, нужно поставить какую-то библиотеку или утилиту для работы с этой фигнёй, или проблема с графической оболочкой или настройкой X сервера?

Не помогают флаги для Firejail:

• –ipc-namespace
• –caps
• –seccomp

Не помог xorg-server-xephyr, ровно та же самая проблема.

Единственные ошибки которые так же выводятся:

• 009c:err:hid:udev_bus_init UDEV monitor creation failed

Может, стоит сделать полный вывод логов, и пытаться разобраться в этих гигабайтах текста что что-то не так?

Прошу не писать комментарии по типу «не используй экранирование системы, доверяй все свои файлы проприетарному ПО» или «используй виртуальную машину»

Для своего проекта мне нужно реализовать передачу данных по протоколу TCP. Моих знаний и опыта хватило для примитивного сервера на Python:

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

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

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

• Программа создаёт сокет
• Настраивает сокет
• Биндит сокет на порт
• Когда приходит запрос или ответ на запрос - операционная система записывает данные в некий «буфер входящих пакетов»
• Программа читает часть «буфера входящих пакетов»

И если это действительно так - то я хочу добиться асинхронности за счёт «««редкого считывания»»» буфера. То есть программа будет делать другие дела помимо ожидания ответа, например - работа с интерфейсом (а то программа, которая пошлёт пакет и будет рисовать интерфейс одновременно - тупо зависнет, а параллельность не везде возможна), или послать ещё запрос, а потом ещё и ещё, хотя ответ на первый запрос ещё не пришёл.

Да, в Python существуют библиотеки для асинхронной работы, но асинхронность в высоких языках я воспринимаю как мега-ужасный костыль - она быстро превращает проект в мега-сложную и сверх-запутанную структуру с огромным количеством абстракций и систем защиты от «гонок». Любой проект превращается из простого «сделать это а потом то» в «держать абстрактный класс с содержанием других классов, наследующих от других классов другие классы», и для моего не самого гениального мозга это воспринимается как мусор, в котором абстрактность на абстрактности, и абстрактность абстрактностью погоняет.

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

Почему не хочу использовать многопоточность?

1. Мой проект должен работать на любом тостере, на любом самоваре, а значит - многопоточности может и не оказаться.
2. Я считаю многопоточность огромным усложнением проекта - в нём сразу возникнет куча проблем с «гонками», семафорами и безопасностью.
3. Многопоточность ускорит работу сети в 2-24 раза, а грамотная асинхронность - в сотни тысяч раз, если не в миллионы или миллиарды.

Почему не async из Python? Потому что это костыль е_аный, а не асинхронность.

Я хочу использовать HTTP, и пока не знаю, как мне подружить его с такой «буферной асинхронностью», если она будет реализована самостоятельно. Поэтому было бы неплохо достичь «адекватной с моей точки зрения» асинхронности в Python. Может, написать библиотеку, которая даёт доступ и функции для работы с «буфером входящих пакетов», может даже в виде простого Python списка. Нет, я не буду писать свой проект полностью на Си - боюсь, что каждый самостоятельно написанный парсер не будет учитывать миллионы давно открытых уязвимостей, и в итоге мой проект будет решетом. Тут я не против абстракций, когда дело касается безопасности.

Плохой новостью для меня окажется, если просто поглядывать в буфер раз в 1/4 секунды - не выйдет, по причинам типа:

• Accept переводит процесс в состояние «заблокировано», пока не будет установлено соединение
• Listen переводит процесс в состояние «заблокировано», пока не придёт новый пакет

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

В общем и целом - помогите разобраться в самоучке.

Покидайте полезных статей с примерами, пожалуйста, я сейчас нахожу только воду и статьи, сгенерированные нейросетями, аля «чтобы добиться асинхронного TCP соединения на Python…» и дальше какой-то абстрактный код, который потом превращается в Java, а затем в рецепт салата Цезарь из резиновых покрышек.

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

Хочу добиться своего на Си или Python.

Спасибо заранее ^~^