умылся просто

Ой, а позвольте еще один вопросик.

Тут мне что-то совсем не понятно.
Шим не может сделать на выходе "переменку"... На выходе получаем все ту же кривую ( синусоиду например ), но смещенную в положительную сторону.
Для того что-бы сделать сигнал не смещенным, то нужно использовать специальные схемы на p-n-p + n-p-n транзисторах
ну либо применять специальные микросхемы.
Вроде-бы как то так...
Но микроконтроллер это делать не умеет. И тишина в динамиках будет при скважности 100%
( при условии, что ШИМ не инвертированный, скважность 100% = аналоговому нулю. )

А-а, или вы предлагаете принять за середину ( за нуль ) ШИМ с 50% коэффициентом заполнения ??? ( при питании 5V получится 2,5 V )
Для того что бы колонки могли играть в обе стороны? Нужно сымитировать переменку?
Хм. Хитро...

не забывайте, что ШИМ вы обязаны отфильтровать LC-фильтром, иначе такое услышите...
но если использовать частоту ШИМ вне звукового диапазона, о чем я и намекал (для МК со встроенными PLL есть смысл выжимать все 250 кГц), то сама катушка динамика будет неплохим фильтром - с частотой 250 кГц она колебаться не сможет физически, и от фильтра можно отказаться: когда вы подадите на нее меандр - она будет просто неподвижной, хотя через нее будет течь какой-то ток. это не самый экономичный режим, но зато самый простой.

таким образом амплитуда ШИМ будет от 0 до 255, но на динамике она превратится в от -127 до +127.

Приполз с работы домой и еще пару вопросов придумал.
( А может мне просто пообщаться хочется? )

1)
А если частота дискретизации не 4 кГц, а скажем 44100 Гц.
44100 Гц - это частота вне звукового диапазона.
Есть ли смысл делать частоту ШИМ более высокой или можно сделать ее равной частоте смены смены данных в ШИМ ???
С одной стороны упростим решение задачи, а с другой стороны увеличится массив данных.

2)
.
Тут поясните пожалуйста.
Данные у меня в виде от 0 до 255.
Звук когда-то был аналоговым сигналом, и после того как АЦП его обработал, звук превратился в данные от 0 до 255 ( это при условии, что АЦП восьмибитный - в нашем случае так оно и есть )
Байтом содержащим 0, стала самая нижняя точка по графику аналогового сигнала. ( самый возможный пик отрицательной полуволны )
Байтом содержащим 255, стала самая верхняя точка по графику аналогового сигнала. ( самый возможный пик положительной полуволны )
Соответственно байтом содержащим ~128, стала точка лежащая на нуле аналогового сигнала.
В таком случае, амплитуда ШИМ будет от 0 до 255, но на динамике она превратится в от -127 до +127. ( И через динамик будет постоянно течь какой-то ток, даже при отсутствии сигнала.. )
И что-же мне мешает в готовом виде выводить эти данные в ШИМ?
Или Вы это и имели в виду? Получается, что мои данные уже отнормированы?

Я если честно другого варианта тут и не вижу...

1. частота сэмплирования определяет предельно возможную частоту в спектре вашего сигнала. если частота семплирования у вас 44,1 кГц это означает, что в сигнале может присутствовать частота вплоть до 22,05 кГц, не более. иначе говоря, частота семплирования определяет "качество" звука. к частоте ШИМ, который выполняет роль ЦАП в данном случае, это относится ровно в той мере, о чем я уже писал: ШИМ не может быть меньшей частоты, чем частота семплирования, но может быть сколь угодно большей частоты.

2. смысл высокой частоты ШИМ я вам объяснял: высокую частоту легко можно отфильтровать, в частности, частоту около 256 кГц можно вообще не фильтровать - динамик ее отфильтрует "естественным" образом. если частота ШИМ больше 20 кГц - уже можно пробовать отказываться от фильтра - на неаудиофильский слух результат может быть приличным. Если ШИМ имеет меньшую частоту - фильтр обязателен, иначе в звуке будет много лишних призвуков, вплоть до постоянного писка или свиста.

3. задайте сами себе вопрос: если у вас в файле записана тишина - какие данные будут в файле? очевидно, что нули - верно? но для того, чтобы динамик молчал, на него надо подавать 50% ШИМ, что для диапазона однобайтного значения соответствует числу 127. то есть в файле 0 - на ШИМ выдаем 127. когда в файле будет самый громкий звук, то число в файле будет от -127 до +127, а на ШИМ подастся соответственно 0 или 254.

если у вас в файле данные хранятся в виде signed short int (или int8_t), перед выводом на ШИМ вы должны просто прибавлять к каждому байту число 127 - вот и все "нормирование". ну или, что то же самое, вычитать из 127 каждый байт файла перед выдачей в ШИМ.

андерстенд?

P.S. на самом деле, если мы говорим о ШИМ в микроконтроллерах AVR, следует учитывать, что FastPWM при задании 0-го уровня (или уровня 255 - это смотря по варианту "прямого" или "инверсного" выхода) будет давать не совсем корректный сигнал. поэтому следует нормировать данные в файле так, чтобы максимальное значение никогда не достигало значения 255 - достаточно остановиться на уровне в 250. тогда нулю будет соответствовать ровно половина, т.е. 125, и в коррекции вместо 127 вы должны будете использовать именно это значение. динамический диапазон слегка сузится, но для 8-битного звука это практически ничего не изменит...

Нет, не согласен и не очевидно.
Я же в предыдущем сообщении написал, что после обработки АЦП аналоговому нулю будет соответствовать число ~128.
Что-бы не быть голословным, я только что записал тишину и конвертнул файл ( программой от smacorp ) .
Получился массив заполненый числами 0x80
вот:
Но все равно спасибо за пищу для ума.
Сам спросил - сам ответил. Как говорили выше - так лучше запоминается.

Это я понял.
Спасибо за то, что пытаетесь разъяснить это еще раз.
Мне просто стало интересно, что если частота ШИМа будет равна частоте семплирования.
Таким образом отпадает необходимость во втором таймере.
А данные можно будет обновлять по прерыванию, которое будет генерироваться компатором того-же таймера на котором построен наш ШИМ.
И данные можно будет обновлять каждый периуд ШИМа.
Это плюс.
Но из минусов то, что данных ( аудио ) станет намного больше....
И скорее всего выгоднее ( памяти в МК AVR не шибко много ) запускать ШИМ на более высокой частоте, а звук генерировать на частоте 4-8 кГц.

А вот это очень хорошая идея! Спасибо а подсказку!

ну, значит у вас уже отнормированы данные - откуда мне знать было?
обычные знаковые числа так не кодируются

Спасибо, ARV за приятное общение!
Сообщение выше я откорректировал - добавил кучу текста

Да я и сам не знал. Просто по Вашему совету начал логически рассуждать, а затем подтвердил свои догадки экспериментом. Страницей ранее мне с этим вопросом помог разобраться smacorp.

когда вы пишите программу выдачи семплированного звука, вы все равно будете писать обработчик прерывания - и окажется, что все равно какого: таймера ли или того же самого таймера, но в режиме ШИМ. с точки зрения кода ничего не изменится, разве что этап инициализации чуток.

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

но принципиально, конечно, можно обновлять данные и по прерываниям от того же таймера, что генерирует ШИМ...

О-о, а это уже более развернутый ответ! Спасибо!

P.S. К новой Вашей аватаре теперь придется привыкать. А я уже привык тому мужику со стаканом.

можно сжатие аудио прмменить - AVR336: Декодер ADPCM http://www.gaw.ru/html.cgi/txt/app/micros/avr/index.htm

Это только в том случае если аудиофайл - на самом деле мелодия.
А если это код? То правильно сжать, скорее всего, ни чего не получится.
( Звук, который мы слышим когда работает модем - например )
Тут наверное проще сразу записать его как 4 кГц
А так, конечно, спасибо за совет!

сжать аудиофайл на компьютере, декодировать микроконтроллером

Много полезной информации узнал из этой ветки. Гуглил просто и нагуглил это. И впринципе то что нужно. Вдумчиво пока не смог все осилить. Да и тут слишком сложная задача была.
У меня задача стоит скопировать звук в микроконтроллер. Но мне прям нужно максимально ужасное качество получить ))) Ну тоесть чтобы звук был каплю похож на оригинал, но тратить на это куча ресурсов мк я не хочу от слова совсем.
Я не могу понять. Если у нас не сжатый звук с частотой сэмплирования 44100hz это значит что 44100 раз в секунду шлется сэмпл длиной битности звука? Тоесть если 44100hz и 32bit = (44100*4байта = ~176 кб в сек?)
Если разбирать дальше что происходит (мне просто так понятнее). Вот есть этот 1 байт звука (для 8 битного звука). 1 сэмпл как я понимаю. например там число 63 которое допустим равно 25% шима, это значит, что в этот сэмпл 25% времени этого сэмпла будет допустим подаваться напряжение и толкать мембрану какого либо динамика, а 75% времени нет.
Как я понял, например у меня есть аудио програма audcity, ей смотрю спектр. и там вижу "громкие частоты" этого звука:

Я вижу тут частоту 1200гц, но если я сэмплирование меняют на меньше чем 2500гц, то этот звук на частоте 1200гц пропадает.
Вот я пробую получить hex файл и получаю (отобразил в DEC для удобства визуального ШИМ%):

Точнее вот эти же числа в эксель и в визуальном просмотре:

Помойму я обрытно получил график звука )))
Но для меня это все еще звук высокого качества, для меня слишком много байт на такой короткий звук. Я бы хотел его сократить, буквально до 4 байт, но растянув их во времени.
Как мне из этого выдрать громкие частоты и их длительность?

Да. Но 32 бита на семпл это много. 44.1 кГц для минимально разборчивого звука - тоже. В принципе, достаточно 4 кГц 8 бит, но уже заметны искажения.

-ss, -t для вырезания нужного фрагмента.
-ar - частота оцмфровки
-acodec - количество бит на семпл. Учтите, что за исключением u8, остальные варианты знаковые.

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

Фразу не расшифровал, но, возможно, спасет преобразование Фурье - разложение последовательности семплов на набор синусоид.

Не так давно я делал демо-код воспроизведения 7 секунд wav-файла (9.6): https://karakatitsariscv.github.io/9.timers.html


Но можно и проще:


Не совсем. Частота ШИМ и частота оцифровки это разные вещи. Например, при той же 4 кГц оцифровки у вас может быть 32 кГц ШИМ, тогда на один семпл уйдет 8 периодов ШИМ. А несущую ШИМ и стоит выбирать повыше - за пределами слышимости человека. Считается, что минимум 20 кГц, но некоторые и это слышат. Поэтому опять же берите с запасом. Другое дело, что на высокой частоте может не хватить скорости таймера. Также не лишним будут и обычные аналоговые фильтры.
С другой стороны, ШИМ это ведь всего лишь дешевая замена ЦАП. Ничто не мешает для воспроизведения звука полноценный ЦАП и использовать.

если что...
в соседней теме мы передавали звук по интернету... с помощью МК
viewtopic.php?f=57&t=182976

Спойлер

Спойлер

Спойлер

Спойлер

Спойлер

и т.д.