Возможно ли определение наличия микрофона?

BBB · 14 дек 2007, 10:32

Возможно ли программным способом (например, через WinAPI) определить, вонкнут ли физически в данный момент микрофон в звуковую плату или нет?

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

Заранее спасибо.

somewhere · 14 дек 2007, 10:48

BBB, тут наверное немного физический метод, если источник записи звука в данный момент - микрофон, и он к тому же присоединен то можно попробовать записать маленький кусочек и просмотреть на наличие хоть какого-то сигнала. Если никакое устройство не подключено, изменения амплитуды будут равны нулю. Совсем недавно приходилось делать захват с микрофона - даже в случае плохого заземления ИЗМЕНЕНИЯ амплитуд сигала практически нет. Если что-то туда воткнуть, будет наблюдатся очень слабый, еле ощутимый сигнал различных наводок.

BBB · 11 янв 2008, 17:07

somewhere,
То есть, предлагаемый тобой способ, все-таки, не "точный" (т.е. на основе неких API-функций типа "bool IsConnected (...)") , а этакий импирический?

Ты имеешь в виду, анализировать занчения отдельных сэмлов потока, приходящего с микрофона через win-событие MM_WIM_DATA? И что, собственно, составляет содержимое Файла (если опустить заголовок) в формате WAVE_FORMAT_PCM?

Я посмотрел, при неподключенном микрофоне содержимое потока (при 8 бит/сэмпл) у меня - чередующиеся (не обязательно "равномерно") значения 0x7F и 0x80.

При подключенном микрофоне и тишине в комнате картина, на самом деле, такая же. Правда, "Усиление микрофона" в настройках звукозаписи было выключено. При включенном "Усиление микрофона" и тишине разброс еле-еле присутствует, буквально на 1-2 единицы.

Так что, если я правильно понял суть твоего предложения, наличие включенного микрофона и "кипении жизни" опознать можно однозначно. А при полной тишине можно ошибочно предположить, что микрофон не подключен.

somewhere · 11 янв 2008, 22:15

&quot писал(а):А при полной тишине можно ошибочно предположить, что микрофон не подключен.

Нет, ибо даже если ты просто воткнешь туда кусок заизолированного провода, даже с охрененным сопротивлением (чтобы ислючить помехи и фон) жизнь закипит "дай дорогу", анализировать желательно 16-битные семплы для большей точности. А точного метода я не знаю, современные карты сами определяют и вырабатывают прерывание, но это далеко не всех касается. Вполне возможно, что они примерно также это определяют, только аналоговым методом.

BBB · 16 янв 2008, 17:12

somewhere писал(а):А точного метода я не знаю, современные карты сами определяют и вырабатывают прерывание, но это далеко не всех касается.

Вот коллеги и рассказывают, мол "А у меня... там картинка... я втыкаю микрофон.. и она прямо на картинке рисует, как штырек втыкается".

somewhere писал(а):анализировать желательно 16-битные семплы для большей точности.

Поскольку видится, что все снимаемое будет записываться, и к тому же это все голосовая запись (не музыка), то, как будто, 16-битовая "точность" не нужна (плюс экономия при записи).

somewhere писал(а):Нет, ибо даже если ты просто воткнешь туда кусок заизолированного провода, даже с охрененным сопротивлением (чтобы ислючить помехи и фон) жизнь закипит "дай дорогу"

Ну не "кипит" она... Вроде, все-таки, байты, отличные от 0x80 и 0x7F, проскакивают. Надо бы провести более чистый эксперимент - поставить запись в пустой комнате. Потом поглядеть, есть ли в том, что получилось, "посторонние" байты (не "байты тишины").

somewhere · 16 янв 2008, 18:08

Все-таки определять надо по записи с 16-битовой точностью оцифровки, при 8-битовом у тебя получается всего 128 уровней амплитуды, т.е. диапазон где-то -7 db получается, ты просто не уловишь эти изменения - что при включеном, что при выключеном микрофоне будет 0x80 по-вашим измерениям и 80h по нашим. А вообще это 0 на самом деле. Я вообщем могу демку создать и выложить, где сам наглядно увидишь, что происходит когда микрофон выключен и когда включен.

BBB · 17 янв 2008, 12:26

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

Выложи, если это тебе не сильно трудоемко.

Кстати, посмотрел содержимое потока при 16-битном сампле и отсоединенном микрофоне - там разброс значений присутсвует. По крайней мере их, в отличие от 8-битных сэмплов, гораздо больше двух.

И еще такой вопрос. Можно ли по-простому 16-битный самл по какой-нибудь формуле преобразовать в 8-битный? Т.е. не перекодируя поток через звуковые функции, а просто рассчитать. Т.е. на тот случай, если, все-таки, читать с микрофона 16-битные, а чтобы в WAV-файл писать, все-таки, 8-битные.

somewhere · 18 янв 2008, 14:06

&quot писал(а):И еще такой вопрос. Можно ли по-простому 16-битный самл по какой-нибудь формуле преобразовать в 8-битный? Т.е. не перекодируя поток через звуковые функции, а просто рассчитать. Т.е. на тот случай, если, все-таки, читать с микрофона 16-битные, а чтобы в WAV-файл писать, все-таки, 8-битные.

Очень просто, достаточно взять только старший байт 16 битного слова. Демку кстати написал, в спокойном состоянии разброс +- 15. Микрофона на работе нет, сегодня дома проверю. Еще при втыкании чего либо в вход микрофона (колонок например) образуется сильный скачок, даже если аккуратненько так задвигать, все-рано скачок присутствует. В принципе еще один кретерий. А в аудиокартах некоторых все банально, там просто в самом конце гнезда датчик стоит, который замыкаеться. Куда демку кинуть?

BBB · 18 янв 2008, 15:38

somewhere писал(а):Очень просто, достаточно взять только старший байт 16 битного слова.

Похоже, кстати, не все так просто. Я заметил, что при 8-битном сэмпле "тишина" представлена байтами 7F и 80, а при 18-битном сампле значения в районе 0001, 0002, 0003, FFFF, FFFE и т.д.

Некоторое время назад канался с перекодирокой WAV в lame MP3, долго был в трансе, почему WAV с записью тишины преобразуется в MP3 с постоянным жутким треском-шорохом. Нашел исходники этого дела (на http://www.free-codecs.com/download/LAME_ACM_Codec.htm). Там есть EXE-шка (lame.exe), которая отлично перекодировала и эта DLL, которая тупила. Прошелся отладчиком, увидел, что оба варианта в итоге сходятся на одну процедцры, сравнил разница в получаемых ею данных потока. В общем, у меня получилось, что на вход lame_enc.dll надо подавать именно двубайтные значения. И формула там получалась (на паскале):

_int = ((_byte^) XOR $80) shl 8 OR $7F;

Т.е.
80h -> 007Fh
7Fh -> FF7Fh

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

Сдалал подобное преобразование перед вызовом ф-ии перекодирования из lame_enc.dll - все отлично получилось. Т.е. - тишина, а не шум.

Демку кстати написал, в спокойном состоянии разброс +- 15. Микрофона на работе нет, сегодня дома проверю. Еще при втыкании чего либо в вход микрофона (колонок например) образуется сильный скачок, даже если аккуратненько так задвигать, все-рано скачок присутствует. В принципе еще один кретерий.

Ну, скачек, наверное, дело такое... Не ясно же, от чего именно он случился - от втыкания/вытыкания.

Куда демку кинуть?

Можно и сюда в архиве приаттачить, если получится. Если нет, в привате e-mail сообщаю.

somewhere · 18 янв 2008, 15:59

Вообще-то да, но можно проще
Value8 := (Value16 shr 8) + $80;