Зачем это нужно?
Бывает так, что нужно сделать озвучку для какого-то видео, но качественного микрофона под рукой нет. Озвучивать на внутренний микрофон — это значит угробить видео. А вот качество записи на многие современные смартфоны очень даже приличное. Поэтому приходится записывать на смартфон, а затем переносить записи на компьютер.
Но удобства здесь мало. Если вы делаете дубляж, то постоянно приходится перезаписывать фрагменты, где нужно чтобы ваша речь была быстрее или медленнее. А это значит, что каждый неудачный раз вам нужно снова копировать файл записи со смартфона на комп. Я хочу этого избежать, то есть сделать так, чтобы запись сразу оказывалась на компе, как будто вы подключили настоящий микрофон.
Ниже я перечислю свои идеи, приведу их плюсы и минусы. Хотел бы услышать ваши комментарии о возможности их реализации.
Идея 1. Смартфон в качестве BlueTooth гарнитуры
1. Написать драйвер для Android смартфона, который бы представлял его окружающим устройствам как беспроводная гарнитура (с микрофоном).
2. Написать приложение для Android смартфона, которое будет забирать звук со встроенного микрофона и направлять его этому драйверу.
3. Выполнить поиск bluetooth устройств на компьютере, подключить «беспроводную гарнитуру».
4. Выбрать её на компе в качестве приоритетного микрофона.
5. Profit
Плюсы
Никаких манипуляций на компе. Не требует дополнительного АО для пользователя.
Минусы
Скорее всего нужен будет root на смартфоне
Мои комментарии и вопросы
1. Возможно ли создать такой драйвер? Мне кажется что да. Я видел что-то подобное для подключения DualShock 3 (bluetooth геймпад для PlayStation) к смартфону (Sixaxis Controller).
2. Будет ли задержка при передаче? Уверен, что да.
3. Будет ли передача происходить без потерь? Не знаю.
Идея 2. Аудиовыход смартфона на аудиовход компьютера
1. Создать переходник с TRS на TRRS (CTIA)
2. Создать аттенюатор line to mic (как его делать — обсудим в моём следующем видео)
3. Запустить приложение Mic To Speaker, выводящее звук со встроенного микрофона смартфона на динамик/аудиовыход смартфона.
4. Подключить смартфон к компьютеру через переходник с аттенюатором.
5. Выбрать на компе внешний микрофон как приоритетный.
5. Profit
Плюсы
Никаких манипуляций на компе.
Минусы
Требует дополнительное аппаратное обеспечение
Мои комментарии и вопросы
1. Возможно ли выводить определённые звуки (уведомления) на встроенный динамик, если вставлен штекер в аудио разъём?
2. Возможно ли записывать звук именно со внутреннего микрофона, если вдруг смартфон определит, что доступен внешний микрофон? Я думаю, что приложение само может выбрать с какого устройства брать звук (со встроенного либо со внешнего микрофона). Но чтобы не было лишних проблем, в смартфон лучше вставлять TRS штекер, а не TRRS.
Идея 3. Смартфон в качестве аудиокарты
1. Сделать программу (или что?), чтобы смартфон мог идентифицироваться USB хосту как аудиокарта (т. е. сообщить компу Pid:Vid, соответствующий какой-либо аудиокарте).
2. Написать приложение на Android, которое будет слать звук со встроенного микрофона на «аудиокарту».
3. Активировать подмену vid:pid и запустить приложение
4. Подключить смартфон к компу по usb
5. Выбрать на компе микрофон со внешней аудиокарты как приоритетный
6. Profit
Примечание: описанное не имеет отношения к USB Audio для android. Usb аудио позволяет подключать внешнюю звуковуху к смартфону. То есть звук со смартфона можно выводить на неё и вводить с неё на смартфон. Но нам нужно, чтобы сам смартфон выступал аудиокартой.
Плюсы
Никаких манипуляций на компе.
Минусы
Скорее всего нужен будет root на смартфоне
Дополнительные задержки на usb контроллерах
Мои комментарии и вопросы
1. Возможна ли подмена Vid:Pid или это можно сделать только аппаратно?
2. Возможно ли использовать usb_ModeSwitch для управления такой подменой с компа или же такие манипуляции можно делать только на смартфоне?
3. Хватит ли пропускной способности usb 2.0, чтобы нормально передавать звук? Здесь сказано, что максимальный теоретический рейт для high-speed usb — это 1,023,000 байт/сек.
Идея 4. Передавать аудиопоток по сети
1. Установить приложение, которое отправляет аудио поток со внутреннего микрофона по сети (я использовал Ip Webcam, но это несвободное по).
2. Пробросить сеть смартфона на комп через adb по usb (чтобы исключить wifi). Ip Webcam-gst может сделать это автоматически.
3. Получить доступ с компа к этому потоку.
4. Зарегистрировать в системе виртуальный микрофон. Завернуть в него получаемый http поток в качестве источника. [Нужно для универсальности. Хотя можно использовать записывалку, которая умеет сразу ловить такие потоки, например vlc или open broadcaster].
5. Выбрать на компе этот виртуальный микрофон как приоритетный
6. Profit
Плюсы
Не нужен root на смартфоне
Минусы
Требуется клиентское ПО для компьютера
Мои комментарии и вопросы
1. VLC имеет встроенную возможность захвата http потока, но имеет серьёзные неудобства при записи (по крайней мере в Gui). Как vlc может захватывать поток с помощью командной строки не разобрался. Может кто подскажет?
2. Ip Webcam-gst умеет регистрировать виртуальный микрофон, но не умеет использовать кодек, отличный от Wav. Кто разбирается в gstreamer конвейерах? Нужно собрать конвейер, который бы поддерживал бы Opus и aac.
3. Я видел приложение WoMic, которое реализует такой функционал. Оно требует Win или Mac. А на Linux я применял ipwebcam. Это несвободная программа. Я думаю, что лучше бы функционал ipwebcam (по аудио части) включить в KDE Connect. Я был бы рад, если кто-то мне с этим помог.
Идея 5. Компьютер как bluetooth наушники для смартфона
1. Написать драйвер (?) для компьютера, который бы представлял его окружающим устройствам как bluetooth аудио колонки.
2. Написать программу для компьютера, которая будет регистрировать виртуальный микрофон и направлять в него приходящий на «колонки» звук.
3. Запустить программу на компьютере и оставаться видимым bluetooth устройством.
4. Запустить приложение Mic To Speaker на смартфоне и подключить его к «беспроводным наушникам». (Я не проверял, можно ли изменять слив при работе этого приложения, но думаю что проблем быть не должно. Если будут проблемы, значит надо написать программу для android, которая будет направлять звук со встроенного микрофона на «bluetooth колонки»).
5. Выбрать на компьютере виртуальный микрофон как приоритетный.
6. Profit
Плюсы
Не нужен root на смартфоне
Минусы
Для одновременного нормального функционирования блютуса компа (например, для bluetooth клавиатуры) скорее всего понадобится дополнительный bt донгл. Я видел подобную ситуацию с dualshock драйвером для компа.
Мои комментарии и вопросы
Какой из всех предложенных вариантов обеспечит наименьшие задержки при передаче?
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (39)
LinuxComp
31.10.2016 17:59Не, тут речь о дубляже видео (я переозвучивал несколько видео на русский язык). Видео дорожку я вообще не трогаю. Все эти затеи лишь для того, чтобы не приходилось переносить с телефона аудио файлы, а чтобы они сразу оказывались на компьютере.
WNeZRoS
31.10.2016 18:03+1Вы не искали реализаций своих идей?
Например: передача звука с микрофона через джек-джек кабель или через клиент-серверLinuxComp
31.10.2016 18:19Читаем статью внимательней, я упоминал про WoMic. У нас речь о Linux, так что он не подходит.
Приложение «Микрофон» я тоже видел, оно не умеет менять громкость, поэтому я говорил о Mic To Speaker.
ValdikSS
31.10.2016 18:54+7Если речь о Linux, то вам нужно реализовать Simple-протокол PulseAudio в приложении, которое захватывало бы микрофон. Пример программы наоборот: Simple Protocol Player, я с его помощью фильмы запускаю на компьютере, а звук получаю в наушники, которые подключены к телефону, а телефон подключен к домашнему Wi-Fi.
cjbars
31.10.2016 18:10+1По поводу второй идеи — а почему не воткнуть аудио выход смартфона в аудиовход компа? Зачем делать аттенюатор и тыкаться в lineIn?
Есть еще идея просто воткнуть наушники в качестве микрофона прямо в lineIn компа.
Но все этот разве что на особо крайние случаи, ибо быстрее будет добежать до ближайшего магазинчика и купить микрофончик. Ну а если озвучивать видео постоянно, то не иметь микрофона мне кажется не совсем хорошо ;-)LinuxComp
31.10.2016 18:30По поводу второй идеи — а почему не воткнуть аудио выход смартфона в аудиовход компа? Зачем делать аттенюатор и тыкаться в lineIn?
Так я так и предлагаю. Аттенюатор понадобится, поскольку из смартфона идёт line level, а в ноутбук должен прийти mic level.
Есть еще идея просто воткнуть наушники в качестве микрофона прямо в
lineInmic in компа. Но все это разве что на особо крайние случаи, ибо быстрее будет добежать до ближайшего магазинчика и купить микрофончик.
Спасибо за дополнительную идею. Но, соглашусь, она для крайнего случая. Хотя, мало ли какие ситуации могут быть… Добавлю в статью.
Ну а если озвучивать видео постоянно, то не иметь микрофона мне кажется не совсем хорошо ;-)
У меня уже есть петличка, которая даёт хорошее качество. Хотел просто поделиться идеями, многим может пригодиться.cjbars
31.10.2016 19:14Я похоже не увидел что в вашем ноутбуке нет линейного входа(в чем я правда сомневаюсь). Просто линейку в линейку по идее нужно втыкать без аттенюации, сигналы там сопоставимые по уровню.
Еще раз повторюсь: аудиовыход смартфона в линейный вход компа.
Kalobok
31.10.2016 19:19А почему в ноутбук должен приходить именно mic level?
LinuxComp
01.11.2016 01:30Так а где сейчас ноутбуки с line in? Такие вообще в природе бывают?
Раньше были отдельные гнёзда для наушников (зелёное) и микрофона (розовое). Сейчас чаще делают комбо разъём с четырьмя контактами. Он объединяет в себе выход на наушники и вход микрофона.
А line in гнездо я видел только на десктопах. Оно обозначено голубым цветом.
Картинка из гугла
Kalobok
01.11.2016 18:06Ну, даже на десктопах, где не нужно сильно экономить на дырках, есть возможность втыкать разные устройства в один и тот же разъем — система просто спрашивает, что именно воткнули. Так что я весьма удивлен, что такую простую вещь не делают на современных ноутах.
На самом деле, я сильно подозреваю, что воткнуть line-level в микрофонный вход можно и оно будет нормально работать.LinuxComp
01.11.2016 22:51даже на десктопах, где не нужно сильно экономить на дырках, есть возможность втыкать разные устройства в один и тот же разъем — система просто спрашивает, что именно воткнули.
Если я не ошибаюсь, так можно было делать только на некоторых реалтеках на десктопах. Вы могли конфигурять практически любой джек как вам угодно.
скриншот
Kalobok
01.11.2016 23:14Ну, вроде, не только на реалтеках. Если не путаю, мне разные варианты попадались. Насчет того, что это зависит от аппаратной части, согласен. Просто меня удивляет, что поддержка этих функций есть не везде. Казалось бы, ничего сложного в этом нет.
LinuxComp
02.11.2016 21:33Кстати не, мне кажется вариант с подключением наушника в микрофонный вход всё же к нам не относится. Если вы оказались на необитаемом острове и нашли разбитый корабль, тогда может быть такой «микрофон» вас спасёт. Но мы тут говорим об озвучке. И уж явно даже у внутреннего мика ноутбука звук будет не хуже.
GennPen
31.10.2016 18:14> Какой из всех предложенных вариантов обеспечит наименьшие задержки при передаче?
Так вам нужна минимальная задержка или качество звука? Задержка при записи аудиодорожки не имеет значения, главное чтобы она не плавала, а компенсировать ее можно сдвинув аудиодорожку в редакторе.
Самым оптимальным вижу способ передачи данных по сети (WiFi) скорости которой хватит за глаза на передачу не сжатого аудио. Варианты в качестве BT-гарнитуры могут не устроить качеством пережатого аудио, вариант в качестве аудиокарты мне кажется будет сложным.
Я понимаю, что это все делается «за идею», но для озвучивания дубляжа может все-таки лучше раскошелиться на качественный микрофон?LinuxComp
31.10.2016 18:39Так вам нужна минимальная задержка или качество звука? Задержка при записи аудиодорожки не имеет значения
Мне кажется, что качество от задержки не зависит. Задержка не важна, если просто озвучивать написанный текст, например для своего видео туториала. А для дубляжа ещё как важна…
Я понимаю, что это все делается «за идею», но для озвучивания дубляжа может все-таки лучше раскошелиться на качественный микрофон?
Конечно, лучше. Но не всегда есть возможность. Эти идеи помогут хоть как то выйти из положения.GennPen
31.10.2016 19:00> Задержка не важна, если просто озвучивать написанный текст, например для своего видео туториала. А для дубляжа ещё как важна
Я специально добавил «главное чтобы она не плавала, а компенсировать ее можно сдвинув аудиодорожку в редакторе». Да и вы же не в реалтайме это все делаете, а записываете в редактор, где потом в любом случае подправляете все огрехи.LinuxComp
01.11.2016 01:39Ну, я не знаю, называется ли это реал таймом, но я озвучиваю именно глядя на видео и видя субтитры, которые появляются именно тогда, когда нужно. Как я к этому подготавливаюсь я хотел рассказать отдельно в будущем.
Очень бесит, если нужно исправить буквально несколько слов. Нужно выждать ~2 сек, когда звук уже начнёт доходить, после чего только говорить. А нельзя просто так нажать на запись и сразу говорить. Ну, это по собственным ощущениям нужно понять… На словах может выглядит смешно, но реально мешает.GennPen
01.11.2016 02:29Видел как знакомый переводил видео(если не ошибаюсь, то это было в Adobe Premiere), читал прямо по субтитрам, неудачные моменты перезаписывал прямо поверх, а уже потом подрезал фразы и расставлял в нужные места по видео, и тут думаю задержка вообще ни на что не влияет.
Alexufo
31.10.2016 18:55+2(WiFi
ага, потерянный пакет внесет не известно где рассинхрон, лови его потом, а он будет не один.
IronHead
31.10.2016 18:41-3Я предлагаю вариант.
1) На комп установить google drive
2) на телефон установить google drive
3) засинхронизировать папку с аудио через wifi
Теперь делаем следующее: Включаем на компьютере оригинальный видео ролик без звука, на телефоне включаем запись звука. Комментируем все происходящее на видео в микрофон телефона, после чего берем аудио дорожку из папки google drive на компьютере.
Плюсы:
Не надо писать драйвера, можно потратить время на что нибудь полезное, например на семью или девушку.
Минусы:
Решение доступно любому школьнику, нечем поправить свое самолюбиеLinuxComp
01.11.2016 01:44А смысл? Гугл драйв нужно ещё как то монтировать в линуксе, так как нет нативного клиента. Либо через веб интерфейс загружать. А раз всё равно какие-то пляски с переносом аудио записей, уж не проще ли тогда просто подключить смарт usb шнурком или вытащить sd карту и всунуть в карт ридер? Так может даже быстрее получится…
Durimar123
31.10.2016 18:49Бред какой-то, я понял задачу как:
У меня есть девайс за 5000$, но нет девайса за 100$, как при помощи говна и палок выйти из ситуации?
имхо по любому купить девайс за 100 $ будет и быстрее и надежнее, а если он часто теряется, то надавать по шее, купить 2 и назначить матотвественного.LinuxComp
31.10.2016 19:14Я не компания, а физ лицо. Мат. ответственный — это я сам. Ничего у меня не теряется.
Я описываю ситуацию, в которой я был сам. И думаю, что проект может быть полезен.
alexmay
31.10.2016 20:59Samsung SideSync позволяет перетаскивать файлы с телефона на комп. Никаких проводов — WiFi и магия
LinuxComp
01.11.2016 01:51Samsung SideSync — только win или mac, только samsung galaxy смартфон, только touchwiz прошивка, завязка на сервисы samsung. Есть Kde connect, который умеет переносить файлы по wifi, но опять же, хочется чтобы записи слались на комп автоматом.
AstorS1
31.10.2016 21:45Микрофон за 100 рублей в первом приближении может решить проблему LinuxComp
LinuxComp
01.11.2016 01:56+1Не согласен. То уг что вы купите в ашане за 89 рублей можно сразу же переместить в помойку. Качество будет на уровне встроенного мика или ещё хуже. Вы сами попробуйте таким озвучку сделать.
А нормальные смартфоны очень качественно пишут. То ли у них обработчик там какой-то особый, то ли реально какое-то железо хитрое, но факт в том, что качество записи на них гораздо круче.GennPen
01.11.2016 02:31+1> То уг что вы купите в ашане за 89 рублей можно сразу же переместить в помойку. Качество будет на уровне встроенного мика или ещё хуже. Вы сами попробуйте таким озвучку сделать.
https://geektimes.ru/post/281208/
lorc
31.10.2016 20:57+1Сначала про 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 — открытая система — всё вышенаписаное вполне осуществимо.LinuxComp
01.11.2016 03:31Спасибо за ваш комментарий, именно таких я и жду.
Беда в том, что профиль гарнитуры обеспечивает моно звук с частотой дискредитизации 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).lorc
01.11.2016 14:32+1Синк — это же «назначение», а 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. Так что приложение придется писать самому. Но это не очень сложно ;)
LinuxComp
02.11.2016 22:47Мне удалось заставить работать идею 5.
Вот что я для этого делал.
Установил 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 клавиатуры) при ресивинге я не знаю.
LinuxComp
03.11.2016 03:08Про 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.
LinuxComp
03.11.2016 19:31Я поизучал информацию с оф. источника касательно идеи 3.
И мне кажется, что сделать это проще, чем кажется.
Итак, 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 есть мультимедиа подставка.
фото подставки
LinuxComp
04.11.2016 06:45Я ещё поисследовал вопрос по поводу идеи 3.
Оказывается, существует 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
barkalov
01.11.2016 11:57Я использую приложение WO Mic (есть в гугл плее, бесплатно). Рут не нужен.
Это, по сути идея 3 + идея 4: смартфон в качестве аудиокарты и передавать аудиопоток по сети.
В винде выглядит как ещё один микрофон. Способы соединения: USB, Wi-fi, bluetooth.
Пользуюсь скайпом, тимспик в играх, всё работает вроде. Задержка добавляется, да. На слух 100-300 мсек дополнительно.
Не знаю, правда, что там за кодек используется для передачи. Если там не PCM, наверное, для озвучки видео — это не лучшее решение. Но для того же тимспика пойдет.
webmasterx
Я правильно понял что снимать нужно видеокамерой, а звук чтобы писался с телефона?
Что мешает включить запись на видеокамере и запись звука на телефоне и снимать ролик?