Вид для печати
хм... посмотрю дома доку, что-то не верится.Цитата:
Сообщение от GriV
и потом для любого ЦАПа есть такой параметр как "время установки" или что-то типа того.
только там на входе F/16 стоит еще :)Цитата:
Сообщение от GriV
код показал бы, может кто протестит у себя тоже.
Выведи меандр и рассматривай его осциллоглядом, короче.Цитата:
Сообщение от GriV
это.. глупый вопрос, но... у тебя прерывания как-то юзаются? не из-за них хрип?
а в каком это месте написано ?Цитата:
что они способны менять своё состояние чуть не каждые 1/2 такта CLK.
в общем, давай код показывай.Цитата:
Сообщение от psb
однако раз уж надо то приведу:
Там была такая тема: каждый байт состоял из двух половинок,
младшая половинка есть громкость, старшая есть число повторов (кто не понял, по 4 бита каждая)
LD A,(HL)
AND 15
LD D,A
LD A,(HL)
AND #F0
LABEL1:OUT (C),D
<ВЫРАВНИВАНИЕ ПО ТАКТАМ>
SUB #10
JR NZ LABEL1
INC HL
ну и т.д.
ерунда какая-то. зачем несколько раз выводить в порт одно и тоже число? также непонятен смысл <ВЫРАВНИВАНИЕ ПО ТАКТАМ>
Каждое значение должно выводиться ровно раз в 80 тактов [раз в 80 тактов есть 44кГц] (вот тебе выравнивание по тактам), кроме того есть первый цикл, потерянный, где происходит увеличение указателя = HL, загрузка регистров = = AND #F LD D,A и т.д.
Т.о. я не стал просто расписывтаь эту ерунду, просто записал <выравнивание..> и всё..
Если сильно надо могу ОРИГИНАЛЬНЫЙ текст приложить, это мне кажется не так важно..
типа у тебя RLE еще параллельно распаковывается? (толку имхо мало для 4х битного звука)
все равно не то - меняй все нечетнотаковые команды на четные. потом проверяй.
бтв, а может у тебя сэмпл гудючий изначально? или попортился при переносе
Когда-то я сам серъезно занимался оцифрованным звуком и скажу вам следующее.Цитата:
Сообщение от jtn
Собственно говоря, вы знаете откуда берутся те самые выводимые одинаковые значения? Попробуйте сконвертировать 16-ти или 8-ми битные оцифровки в 4-х битный формат и посмотрите на результат - там действительно получается много повторяющихся цепочек одинаковых байт. А приминение RLE-подобного алгоритма - это весьма разумный подход, позволяющий сократить обьем полученой оцифровки в 2-4 раза, при этом распаковка возможна в реальном времени (слава Богу когда-то проверил все эти вещи лично)! Точная подборка времени выполнения одного прохода цикла вывода значения в порт обьясняется понятием частоты дискретизации. Чем короче цикл - тем выше частота, но частота дискретизации по возможности должна быть стабильной, а значит время выполнения одного прохода цикла - сторого подобранным, этим и обьясняется кусок кода <выравнивание по тактам>.
Да, кстати, когда-то я занимался вопросом конвертирования 8 бит оцифровок в 4 бит АЦП АУ'ка. Дело в том, что АЦП АУ'ка имеет не линейную, а логарифмическую шкалу зависимости выходного напряжения от входной цифровой комбинации. При конвертировании я использовал специальную табличку перевода 8>4 бит АУ'ка, что позволяло заметно улучшить качество сконверторованной оцифровки. Так вот, может вышеуказанные особенности АЦП АУ'ка как то влияют на качество звука при высокой частоте дискретизации?
Нет дело вовсе не в способе преобразования оцифровки (8 бит в 4 бита), потому что сам оцифровка играется нормально на других девайсах (интереса ради потом запускал на Sound Blaster на PC, так же не поленился написать опять же проигрыватель, которое выдавал это всё на ZX Beeper), нет, везде КРОМЕ AY звук шёл нормально... Один аук хрипел...
Даже таблицу конвертации переписал, ничего не помогло... Где то здесь же в форуме есть линк на спецификацию по ауку, там кстати написано распределение громокостей аука, там кстати же указано что она логарифмическая... Также я забивал более сложные таблицы конвертации (т.е. по умолчанию длина таблицы конвертации была 16 элементов, я её до 32 расширял (бОльший запас точности), ничего не помогало, тогда меня это не больно волновало, сейчаз же вопрос стал ребром...