Привет! Вот блог Кайта,
Добро пожаловать, чтобы общаться со мной.
Это была очередная яма цифровых наушников, и я снова с ней столкнулся, увы. . .
Обратная связь теста: объективный тест, громкость исходящего вызова цифровой гарнитуры не соответствует стандарту (не обязательно присутствует, очень высокая вероятность).
Поскольку я производитель мобильных телефонов, существует так много сценариев для мобильных телефонов, и они напрямую ориентированы на пользователей, поэтому проводится множество тестов, и также учитываются чувства пользователя. . . . .
Здесь он делится на субъективный тест и объективный тест:
Субъективный тест: инженер по оценке звука надевает цифровую гарнитуру для разговора и лично ощущает качество звукового эффекта звонка.
Объективный тест: поместите мобильный телефон в аудиолабораторию (с моделью головы человека), повесьте наушники на искусственное ухо, повесьте микрофон гарнитуры на искусственный рот и используйте машину для тестирования.
Затем в лаборатории есть псевдобазовая станция.Мобильный телефон использует белую карту для совершения звонков.Данные о звонке будут захвачены псевдобазовой станцией и их можно будет увидеть интуитивно.
Тест дал мне обратную связь, что громкость восходящего канала не соответствует стандарту. Но субъективные тесты не имеют этой проблемы.
Это тоже телефонный тест, субъективный тест не воспроизводит, а объективный тест воспроизводит? ? ? это шутка
Хорошо, если громкость не соответствует стандарту, это должно быть связано с тем, что усиление установлено неправильно или кривая громкости не отрегулирована должным образом, тогда возьмите для меня журнал, и я посмотрю.
В итоге тест сказал мне второе предложение: лога нет, так как после запуска инструмента MTKlog (DebugLogger) для захвата лога проблема больше не повторится.Если лога нет, что анализировать
? ? ?
Потом я поболтал с другими тестами, проблема должна быть в беззвучном звонке или в неслышимой тишине из-за слишком маленького усиления?
Вот это меня опять сильно смутило, это несколько проблем, никак не получается, ни один лог не анализировать, могу только ру с тестом, а потом пробовать ловить лог, прошу усилить усилия! ! !
Поскольку MTKlog фиксирует множество вещей, попробуйте захватить только часть журнала. Записывать только мобильный журнал, только записывать журнал модема, только записывать журнал ВМ, только записывать мобильный журнал + журнал ВМ, только записывать...
Поскольку алгоритм вызова использует трехсторонний алгоритм, я также попросил людей из трех сторон вместе рассмотреть эту проблему.
Поймав наконец лог, я обнаружил, что aurisys был обойден в ADSP, то есть в ADSP нет алгоритма трехстороннего вызова, из-за чего может возникнуть проблема с настройкой усиления ul.
MTK считает, что вам нужен журнал загрузки, чтобы знать, почему ADSP будет обходить.Боже мой, это достаточно сложно поймать журнал, как я могу получить журнал загрузки для вас.
Я продолжил ловить и поймал еще один лог.В этом логе ADSP не сообщил об ошибке, но дамп алгоритма вызова я не поймал, поэтому доказать, была ли проблема с алгоритмом, я не смог.По крайней мере в этом журнале не было проблем с ADSP.
Никак, я могу найти путь только из алгоритма вызова, пытаюсь использовать параметр bypass в алгоритме, но так и не могу решить эту проблему, поэтому алгоритм считает, что эта проблема не имеет ничего общего с алгоритмом вызова .
Поскольку открытие журнала приведет к тому, что проблема не будет повторяться, поэтому угадайте причину проблемы, а затем снова и снова изменяйте тест, чтобы увидеть, можно ли решить проблему, а затем попытайтесь поймать повторяющийся журнал. В результате было задействовано слишком много испытательной рабочей силы, и испытание также раздражало. . . . . .
Увы, у завода по производству мобильных телефонов есть эта проблема, темпы быстрые, и прошло всего несколько дней, и ее призвали решить. Меня призывают каждый день, и тест раздражает. Нет рабочей силы. Мне нужно разработать его самому и пойти в лабораторию для тестирования. . . .
Из-за отсутствия эффективного лога ход анализа действительно не очень хороший, аудиолаборатория находится за городом, поэтому я могу сделать это только сам! ! Мои исследования и разработки на самом деле хотят, чтобы я отправился в командировку со слезами на глазах. . .
После того, как я поехал в лабораторию в командировку, я попробовал это сам, и это было действительно потрясающе! ! Аномалию можно воспроизвести, не открывая журнал, и она не будет воспроизводиться после открытия журнала.
Сначала я подумал, что это вызвано проблемой производительности, и это не сработало после включения режима высокой производительности телефона.
Тогда я могу использовать только окончательное решение.Метод отладки высокого класса часто представляет собой простую команду:
adb shell logcat > D:\log.txt
В итоге нет, сэр, я просто logcat ловлю лог, и он больше не воспроизводится. . . Это действительно самая метафизическая проблема, с которой я когда-либо сталкивался.
Затем я подошел к прибору, чтобы проверить. Данные восходящего вызова, захваченные псевдобазовой станцией, были прямой линией. Это действительно казалось проблемой тишины. Я думаю, это не должно быть связано с громкостью, это должна быть тишина. .
Потом я присел в лаборатории и почесал лог, и наконец нашел нужный путь:
- 1.adb shell logcat > D:\log_first, чтобы начать сканирование
- 2. Звонок (звонок нормальный в это время)
- 3. Ctrl-c отменяет захват logcat (вызов не зависает)
- 4. Подождите несколько секунд
- 5. Продолжайте logcat оболочки adb > D:\log_second, чтобы получить журнал.
- 6. В это время проблема снова появляется ,
когда вызов ненормальный.
Какое это имеет отношение к включению и выключению экрана?
Просмотрите log_second, найденный в этом журнале:
AudioUSBPhoneCallController: speechULThread(), proxy_read failed, ret -1, fail due to cannot read stream data: Streams pipe error, writeTimes 1249, fill mute data
AudioUSBPhoneCallController: speechULThread(), proxy_read failed, ret -1, fail due to cannot read stream data: Streams pipe error, writeTimes 1250, fill mute data
AudioUSBPhoneCallController: speechULThread(), proxy_read failed, ret -1, fail due to cannot read stream data: Streams pipe error, writeTimes 1251, fill mute data
Похоже, звонок действительно молчит, и это никак не связано с громкостью усиления, потому что звонок UL не получает данные от цифровой гарнитуры, поэтому звонок по восходящему каналу молчит.
Проверьте журнал ядра дальше:
[ 2915.631642] (1)[18169:usb_call_ul]usb 1-1: start in data endpoint #81
[ 2916.152638] (2)[18169:usb_call_ul]usb 1-1: stop in data endpoint #81
[ 2916.162986] -(2)[18169:usb_call_ul]usb 1-1: start in data endpoint #81
[ 2916.644130] (4)[18169:usb_call_ul]usb 1-1: stop in data endpoint #81
[ 2916.654690] -(4)[18169:usb_call_ul]usb 1-1: start in data endpoint #81
[ 2917.168865] (4)[18169:usb_call_ul]usb 1-1: stop in data endpoint #81
Нашел цифровую гарнитуру, USB постоянно подключается и отключается! ! !
Похоже, что это имеет много общего с USB, а то я синхронизировал ход проблемы с коллегами по USB, черт возьми! Он действительно знает этот вопрос! ! !
Сторона USB сказала: мобильный телефон используется как хост.После того, как otg вставлен, система будет держать wake_lock и система не будет переходить в сон после выключения экрана.Поэтому, чтобы уменьшить энергопотребление системы , система больше не будет удерживать блокировку wake_lock после перехода в закадровый режим. , система перейдет в спящий режим.
Итак, я сказал, почему журнал часто отключает USB! ! !
Тогда попробуйте откатить патч USB или используйте
echo test > /sys/power/wake_lock
Сделайте тест блокировки, проблема не повторяется, она решена.
Увы, это слишком плохо, чтобы снова быть виноватым.Окончательное решение - добавить блокировку в Audio HAL во время вызова, чтобы гарантировать, что система не будет спать.После прохождения проверки патча эта проблема наконец-то ушла.