Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 39
Я правильно понял что снимать нужно видеокамерой, а звук чтобы писался с телефона?
Что мешает включить запись на видеокамере и запись звука на телефоне и снимать ролик?
Что мешает включить запись на видеокамере и запись звука на телефоне и снимать ролик?
Не, тут речь о дубляже видео (я переозвучивал несколько видео на русский язык). Видео дорожку я вообще не трогаю. Все эти затеи лишь для того, чтобы не приходилось переносить с телефона аудио файлы, а чтобы они сразу оказывались на компьютере.
Вы не искали реализаций своих идей?
Например: передача звука с микрофона через джек-джек кабель или через клиент-сервер
Например: передача звука с микрофона через джек-джек кабель или через клиент-сервер
Читаем статью внимательней, я упоминал про WoMic. У нас речь о Linux, так что он не подходит.
Приложение «Микрофон» я тоже видел, оно не умеет менять громкость, поэтому я говорил о Mic To Speaker.
Приложение «Микрофон» я тоже видел, оно не умеет менять громкость, поэтому я говорил о Mic To Speaker.
Если речь о Linux, то вам нужно реализовать Simple-протокол PulseAudio в приложении, которое захватывало бы микрофон. Пример программы наоборот: Simple Protocol Player, я с его помощью фильмы запускаю на компьютере, а звук получаю в наушники, которые подключены к телефону, а телефон подключен к домашнему Wi-Fi.
По поводу второй идеи — а почему не воткнуть аудио выход смартфона в аудиовход компа? Зачем делать аттенюатор и тыкаться в lineIn?
Есть еще идея просто воткнуть наушники в качестве микрофона прямо в lineIn компа.
Но все этот разве что на особо крайние случаи, ибо быстрее будет добежать до ближайшего магазинчика и купить микрофончик. Ну а если озвучивать видео постоянно, то не иметь микрофона мне кажется не совсем хорошо ;-)
Есть еще идея просто воткнуть наушники в качестве микрофона прямо в lineIn компа.
Но все этот разве что на особо крайние случаи, ибо быстрее будет добежать до ближайшего магазинчика и купить микрофончик. Ну а если озвучивать видео постоянно, то не иметь микрофона мне кажется не совсем хорошо ;-)
По поводу второй идеи — а почему не воткнуть аудио выход смартфона в аудиовход компа? Зачем делать аттенюатор и тыкаться в lineIn?
Так я так и предлагаю. Аттенюатор понадобится, поскольку из смартфона идёт line level, а в ноутбук должен прийти mic level.
Есть еще идея просто воткнуть наушники в качестве микрофона прямо вlineInmic in компа. Но все это разве что на особо крайние случаи, ибо быстрее будет добежать до ближайшего магазинчика и купить микрофончик.
Спасибо за дополнительную идею. Но, соглашусь, она для крайнего случая. Хотя, мало ли какие ситуации могут быть… Добавлю в статью.
Ну а если озвучивать видео постоянно, то не иметь микрофона мне кажется не совсем хорошо ;-)
У меня уже есть петличка, которая даёт хорошее качество. Хотел просто поделиться идеями, многим может пригодиться.
Я похоже не увидел что в вашем ноутбуке нет линейного входа(в чем я правда сомневаюсь). Просто линейку в линейку по идее нужно втыкать без аттенюации, сигналы там сопоставимые по уровню.
Еще раз повторюсь: аудиовыход смартфона в линейный вход компа.
Еще раз повторюсь: аудиовыход смартфона в линейный вход компа.
А почему в ноутбук должен приходить именно mic level?
Так а где сейчас ноутбуки с line in? Такие вообще в природе бывают?
Раньше были отдельные гнёзда для наушников (зелёное) и микрофона (розовое). Сейчас чаще делают комбо разъём с четырьмя контактами. Он объединяет в себе выход на наушники и вход микрофона.
А line in гнездо я видел только на десктопах. Оно обозначено голубым цветом.
Раньше были отдельные гнёзда для наушников (зелёное) и микрофона (розовое). Сейчас чаще делают комбо разъём с четырьмя контактами. Он объединяет в себе выход на наушники и вход микрофона.
А line in гнездо я видел только на десктопах. Оно обозначено голубым цветом.
Картинка из гугла
Ну, даже на десктопах, где не нужно сильно экономить на дырках, есть возможность втыкать разные устройства в один и тот же разъем — система просто спрашивает, что именно воткнули. Так что я весьма удивлен, что такую простую вещь не делают на современных ноутах.
На самом деле, я сильно подозреваю, что воткнуть line-level в микрофонный вход можно и оно будет нормально работать.
На самом деле, я сильно подозреваю, что воткнуть line-level в микрофонный вход можно и оно будет нормально работать.
даже на десктопах, где не нужно сильно экономить на дырках, есть возможность втыкать разные устройства в один и тот же разъем — система просто спрашивает, что именно воткнули.
Если я не ошибаюсь, так можно было делать только на некоторых реалтеках на десктопах. Вы могли конфигурять практически любой джек как вам угодно.
скриншот
Не могу сказать, была ли такая возможность на лэптопах. Например, у моего такой возможности нет даже под win. Соответственно, я думаю, что это аппаратное ограничение, поэтому я даже не выяснял, бывает ли такое под линукс.
На самом деле, я сильно подозреваю, что воткнуть line-level в микрофонный вход можно и оно будет нормально работать.
Вы ошибаетесь. Так сделать не получится. Line уровень намного выше микрофонного. Если вы воткнёте штекер с такой напругой в мик гнездо, то в лучшем случае вы получите полное зашкаливание, в хучшем — спалите приёмник.
Чтобы воткнуть line в mic, нужен либо аттенюатор, либо аппаратная поддержка этой возможности звуковухой.
Кстати не, мне кажется вариант с подключением наушника в микрофонный вход всё же к нам не относится. Если вы оказались на необитаемом острове и нашли разбитый корабль, тогда может быть такой «микрофон» вас спасёт. Но мы тут говорим об озвучке. И уж явно даже у внутреннего мика ноутбука звук будет не хуже.
> Какой из всех предложенных вариантов обеспечит наименьшие задержки при передаче?
Так вам нужна минимальная задержка или качество звука? Задержка при записи аудиодорожки не имеет значения, главное чтобы она не плавала, а компенсировать ее можно сдвинув аудиодорожку в редакторе.
Самым оптимальным вижу способ передачи данных по сети (WiFi) скорости которой хватит за глаза на передачу не сжатого аудио. Варианты в качестве BT-гарнитуры могут не устроить качеством пережатого аудио, вариант в качестве аудиокарты мне кажется будет сложным.
Я понимаю, что это все делается «за идею», но для озвучивания дубляжа может все-таки лучше раскошелиться на качественный микрофон?
Так вам нужна минимальная задержка или качество звука? Задержка при записи аудиодорожки не имеет значения, главное чтобы она не плавала, а компенсировать ее можно сдвинув аудиодорожку в редакторе.
Самым оптимальным вижу способ передачи данных по сети (WiFi) скорости которой хватит за глаза на передачу не сжатого аудио. Варианты в качестве BT-гарнитуры могут не устроить качеством пережатого аудио, вариант в качестве аудиокарты мне кажется будет сложным.
Я понимаю, что это все делается «за идею», но для озвучивания дубляжа может все-таки лучше раскошелиться на качественный микрофон?
Так вам нужна минимальная задержка или качество звука? Задержка при записи аудиодорожки не имеет значения
Мне кажется, что качество от задержки не зависит. Задержка не важна, если просто озвучивать написанный текст, например для своего видео туториала. А для дубляжа ещё как важна…
Я понимаю, что это все делается «за идею», но для озвучивания дубляжа может все-таки лучше раскошелиться на качественный микрофон?
Конечно, лучше. Но не всегда есть возможность. Эти идеи помогут хоть как то выйти из положения.
> Задержка не важна, если просто озвучивать написанный текст, например для своего видео туториала. А для дубляжа ещё как важна
Я специально добавил «главное чтобы она не плавала, а компенсировать ее можно сдвинув аудиодорожку в редакторе». Да и вы же не в реалтайме это все делаете, а записываете в редактор, где потом в любом случае подправляете все огрехи.
Я специально добавил «главное чтобы она не плавала, а компенсировать ее можно сдвинув аудиодорожку в редакторе». Да и вы же не в реалтайме это все делаете, а записываете в редактор, где потом в любом случае подправляете все огрехи.
Ну, я не знаю, называется ли это реал таймом, но я озвучиваю именно глядя на видео и видя субтитры, которые появляются именно тогда, когда нужно. Как я к этому подготавливаюсь я хотел рассказать отдельно в будущем.
Очень бесит, если нужно исправить буквально несколько слов. Нужно выждать ~2 сек, когда звук уже начнёт доходить, после чего только говорить. А нельзя просто так нажать на запись и сразу говорить. Ну, это по собственным ощущениям нужно понять… На словах может выглядит смешно, но реально мешает.
Очень бесит, если нужно исправить буквально несколько слов. Нужно выждать ~2 сек, когда звук уже начнёт доходить, после чего только говорить. А нельзя просто так нажать на запись и сразу говорить. Ну, это по собственным ощущениям нужно понять… На словах может выглядит смешно, но реально мешает.
(WiFi
ага, потерянный пакет внесет не известно где рассинхрон, лови его потом, а он будет не один.
Я предлагаю вариант.
1) На комп установить google drive
2) на телефон установить google drive
3) засинхронизировать папку с аудио через wifi
Теперь делаем следующее: Включаем на компьютере оригинальный видео ролик без звука, на телефоне включаем запись звука. Комментируем все происходящее на видео в микрофон телефона, после чего берем аудио дорожку из папки google drive на компьютере.
Плюсы:
Не надо писать драйвера, можно потратить время на что нибудь полезное, например на семью или девушку.
Минусы:
Решение доступно любому школьнику, нечем поправить свое самолюбие
1) На комп установить google drive
2) на телефон установить google drive
3) засинхронизировать папку с аудио через wifi
Теперь делаем следующее: Включаем на компьютере оригинальный видео ролик без звука, на телефоне включаем запись звука. Комментируем все происходящее на видео в микрофон телефона, после чего берем аудио дорожку из папки google drive на компьютере.
Плюсы:
Не надо писать драйвера, можно потратить время на что нибудь полезное, например на семью или девушку.
Минусы:
Решение доступно любому школьнику, нечем поправить свое самолюбие
А смысл? Гугл драйв нужно ещё как то монтировать в линуксе, так как нет нативного клиента. Либо через веб интерфейс загружать. А раз всё равно какие-то пляски с переносом аудио записей, уж не проще ли тогда просто подключить смарт usb шнурком или вытащить sd карту и всунуть в карт ридер? Так может даже быстрее получится…
Бред какой-то, я понял задачу как:
У меня есть девайс за 5000$, но нет девайса за 100$, как при помощи говна и палок выйти из ситуации?
имхо по любому купить девайс за 100 $ будет и быстрее и надежнее, а если он часто теряется, то надавать по шее, купить 2 и назначить матотвественного.
У меня есть девайс за 5000$, но нет девайса за 100$, как при помощи говна и палок выйти из ситуации?
имхо по любому купить девайс за 100 $ будет и быстрее и надежнее, а если он часто теряется, то надавать по шее, купить 2 и назначить матотвественного.
Я не компания, а физ лицо. Мат. ответственный — это я сам. Ничего у меня не теряется.
Я описываю ситуацию, в которой я был сам. И думаю, что проект может быть полезен.
Я описываю ситуацию, в которой я был сам. И думаю, что проект может быть полезен.
Микрофон за 100 рублей в первом приближении может решить проблему LinuxComp
Не согласен. То уг что вы купите в ашане за 89 рублей можно сразу же переместить в помойку. Качество будет на уровне встроенного мика или ещё хуже. Вы сами попробуйте таким озвучку сделать.
А нормальные смартфоны очень качественно пишут. То ли у них обработчик там какой-то особый, то ли реально какое-то железо хитрое, но факт в том, что качество записи на них гораздо круче.
А нормальные смартфоны очень качественно пишут. То ли у них обработчик там какой-то особый, то ли реально какое-то железо хитрое, но факт в том, что качество записи на них гораздо круче.
Сначала про BT:
Можно сделать так, что бы компьютер работал как гарнитура для телефона. Тогда не надо ничего менять в телефоне, никакого рута, ничего. Беда в том, что профиль гарнитуры обеспечивает моно звук с частотой дискредитизации 8кГц. Этого достаточно разве что для разговоров через GSM. В CDMA и LTE сетях качество звука уже лучше, чем тот, что выдает блютусный Hands Free Profile/ Head Set Profile. Можно бы использовать A2DP но андроидный блютус стек не поддерживает его в режиме Source. Только Sink. Точнее, есть несколько реализаций A2DP Source, но насколько я знаю не одна до сих пор не включена в мейнлайн.
Про USB. VID:PID определяется драйвером USB-gadet. Но главное не пара VID:PID, а класс интерфейса.
Ядро уже поддерживает гаджет аудио-карты: drivers/usb/gadget/function/f_uac1.c
Так что если сможете собрать этот модуль для своего телефона — проблем особых не будет. Правда, вам не удастся встроить его в Android Framework. Точнее, встроить то можно, но это куча работы: audio hal, audio policy, framework. Проще тупо фигачить данные через ALSA.
Заставить выводить часть звуков в динамик, а часть — в разъем наушников тоже тяжело. Надо переделывать тот самый Audio Policy.
Но так как Android — открытая система — всё вышенаписаное вполне осуществимо.
Можно сделать так, что бы компьютер работал как гарнитура для телефона. Тогда не надо ничего менять в телефоне, никакого рута, ничего. Беда в том, что профиль гарнитуры обеспечивает моно звук с частотой дискредитизации 8кГц. Этого достаточно разве что для разговоров через GSM. В CDMA и LTE сетях качество звука уже лучше, чем тот, что выдает блютусный Hands Free Profile/ Head Set Profile. Можно бы использовать A2DP но андроидный блютус стек не поддерживает его в режиме Source. Только Sink. Точнее, есть несколько реализаций A2DP Source, но насколько я знаю не одна до сих пор не включена в мейнлайн.
Про USB. VID:PID определяется драйвером USB-gadet. Но главное не пара VID:PID, а класс интерфейса.
Ядро уже поддерживает гаджет аудио-карты: drivers/usb/gadget/function/f_uac1.c
Так что если сможете собрать этот модуль для своего телефона — проблем особых не будет. Правда, вам не удастся встроить его в Android Framework. Точнее, встроить то можно, но это куча работы: audio hal, audio policy, framework. Проще тупо фигачить данные через ALSA.
Заставить выводить часть звуков в динамик, а часть — в разъем наушников тоже тяжело. Надо переделывать тот самый Audio Policy.
Но так как Android — открытая система — всё вышенаписаное вполне осуществимо.
Спасибо за ваш комментарий, именно таких я и жду.
Спасибо за информацию.
Синк — это же «назначение», а source — источник, правильно? Так нам же по идее нужен sink. То есть комп — это A2DP наушники, на которые смарт сливает звук.
Спасибо. Я не всё понял, так как не ковырялся в теме. Но я так понял, что вы про то, что проблемы будут в том, что из приложений нельзя будет управлять переключением в режим аудиокарты? А можно ли тогда сделать приложение нативным или, не знаю, создать скрипт какой-нибудь и из терминала его запускать?
А это как? Имеется в виду смартфонная альса? И как поток окажется на компе?
Ну, это просто пожелание, нежели требование. На самом деле можно воткнуть например портативную колонку в Y сплиттер (если используется вариант 2).
Беда в том, что профиль гарнитуры обеспечивает моно звук с частотой дискредитизации 8кГц. Этого достаточно разве что для разговоров через GSM.
Спасибо за информацию.
Можно бы использовать A2DP но андроидный блютус стек не поддерживает его в режиме Source. Только Sink.
Синк — это же «назначение», а source — источник, правильно? Так нам же по идее нужен sink. То есть комп — это A2DP наушники, на которые смарт сливает звук.
Ядро уже поддерживает гаджет аудио-карты: drivers/usb/gadget/function/f_uac1.c
Так что если сможете собрать этот модуль для своего телефона — проблем особых не будет. Правда, вам не удастся встроить его в Android Framework. Точнее, встроить то можно, но это куча работы: audio hal, audio policy, framework.
Спасибо. Я не всё понял, так как не ковырялся в теме. Но я так понял, что вы про то, что проблемы будут в том, что из приложений нельзя будет управлять переключением в режим аудиокарты? А можно ли тогда сделать приложение нативным или, не знаю, создать скрипт какой-нибудь и из терминала его запускать?
Проще тупо фигачить данные через ALSA.
А это как? Имеется в виду смартфонная альса? И как поток окажется на компе?
Заставить выводить часть звуков в динамик, а часть — в разъем наушников тоже тяжело. Надо переделывать тот самый Audio Policy.
Ну, это просто пожелание, нежели требование. На самом деле можно воткнуть например портативную колонку в Y сплиттер (если используется вариант 2).
Синк — это же «назначение», а source — источник, правильно? Так нам же по идее нужен sink. То есть комп — это A2DP наушники, на которые смарт сливает звук.
Да, действительно. Что-то я торможу. Нам нужен A2DP Source, который как раз поддерживается всеми смартфонами. Нужно просто настроить компьютер как A2DP Sink. Pulseaudio это умеет.
Так что надо только приложение для смартфона которое будет роутить звук из микрофона в media output и правильно настроенный PulseAudio.
Спасибо. Я не всё понял, так как не ковырялся в теме. Но я так понял, что вы про то, что проблемы будут в том, что из приложений нельзя будет управлять переключением в режим аудиокарты?
Да, именно. У андроида своя подсистема обработки звука которая обычно жестко затачивается под конкретное устройство. Соответственно, эта подсистема не ожидает что у нас вдруг появится USB Audio Gadget. Во всяком случае так было в андроидах 4х-5х версий.
А можно ли тогда сделать приложение нативным или, не знаю, создать скрипт какой-нибудь и из терминала его запускать?
Да, это как раз именно то что я имел в виду когда говорил про ALSA. USB Audio Gadget будет выглядеть как ещё одна звуковая карта. Соответственно можно работать с ним стандартными линуксовыми методами. Единственная проблема в том, что начиная с Android 3.x на устройствах больше не ставится полноценная alsa-lib. Вместо неё используют TinyAlsa. Так что приложение придется писать самому. Но это не очень сложно ;)
Мне удалось заставить работать идею 5.
Вот что я для этого делал.
Установил blueman и pulseaudio-bluetooth,
создал файл /etc/bluetooth/audio.conf со следующим содержимым:
Перезагрузился. Включил блютус на компе и на смарте.
Удалил как как с компа так и со смарта предыдущее сопряжение.
Открыл blueman.
Теперь нужно инициировать сопряжение. Тут происходили какие-то странности. Долго не мог сделать подключение, потом каким-то образом сделал. Поэкспериментировав, так и не выяснил, как надо делать.
Простое сопряжение невозможно сделать ни с компа, ни с телефона.
То есть если на телефоне нажать на иконку для подключения ноутбука, то на нём и на компе появляется диалог для подтверждения ключа доступа для соединения. Он совпадает на компе и на телефоне. Я подтрверждаю его и на компе и на телефоне. Но затем на телефоне выводится тост, что «Невозможно установить соединение с буком. Неправильный PIN-код или пароль».
Если инициировать сопряжение с компа, оно тоже фейлится. Заходим в blueman, выполняем поиск bluetooth устройств, видим наш смартфон, нажимаем пкм по нему, и нажимаем «Сопряжение» (пункт меню с серебряным ключиком). На компе вылезает диалог для подтверждения ключа, который я принимаю. Но на смартфоне прикол: сначала выводится окно «Ошибка» с тем же текстом «Невозможно установить соединение с буком. Неправильный PIN-код или пароль» и с единственной кнопкой «Ok». А после её нажатия появляется диалог подтверждения ключа сопряжения. Каким образом он узнаёт, что пин неверный, если я ещё его подтверждить не успел? Причём код соответствует тому, что на компе. Но подтвердив его, сопряжение не регистрируется.
Это чьи баги: линукса или андроида?
Я больше склонялся, что андроида. Потому как часто приходят двойные подтверждения кода. Что-то он вообще тупит… Вот выключаю блютик на компе, а на смарте он ещё отображается в доступных устройствах даже после повторного перепоиска.
Короче, создать это сопряжение — реально баганутое дело. Из многих десятков попыток были единичные случаи удачных сопряжений. Как я только ни пробовал… Инициировал сопрожение одновременно и с тела и компа, пробовал подтверждать код сначала на компе, потом на теле и в обратном порядке: сначала на теле, потом на компе, пробовал выжидать несколько секунд (чтобы успела дойти информация), пробовал делать тел невидимым, пробовал сначала пометить тел как доверенный в блюмане. И всё это в разных комбинациях и порядке. И никакой закономерности при удачном сопряжении!
Потом попробовал изменить графическое окружение на компе. Всё что я описывал выше происходило при использовании kde. Переключившись на cinnamon ни единой ошибки: удачно сопрягался в любых комбинациях (инициировал с любой стороны и подтверждал код в любом порядке).
Надо копаться что за проблемы в KDE.
Итак, нам наконец удалось авторизовать комп на смарте. Он отображается в разделе Подключенные устройства и помечен как Авторизовано. Теперь не него можно нажать. Он загорится синим и будет надпись «Подключен звук мультимедиа».
Также можно подключиться из блюмана. Нажимаем пкм по смарту, выбираем пункт «подключиться к: источник звука» (позволяет принимать звук с устройства).
Чтобы проверить, что комп предоставляет смартфону сервис синк (то есть выступает как наушники), выполните поиск сервиса для мак адреса смартфона:
sdptool search --bdaddr… a2snk
Если будет одна строка Searching for a2snk on FF:FF:FF:00:00:00 ..., значит сервис не предоставляется. (узнал отсюда )
Теперь откроем приложение Mic to Speaker. Нажимаем в нём кнопку Talk on. Ура, мы слышим звук со смарта на компе!
Открываем pavucontrol, на вкладке проигрывание мьютим наш источник. Откроем audacity и попробуем записать что-нибудь.
Запись работает. Звук неплохой.
Но бывает происходят внезапные остановки записи. Я выяснил почему. Оказывается, наш источник (смартфон), несмотря на то что он подключен, доступен в системе лишь тогда, когда он реально посылает какой-то звук. Если заглянуть в pavucontrol, мы можем наблюдать, что наш bluetooth источник будет исчезать, если мы выключаем talk, и появляться, когда мы снова включаем talk. Так что советую в pavucontrol на вкладке запись явно указать, что для приложения Audacity вы хотите использовать смартфон. Тогда вы случайно не запишите звук со внутреннего микрофона. А чтобы при диктовке текста не отвлекаться на контролирование того, что запись не оборвалась, просто не выключайте talk.
Думаю, мы можем считать, что идея 5 полностью реализована, за исключением глючности блютуса в KDE.
P.S. по поводу моего упоминания того, что возможно понадобится ещё один bluetooth донгл, чтобы обычные устройства могли подключаться к компу. Я нашёл эту страницу. Там в разделе One more thing, honey говорится что использовать комп одновременно и для стриминга (на bt колонки) и для ресивинга (со смарта по bt) невозможно. Но это относится к аудио. Что по поводу других устройств (например, bt клавиатуры) при ресивинге я не знаю.
Вот что я для этого делал.
Установил blueman и pulseaudio-bluetooth,
создал файл /etc/bluetooth/audio.conf со следующим содержимым:
[General]
Enable=Source,Sink,Media,Socket
Перезагрузился. Включил блютус на компе и на смарте.
Удалил как как с компа так и со смарта предыдущее сопряжение.
Открыл blueman.
Теперь нужно инициировать сопряжение. Тут происходили какие-то странности. Долго не мог сделать подключение, потом каким-то образом сделал. Поэкспериментировав, так и не выяснил, как надо делать.
Простое сопряжение невозможно сделать ни с компа, ни с телефона.
То есть если на телефоне нажать на иконку для подключения ноутбука, то на нём и на компе появляется диалог для подтверждения ключа доступа для соединения. Он совпадает на компе и на телефоне. Я подтрверждаю его и на компе и на телефоне. Но затем на телефоне выводится тост, что «Невозможно установить соединение с буком. Неправильный PIN-код или пароль».
Если инициировать сопряжение с компа, оно тоже фейлится. Заходим в blueman, выполняем поиск bluetooth устройств, видим наш смартфон, нажимаем пкм по нему, и нажимаем «Сопряжение» (пункт меню с серебряным ключиком). На компе вылезает диалог для подтверждения ключа, который я принимаю. Но на смартфоне прикол: сначала выводится окно «Ошибка» с тем же текстом «Невозможно установить соединение с буком. Неправильный PIN-код или пароль» и с единственной кнопкой «Ok». А после её нажатия появляется диалог подтверждения ключа сопряжения. Каким образом он узнаёт, что пин неверный, если я ещё его подтверждить не успел? Причём код соответствует тому, что на компе. Но подтвердив его, сопряжение не регистрируется.
Это чьи баги: линукса или андроида?
Я больше склонялся, что андроида. Потому как часто приходят двойные подтверждения кода. Что-то он вообще тупит… Вот выключаю блютик на компе, а на смарте он ещё отображается в доступных устройствах даже после повторного перепоиска.
Короче, создать это сопряжение — реально баганутое дело. Из многих десятков попыток были единичные случаи удачных сопряжений. Как я только ни пробовал… Инициировал сопрожение одновременно и с тела и компа, пробовал подтверждать код сначала на компе, потом на теле и в обратном порядке: сначала на теле, потом на компе, пробовал выжидать несколько секунд (чтобы успела дойти информация), пробовал делать тел невидимым, пробовал сначала пометить тел как доверенный в блюмане. И всё это в разных комбинациях и порядке. И никакой закономерности при удачном сопряжении!
Потом попробовал изменить графическое окружение на компе. Всё что я описывал выше происходило при использовании kde. Переключившись на cinnamon ни единой ошибки: удачно сопрягался в любых комбинациях (инициировал с любой стороны и подтверждал код в любом порядке).
Надо копаться что за проблемы в KDE.
Итак, нам наконец удалось авторизовать комп на смарте. Он отображается в разделе Подключенные устройства и помечен как Авторизовано. Теперь не него можно нажать. Он загорится синим и будет надпись «Подключен звук мультимедиа».
Также можно подключиться из блюмана. Нажимаем пкм по смарту, выбираем пункт «подключиться к: источник звука» (позволяет принимать звук с устройства).
Чтобы проверить, что комп предоставляет смартфону сервис синк (то есть выступает как наушники), выполните поиск сервиса для мак адреса смартфона:
sdptool search --bdaddr… a2snk
Если будет одна строка Searching for a2snk on FF:FF:FF:00:00:00 ..., значит сервис не предоставляется. (узнал отсюда )
Теперь откроем приложение Mic to Speaker. Нажимаем в нём кнопку Talk on. Ура, мы слышим звук со смарта на компе!
Открываем pavucontrol, на вкладке проигрывание мьютим наш источник. Откроем audacity и попробуем записать что-нибудь.
Запись работает. Звук неплохой.
Но бывает происходят внезапные остановки записи. Я выяснил почему. Оказывается, наш источник (смартфон), несмотря на то что он подключен, доступен в системе лишь тогда, когда он реально посылает какой-то звук. Если заглянуть в pavucontrol, мы можем наблюдать, что наш bluetooth источник будет исчезать, если мы выключаем talk, и появляться, когда мы снова включаем talk. Так что советую в pavucontrol на вкладке запись явно указать, что для приложения Audacity вы хотите использовать смартфон. Тогда вы случайно не запишите звук со внутреннего микрофона. А чтобы при диктовке текста не отвлекаться на контролирование того, что запись не оборвалась, просто не выключайте talk.
Думаю, мы можем считать, что идея 5 полностью реализована, за исключением глючности блютуса в KDE.
P.S. по поводу моего упоминания того, что возможно понадобится ещё один bluetooth донгл, чтобы обычные устройства могли подключаться к компу. Я нашёл эту страницу. Там в разделе One more thing, honey говорится что использовать комп одновременно и для стриминга (на bt колонки) и для ресивинга (со смарта по bt) невозможно. Но это относится к аудио. Что по поводу других устройств (например, bt клавиатуры) при ресивинге я не знаю.
Про USB. VID:PID определяется драйвером USB-gadet. Но главное не пара VID:PID, а класс интерфейса.
Ядро уже поддерживает гаджет аудио-карты: drivers/usb/gadget/function/f_uac1.c
Так что если сможете собрать этот модуль для своего телефона — проблем особых не будет.
А вы не подскажте как это всё делается? Я представляю то о чём вы говорите так:
1) Для Android собрать модуль ядра f_uac1 из исходника (Этот исходник?)
2) Поместить его на смартфон
adb push f_uac1.ko /system/lib/modules/
и перезагрузить смартфон.
3) Если он не будет загружен автоматически, то выполнить на смартфоне
insmod f_uac
Да, это как раз именно то что я имел в виду когда говорил про ALSA. USB Audio Gadget будет выглядеть как ещё одна звуковая карта. Соответственно можно работать с ним стандартными линуксовыми методами. Единственная проблема в том, что начиная с Android 3.x на устройствах больше не ставится полноценная alsa-lib. Вместо неё используют TinyAlsa.
То есть через TinyAlsa работать не получится и придётся доустанавливать ещё обычную alsa?
4) Работать линуксовыми методами. (как именно?)
По поводу сложности встраивания в Android Framework: а зачем? Я думаю, можно написать приложение, которое и будет «работать линуксовыми методами», используя busybox.
Я поизучал информацию с оф. источника касательно идеи 3.
И мне кажется, что сделать это проще, чем кажется.
Итак, Android может работать в трёх разных режимах usb:
1) Режим разработчика.
В нём доступны только fastboot и adb. При подключении к хосту (компу) он определяется в этом режиме.
2) Режим хоста.
По otg кабелю можно подключить аудиокарту. Я упоминал, что это близкая тематика, но к нашей задаче не относится, т.к. нам надо, чтобы сам смартфон выступал аудиокартой. Ну, разве что превратить комп в «периферийное устройство» и подключаться к смартфону. Этот режим нам не нужен.
3) Режим аксессуара.
Это как раз то, что нам нужно. В этом режиме тоже может быть доступен adb. Но главное, что смартфон является периферийным (не главным) устройством для хоста.
Там же написано, что чтобы перевести смартфон из режима разработчика в режим аксессуара, нужно пройти re-negotiation process.
Ещё там написано,,
Это же то, что нам нужно!
Теперь мне кажется, что даже не понадобится собирать никакие модули ядра. Всё уже итак должно работать. Вот как это описано:
Действительно, я такой режим видел. Для смартфона samsung S4 есть мультимедиа подставка.
Не могу точно сказать в каком режиме она работает с телефоном. В неё можно подключать usb устройства (это как бы режим otg хоста), micro-usb (для питания самой док подставки и для подключения к компу в обычном режиме аксессуара), hdmi кабель (как бы режим mhl), и аудио кабель (как бы режим аксессуара, тот самый, что нужен нам). Я разбирал её, и там видно, что используется не 5 контактов usb, а целых 12!
P.S. мне нужно восстановить переломанный шлейф. Если кто-то умеет заниматься мелкой пайкой, свяжитесь пожалуйста со мной.
В самом конце страницы сказано, что производителю нужно правильно реализовать аудио политику в файле audio_policy.conf
У меня файл расположен в /system/etc/, и такую политику он содержит.
Теперь вопрос только в том, как (и возможно ли) сделать так, чтобы комп вёл себя как медиа подставка (которая, как и комп, является хостом). Он должен перевести смарт из режима разработчика в режим аксессуара, причём не в простой, а именно в «мультимедиа-док» режим.
По этому вопросу я нашёл старый вопрос на stackoverflow. Но я не понял как это можно сделать. Есть ли какой-то известный путь или нужно как-то отснифать usb траффик мужду мультимедиа подставкои и смартфоном?
И мне кажется, что сделать это проще, чем кажется.
Итак, Android может работать в трёх разных режимах usb:
1) Режим разработчика.
В нём доступны только fastboot и adb. При подключении к хосту (компу) он определяется в этом режиме.
2) Режим хоста.
По otg кабелю можно подключить аудиокарту. Я упоминал, что это близкая тематика, но к нашей задаче не относится, т.к. нам надо, чтобы сам смартфон выступал аудиокартой. Ну, разве что превратить комп в «периферийное устройство» и подключаться к смартфону. Этот режим нам не нужен.
3) Режим аксессуара.
Это как раз то, что нам нужно. В этом режиме тоже может быть доступен adb. Но главное, что смартфон является периферийным (не главным) устройством для хоста.
Там же написано, что чтобы перевести смартфон из режима разработчика в режим аксессуара, нужно пройти re-negotiation process.
Ещё там написано,,
Android 4.1 (API level 16) added limited support for audio playback to the host. While in accessory mode, Android automatically routes its audio output to USB. That is, the Android device serves as a data source to the host, for example a dock.
Это же то, что нам нужно!
Теперь мне кажется, что даже не понадобится собирать никакие модули ядра. Всё уже итак должно работать. Вот как это описано:
The Android device must be controlled by a knowledgeable host that can first transition the Android device from development mode to accessory mode, and then the host must transfer audio data from the appropriate endpoint. Thus the Android device does not appear «driverless» to the host.
Действительно, я такой режим видел. Для смартфона samsung S4 есть мультимедиа подставка.
фото подставки
Не могу точно сказать в каком режиме она работает с телефоном. В неё можно подключать usb устройства (это как бы режим otg хоста), micro-usb (для питания самой док подставки и для подключения к компу в обычном режиме аксессуара), hdmi кабель (как бы режим mhl), и аудио кабель (как бы режим аксессуара, тот самый, что нужен нам). Я разбирал её, и там видно, что используется не 5 контактов usb, а целых 12!
картинки
P.S. мне нужно восстановить переломанный шлейф. Если кто-то умеет заниматься мелкой пайкой, свяжитесь пожалуйста со мной.
В самом конце страницы сказано, что производителю нужно правильно реализовать аудио политику в файле audio_policy.conf
audio_hw_modules {
...
usb {
outputs {
usb_accessory {
sampling_rates 44100
channel_masks AUDIO_CHANNEL_OUT_STEREO
formats AUDIO_FORMAT_PCM_16_BIT
devices AUDIO_DEVICE_OUT_USB_ACCESSORY
}
...
}
...
}
}
...
}
У меня файл расположен в /system/etc/, и такую политику он содержит.
Теперь вопрос только в том, как (и возможно ли) сделать так, чтобы комп вёл себя как медиа подставка (которая, как и комп, является хостом). Он должен перевести смарт из режима разработчика в режим аксессуара, причём не в простой, а именно в «мультимедиа-док» режим.
По этому вопросу я нашёл старый вопрос на stackoverflow. Но я не понял как это можно сделать. Есть ли какой-то известный путь или нужно как-то отснифать usb траффик мужду мультимедиа подставкои и смартфоном?
Я ещё поисследовал вопрос по поводу идеи 3.
Оказывается, существует Android Open Accessory Protocol. Он описывает, как подключаемый по usb аксессуар должен взаимодействовать со смартфоном. Начиная с android 4.1 появилась спецификация 2.0, и в ней появилась поддержка передачи аудио на аксессуар. В первую очередь подразумевалась аудио док станция. Но нам нужно забрать аудио на обычный линукс комп.
В спецификации описано, какие именно данные нужно слать на смартфон, чтобы переключить его в аксессуарный режим. Там можно например задать url с которого надо скачать приложение для аксессуара. Кроме того, описано, что можно не определять конкретное приложение, а просто запросить аудио.
К сожалению, гугл описывает разработку так, будто у меня есть ардуино. Но у меня его нет. Я стал искать, возможно ли как то обойтись без него, ведь наша конечная цель — просто подключение к компу без лишнего железа. Я нагуглил статью, в которой, к моей радости, это было описано. Да, arduino ну нужен =).
А вот и проект, на котором автор приведённой выше статьи сделал свой проект.
Я закачал его, сделал make, посмотрел через lsusb текущий pid:vid моего смартфона (меняется при переключении режимов). Например, сейчас у меня такие id: 04e8:6865. Выполняю команду
Аппарат действительно переводится в режим аудиокарты, т.е. в lsusb мы теперь видим 18d1:2d04 Google Inc. В вашем случае будет какой-то id из этого списка в зависимости от того, включали ли вы отладку и какие параметры передавали через linux-adk.
Можно было бы сказать, что музыка со смартфона перенаправляется на usb, т.к. в интерфейсе плеера воспроизведение продолжается, а звук с динамика телефона прекращается. Но это не совсем так.
В системе у меня появляется ещё одно аудио устройство. Если ввести arecord -l, то я вижу
Но в pavucontrol я могу видеть, что на нём не колеблется индикатор звука.
Что это значит? То ли чего-то неправильно в linux-adk (сомневаюсь), то ли это самсунг сделали такую реализацию-пустышку (склоняюсь)? Сами гугл не рекомундуют использовать usb audio вывод:
Ещё могу сказать, что при посадке в настоящую док станцию, смартфон об этом сообщает. Т.е. в шторке появляются рекомендуемые приложения (PageBuddy) и на экране отображается радуга. А здесь такого нет.
Я проверил галочку «Prevent usb audio routing» в настройках разработчика, но в моём случае она ни на что не влияла.
Скорее всего, самсунговская подставка не использует стандартную реализацию, которую мы только что пытались осуществить. Ну как-то же работает он со своей станцией… Может быть есть где-то на смартфоне список известных ему аксессуаров? Наверняка там есть описание этой подставки. Если бы найти это описание, мы бы возможно узнали какие сигналы нужно послать, чтобы «задокить» смартфон.
Или же мне надо сниффить как смарт общается с этой подставкой. Но может быть вообще ничего из этого не получится. И дело даже не в том, что я пока не имею опыта как это делать, а в их странном usb коннекторе.
Для чего-то же они используют своё расширение из 6 контактов… Может быть это два usb порта, объединённые в один? Даже не ясно в каком режиме подключается подставка: хоста, аксессуара или в каком-то смешанном самсунговском.
Ну, даже если это и получится, вряд ли это будет решением для пользователей других производителей.
В итоге, на данный момент перевести в режим аудиокарты удалось, но не удалось забрать звук.
У кого-нибудь есть опыт в usb сниффинге?
Ещё ссылки по теме:
http://blog.jfedor.org/2013/01/usb-audio-dock-for-android.html
https://github.com/SquidIndustries/AndroidCarAudioDock
https://www.youtube.com/watch?v=MzIWi1Q-DaE
http://android.serverbox.ch/?p=262
Оказывается, существует Android Open Accessory Protocol. Он описывает, как подключаемый по usb аксессуар должен взаимодействовать со смартфоном. Начиная с android 4.1 появилась спецификация 2.0, и в ней появилась поддержка передачи аудио на аксессуар. В первую очередь подразумевалась аудио док станция. Но нам нужно забрать аудио на обычный линукс комп.
В спецификации описано, какие именно данные нужно слать на смартфон, чтобы переключить его в аксессуарный режим. Там можно например задать url с которого надо скачать приложение для аксессуара. Кроме того, описано, что можно не определять конкретное приложение, а просто запросить аудио.
К сожалению, гугл описывает разработку так, будто у меня есть ардуино. Но у меня его нет. Я стал искать, возможно ли как то обойтись без него, ведь наша конечная цель — просто подключение к компу без лишнего железа. Я нагуглил статью, в которой, к моей радости, это было описано. Да, arduino ну нужен =).
А вот и проект, на котором автор приведённой выше статьи сделал свой проект.
Я закачал его, сделал make, посмотрел через lsusb текущий pid:vid моего смартфона (меняется при переключении режимов). Например, сейчас у меня такие id: 04e8:6865. Выполняю команду
./linux-adk --device 04e8:6865 --no_app
Аппарат действительно переводится в режим аудиокарты, т.е. в lsusb мы теперь видим 18d1:2d04 Google Inc. В вашем случае будет какой-то id из этого списка в зависимости от того, включали ли вы отладку и какие параметры передавали через linux-adk.
Можно было бы сказать, что музыка со смартфона перенаправляется на usb, т.к. в интерфейсе плеера воспроизведение продолжается, а звук с динамика телефона прекращается. Но это не совсем так.
В системе у меня появляется ещё одно аудио устройство. Если ввести arecord -l, то я вижу
**** List of CAPTURE Hardware Devices ****
card 1: PCH [HDA Intel PCH], device 0: ALC233 Analog [ALC233 Analog]
Subdevices: 0/1
Subdevice #0: subdevice #0
card 2: SAMSUNGAndroid [SAMSUNG_Android], device 0: USB Audio [USB Audio]
Subdevices: 0/1
Subdevice #0: subdevice #0
Но в pavucontrol я могу видеть, что на нём не колеблется индикатор звука.
Что это значит? То ли чего-то неправильно в linux-adk (сомневаюсь), то ли это самсунг сделали такую реализацию-пустышку (склоняюсь)? Сами гугл не рекомундуют использовать usb audio вывод:
Accessory mode audio has not been widely adopted, and is not currently recommended for new designs.Может поэтому самсунг так «реализовали» эту функцию?
Ещё могу сказать, что при посадке в настоящую док станцию, смартфон об этом сообщает. Т.е. в шторке появляются рекомендуемые приложения (PageBuddy) и на экране отображается радуга. А здесь такого нет.
Я проверил галочку «Prevent usb audio routing» в настройках разработчика, но в моём случае она ни на что не влияла.
Скорее всего, самсунговская подставка не использует стандартную реализацию, которую мы только что пытались осуществить. Ну как-то же работает он со своей станцией… Может быть есть где-то на смартфоне список известных ему аксессуаров? Наверняка там есть описание этой подставки. Если бы найти это описание, мы бы возможно узнали какие сигналы нужно послать, чтобы «задокить» смартфон.
Или же мне надо сниффить как смарт общается с этой подставкой. Но может быть вообще ничего из этого не получится. И дело даже не в том, что я пока не имею опыта как это делать, а в их странном usb коннекторе.
Для чего-то же они используют своё расширение из 6 контактов… Может быть это два usb порта, объединённые в один? Даже не ясно в каком режиме подключается подставка: хоста, аксессуара или в каком-то смешанном самсунговском.
Ну, даже если это и получится, вряд ли это будет решением для пользователей других производителей.
В итоге, на данный момент перевести в режим аудиокарты удалось, но не удалось забрать звук.
У кого-нибудь есть опыт в usb сниффинге?
Ещё ссылки по теме:
http://blog.jfedor.org/2013/01/usb-audio-dock-for-android.html
https://github.com/SquidIndustries/AndroidCarAudioDock
https://www.youtube.com/watch?v=MzIWi1Q-DaE
http://android.serverbox.ch/?p=262
Я использую приложение WO Mic (есть в гугл плее, бесплатно). Рут не нужен.
Это, по сути идея 3 + идея 4: смартфон в качестве аудиокарты и передавать аудиопоток по сети.
В винде выглядит как ещё один микрофон. Способы соединения: USB, Wi-fi, bluetooth.
Пользуюсь скайпом, тимспик в играх, всё работает вроде. Задержка добавляется, да. На слух 100-300 мсек дополнительно.
Не знаю, правда, что там за кодек используется для передачи. Если там не PCM, наверное, для озвучки видео — это не лучшее решение. Но для того же тимспика пойдет.
Это, по сути идея 3 + идея 4: смартфон в качестве аудиокарты и передавать аудиопоток по сети.
В винде выглядит как ещё один микрофон. Способы соединения: USB, Wi-fi, bluetooth.
Пользуюсь скайпом, тимспик в играх, всё работает вроде. Задержка добавляется, да. На слух 100-300 мсек дополнительно.
Не знаю, правда, что там за кодек используется для передачи. Если там не PCM, наверное, для озвучки видео — это не лучшее решение. Но для того же тимспика пойдет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как превратить смартфон в микрофон (идеи и вопросы)