Перейти к содержанию
    

vs1011 щелчки при переключении треков

VS1011E При прерывании трека в произвольном месте и начале воспроизведения другого файла даже при осуществлении программного сброса появляется щелчек(иногда) думаю что это остаток от предыдущего файла в выходном буфере. Как рекомендует ANotes после останова загружаю 2048 нулей, затем softreset. Результат такой-же. Кто нибудь сталкивался или это я что-то не так делаю?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

и начале воспроизведения другого файла даже при осуществлении программного сброса появляется щелчек(иногда) думаю

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Дело происходит так: после остановки воспроизведения в произвольном месте фрагмента и остановки все нормально, затем перегружаю vs1011 как написано в рекомендациякх по применению изаливаю туда нули. После паузы любой длительности стартую другой файл или этот-же файл и слышу вначале "щелчек" как-будто этот отрезок остался от прошлого фрагмента в буфере но не вышел из него( FIFO не выплюнул его)/

Пока обошел проблему плавным снижением громкости в ноль перед остановом одного фрагмента, и начинаю поднимать после старта следующего, при этом щелчек происходит в районе громкости 0 и его неслышно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

слышу вначале "щелчек" как-будто этот отрезок остался от прошлого фрагмента в буфере но не вышел из него( FIFO не выплюнул его)/

Пока обошел проблему плавным снижением громкости в ноль перед остановом одного фрагмента, и начинаю поднимать после старта следующего, при этом щелчек происходит в районе громкости 0 и его неслышно.

Думаю, вы слышите переходной процесс , при переходе от нуля к первой "цифре" нового файла.

И если, просто снизите громкость в начале , щелчек тоже заглушите.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Щелчек - это и есть переходной процесс)), которого не должно быть. Четко прослеживается зависимость от того в каком месте прерываемого файла произошел останов. Если это происходит в "тихой" части файла, тогда щелчка или нет, или он очень малозаметен(нет цифрового осцилла не могу посмотреть). В Случае останова на "громком" участке в большинстве случаев(не всегда) слышны как раз переходные процессы. Но нигде не видел упоминания о таком эффекте... либо о том как можно очистить выходной буфер этого декодера. Есть фраза о загрузке нулями в размере 2048 байт после остановки пакетами по 32байта по запросу от декодера и перед воспроизведением следующего файла для устранения переходных процессов, но если я все правильно делаю - это не помогает...

Кстат первая "цифра" следующего файла должна быть равна нулю( всегда пытаюсь так делать при подготовке файлов) как собственно и последняя. для нормального воспроизведения "по кругу".

Изменено пользователем Григорий2000

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Есть фраза о загрузке нулями в размере 2048 байт после остановки пакетами по 32байта по запросу от декодера и перед воспроизведением следующего файла для устранения переходных процессов, но если я все правильно делаю - это не помогает...

Кстат первая "цифра" следующего файла должна быть равна нулю

Так может попробовать "плавный переход" в размере 2048 байт от последнего значения к первому?

А какому нулю , цифровому или аналоговому? Я думаю , что "ноль" должен быть равен половине питания.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

самое интересное что после прерывания трека и загрузке 2048 нулей во входной буфер, я так понял что выходной буфер при этом не очищается, а очищается только входной(это mp3),

так как я вижу в ходе эксперимента может пройти сколь угодно много времени после окончания воспроизведения старого трека до начала новго трека.

И в начале этого воспроизведения выплюнется именно этот щелчек( ряд отсчетов в выходном буфере оставшийся от предыдущего трека). используя также softreset ничего изменить неудалось...

Конечно ведя речь о нуле имется ввиду не абсолютное значение выходного ЦАП.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Кстати, не подскажете, уважаемые.

Вот только думаю заняться воспроизведением музыки с помощью VS1011e.

 

Файл .mp3 можно с какого места "кидать" в декодер - прямо с самого начала (вместе с заголовком, тэгами и т.д.), или заголовок необходимо откинуть и передавать только сжатый аудио поток?

 

Ещё вот интересно, кто-нить на АРМе типа STM32 напрямую, безо всяких декодеров, воспроизводил mp3?

Стоит ли заморачиваться с софтом, по силам ли ему такое, если учесть, что кроме самого воспроизведения он будет выполнять роль системного контроллера с доп. задачами?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

VS1011E При прерывании трека в произвольном месте и начале воспроизведения другого файла даже при осуществлении программного сброса появляется щелчек(иногда) думаю что это остаток от предыдущего файла в выходном буфере. Как рекомендует ANotes после останова загружаю 2048 нулей, затем softreset. Результат такой-же. Кто нибудь сталкивался или это я что-то не так делаю?

Такая же фигня получается.

 

После прерывания воспроизведения трека в произвольном месте начинаю воспроизводить следующий - и сразу отчётливо слышно не то что щелчок - а кусок предыдущего трека, длиной в несколько сотен миллисекунд.

 

Аналогично, выдача 2048 или любого другого кол-ва нулей перед загрузкой нового трека не помогает.

Однако нашёл случайно выход, не затрагивая управление громкостью - вместо нулей передаю декодеру 2 килобайта памяти программ (флеша) :biggrin:

Пытаясь декодировать код контроллера, декодер благополучно очищает буфера ЦАПов :laughing:

 

Ну а вообще, конечно, финнам за такой ляп по голове надавать нужно.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Хе, сделал проще - не стал вообще закачивать нули перед окончанием трека.

Просто прекращаю передавать данные, и жду сотню-другую миллисекунд.

Вуаля - буфер ЦАПов очищается и они автоматически глушатся.

 

Получается, что при передаче 2048 нулей DSP останавливает ЦАПы до того, как они успевают вывести весь выходной буфер.

И очищает входной.

 

А что получается, когда мы просто перестаём передавать данные?

Имхо, декодер дочитает байты из входного буфера и остановится, ЦАПы, в свою очередь, тоже выгребут все готовые семплы и отключатся.

 

Вуаля - всё чистенько, при воспроизведении след. файла никаких хрипов и старых остатков :yeah:

И не надо никаких нулевых байтов :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вуаля - всё чистенько, при воспроизведении след. файла никаких хрипов и старых остатков :yeah:

И не надо никаких нулевых байтов :)

Т.е сегодня воевать финнов не будем :smile3009: :maniac: ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Т.е сегодня воевать финнов не будем :smile3009: :maniac: ?

Письмо им я всё равно написал.

Интересно, что подскажут.

 

Жаль, нет на их сайте форума, только имэйл для помощи...

 

Имхо, косяк всё же за ними.

Столько лет производят свои декодеры, а до сих пор нет очистки буфера ЦАПов при софтовом сбросе!

Стыд :(

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вот что мне ответили на мой вопрос тех. саппорт VLSI:

>I think this is samples of the last track, which remains in audio DAC

>buffer untouched even after 2048 zeros and software reset.

>

Software reset clears the audio buffer, and if there is no data to be

decoded, zero samples are inserted. Software reset clears the whole

memory, so the windowing history buffer should also be cleared.

 

Говорят, что вся память очищается при софтовом сбросе.

 

Однако фактически это не так.

 

Интересно, такая трабла только с 1011 чипом, а другие (1033, 1053) работают ОК?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

У 1033с такой проблемы пока не заметил

То есть, следуя рекомендациям, пересылаешь 2048 байт нулей, затем софт сброс и передача след. трека?

 

У меня тоже есть 1033 - лежит в коробке в корпусе LQFP 48.

А на макетку впаял 1011 в SOIC28 - легче паять.

На плату, возможно, тоже поставлю 1033.

 

Но выход нашёл простой - вообще не шлю нули, просто пауза 50-100 миллисекунд и софт сброс.

Никаких шумов :)

 

Сейчас спросил у финнов, что за дела такие и как это понимать.

Упорствуют, что память всенепременно очищается при сбросе... :)

 

Кстати, что такое "history window buffer"?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...