Comments 20
Вот так: while True: pass никогда не следует даже пытаться писать! Вариант while True: sleep(10) чуть по-лучше, но все еще странный.
Если нужно уснуть навсегда (до прерывания с клавиатуры или завершения процесса) — подойдет вот такой вариант (источник: https://stackoverflow.com/a/48631852):
from threading import Event
Event().wait()
Насчет нажатия программно комбинаций клавиш. Сам использовал pywin32 модуль, а потом как-то попался модуль keyboard. Вроде проще и довольно удобный. Не знаю может есть какие-то недостатки в работе, мне пока не попадалось вроде.
def toggle_play():
win32api.keybd_event(VK_MEDIA_PLAY_PAUSE, 0, 0, 0)
Должно быть примерно так.
def toggle_play():
win32api.keybd_event(VK_MEDIA_PLAY_PAUSE, 0, 0, 0)
win32api.keybd_event(VK_MEDIA_PLAY_PAUSE, 0, win32con.KEYEVENTF_KEYUP, 0)
У меня переходника нет, пробовал вставлять две гарнитуры в разъём микрофона. Та, которая от Nokia и не работает на моём устройстве Android, смогла передать сигнал при нажатии, хотя записи звука нет. Регистрация нажатия срабатывала через раз, увеличил SAMPLE_RATE на 2 и стало нормально.
У меня в 4-х летнем ноутбуке есть разъем с поддержкой гарнитуры. Только мне пока не удалось найти гарнитуру, которая к нему бы подходила (специально не искал, но телефонная не работает — звук не пишется).
Звука в нокиевской гарнитуре нет из-за разных стандартов джека (OMTP и CTIA), по делу разница стандартов лишь в поменянных местами контактах GND и Mic. Я думаю, возьмёте любые другие наушники, стандарт у почти всех кроме нокии CTIA, и все будет хорошо.
Интуитивно по спецификации я бы предположил, что сигнал подскочит до 1 и останется там, пока кнопку не отпустить, но в реальности выглядит иначе.
Зная устройство микрофонного входа я бы такое не предположил бы никогда. Для работы микрофона на входе поддерживается некоторая постоянная составляющая — по сути источник тока с ограниченным напряжением в +3В примерно. Уровень напряжения «нуля»(в пределах 1..2В) при подключенном микрофоне будет зависеть от самого микрофона, разброса параметров микрофона и т.д. чтобы с этим не парится по входу стоит ВЧ-фильтр на 2-10Гц(на дешёвых карточках может быть и выше граница) в виде конденсатора, что в итоге даёт наблюдаемую картину.
И я бы в условие срабатывания включил бы проверку крутизны фронтов этого импульса, с вашей проверкой могут быть ложные срабатывания просто от громкого звука(микрофоны гарнитуры бывают довольно чувствительны и болтаются где ни попадя). Поэтому нужна полноценная частота семплирования и простейшая обработка сигнала.
С Bluetooth наушниками ничего такого нельзя сделать? У меня кнопки на наушниках (play/pause, next, previous) работают только в UWP приложениях и в iTunes.
Может как-то можно обойти, чтобы вызывалось срабатывание обычных медиаклавиш клавиатуры?
Сам, правда, отказался от прослушивания музыки с ПК в пользу смартфона. Первый слишком прожорлив для этой задачи в плане энергопотребления.
Просто есть же джойстики для магнитол.
Надо расковыривать, наблюдать осциллографом на живой магнитоле и потом делать выводы.
Но технически, можно разобрать выкинуть всю начинку оттуда и сделать как в гарнитуре — на простых резисторах. Правда, с энкодерами могут быть проблемы — сложно будет отличать направление вращения. Ну и соответственно миниджек надо 4-х контактный. Короче, «каша из топора» получается.
Хак для поддержки кнопок Android-гарнитуры под Windows