Вид для печати
Имеется в виду запись в регистры ЦАП, как часто они способны менять своё значение? Из доки по оным сопрам следует, что они способны менять своё состояние чуть не каждые 1/2 такта CLK.
Вопрос связан с тем, что попытка выводить в эти регистры значения с частотой превышающей 19-20 кГц приводит к возникновению непонятного "хрипа" на выходе ЦАП.
не на скорпионе ли случаем?
Где это ты там такое вычитал?Цитата:
Сообщение от GriV
Впрочем, думаю, что вполне могут, и проблема у тебя не из-за этого.
Да, именно на скорпионе, однако это не ответ на вопрос...Цитата:
Сообщение от jtn
Не где, а в полном описании YM2194 от Yamaha, это естественно, откуда ещё могут быть такие данные? :`(Цитата:
Сообщение от Shiru
А про ваиты на M1 с выравниванием кол-ва тактов команды до чётного - ты в курсе?Цитата:
Сообщение от GriV
на скорпе все нечетнотактовые команды округляются до четных, отсюда и получается офигительный джиттер (частота плавает). попробуй переписать вывод оцифровки в четнотактовых командах.Цитата:
Сообщение от GriV
2194? Это ещё что?;)Цитата:
Сообщение от GriV
Я смотрел в даташите на AY3-8910, там таких тонкостей нет..
Я знаю, что есть такой глюк, однако не понял я при чём тут YM и вывод в его ЦАПы, тут речь идёт не про то, что звук идёт (ну имеется в виду вывод оцифровки конечно) то быстрей то медленней, такие нюансы как округление до чётного такта я учитывал, речь про то, что появляется именно хрип, не знаю как его ещё назвать, в общем идёт тот же звук, однако имеено как будто поверх его ложится какой то хрип.Цитата:
Сообщение от jtn
С другой стороны, даже если отбросить тот нюанс, что я выравнивал по тактам на чётнотактовые команды, то получается следующее: частота собсно звук.проца = 1,7 МГц (округлённо), в то же время частота выводимых данных окло 20кГц - мне кажется что порядок величин настолько несопоставимый, что программно образованный джиттер не внесёт такой задержки, чтобы она была заметна на слух
хватает, это чтобы предположить, что по какой то причине ЦАПы сбиваются - собственно оттуда и этот хрип...
Чтото вроде того, что вывод значений пришёл когда сопр находился в каком то состоянии, что он был неспопобен адекватно принять переданные данные...
Возможно проблема в триггерах регистров R8-RA?
хм... посмотрю дома доку, что-то не верится.Цитата:
Сообщение от 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 расширял (бОльший запас точности), ничего не помогало, тогда меня это не больно волновало, сейчаз же вопрос стал ребром...
Во-первых да, надо учитывать, что у АУка шкала громкостей логарифмическая (точнее, кусочно-линейная аппроксимация к оной - это хорошо видно на осциллографе), а кроме того, ты генерацию тона отрубаешь ли? Может он у тебя на макс. частоте работает (этого не слышно, естественно, но вдруг как-то на усилитель-етц влияет?)...Цитата:
Сообщение от GriV
в том числе (с учётом тем не менее того, что я сам знаю конечно) Instrument и подобные ему программы... Так что нет там генератора, даже если бы он был, почему на более низких частотах вывода хвука его не слышно?
Тогда хз. Остаётся только смотреть осциллографом (покрмере я бы уж давно им ткнулся =)Цитата:
Сообщение от GriV
Кстати, дельное замечание! Если ты работаешь с АЦП АУ'ка то в обязательном порядке перед началом вывода оцифровки УСТАНОВИ биты 0-5 регистра 7 в состояние "1", тем самым ты запретишь влияние на выходной сигнал генератора тона и генератора шума. Так же не забывай, что при выводе бит 4 регистра 8(9,10) не должен устанавливаться в "1", иначе к выходному сигналу примажется генератор огибающей! Вообщем, запиши в регистр 7 число 63 и поизменяй значения регистров 0-6. Если характеристики выводимого звука не будут меняться, то генератор тона и генератор шума тут не при чем!Цитата:
Сообщение от lvd
Есть такое понятие, как резонанс. Если окажется, что сигналы от внутренних генераторов влияют на выходной сигнал АЦП, то резонанс в определенном диапазоне частот дискретизации вполне реален (но это мои чисто теоретические соображения)! В этом случае попробуй немного изменить частоту дискретизации либо поэкспериментируй со значениями регистров 0-6 и 11-13!Цитата:
Сообщение от GriV
однако же всё таки датаграмму работы я сделал
Вот оно в архиве приложено, я специально написал программу, которая бы выводила уровни громкости - от 0 до 15 - пробегая последовательно значения - и формируя на ЦАПе соответствующие уровни. (управляющий регистр номер 7 отключал = #FF; пробовал менять другие регистры, стабильно картина наблюдается одинаковая - из раза в раз)
Записывал на SB Live! 5.1 - может быть этот агрегат сам даёт помехи, но вот факт - после значени "15" переход в значение "0" сопровождается жуткими переколебаниями - причём ещё до старта перехода (джиттер внутри звукахи?). Малые значения тоже сопровождаются переколебаниями (видно опять же таки по графику) - причём сами переколебания значений происходят и в середине уже установленного значения.
В общем разумно я объяснить это не могу (есть только одно чувственное наполнение ситуцации - бред какой то :D), потому что длина переколебаний соответствует частоте около 8 кгц (квантование приведённого сигнала идёт на частоте 48 кгц, занимает же переколебание около 6 замеров). Может быть дело в ёмкостях которые стоят на выходе AY-ка?
Кстати подобными помехами обладал не только выводимый мной сигнал, так же и простые FM-музоны тоже давали помехи (сампл не стал приводить, думаю он просто не нужен), однако они неплохо маскируются на общем фоне (их почти не слышно).
P.S. Понятно что усислитель звукахи, ёмкости звукахи, провод от спекка до звукахи т.д. вносят свою погрешность, но то что и без звукахи хрип был, это факт...
P.P.S. Как то в ревюшках было написано цитата <<цитата:"И звук хороший.." - А что бывает и плохой? Оказывается бывает..>> - речь шла про AY. Может именно это и имелось в виду?
И всё же покажи схему, как сделан выход с АУка! И заодно осциллограф у кого-нибудь выпроси нормальный, им глянь...Цитата:
Сообщение от GriV
эххх придётся лазить в схему ;)Цитата:
Сообщение от lvd
посмотрю...
А осциллограф я в руках держать не умею ;)
Тогда пусть его в руках владелец держит. И ручки крутит =)Цитата:
Сообщение от GriV
Hемедленно нажми на RESET, Valery Grigoriev!
On Mon, 07 Nov 05 13:36:29 +0300, Valery Grigoriev wrote:
Дело в индуктивностях проводов. Смотри осциллографом с нормальнымЦитата:
Записывал на SB Live! 5.1 - может быть этот агрегат сам даёт помехи, но вот
факт - после значени "15" переход в значение "0" сопровождается жуткими
переколебаниями - причём ещё до старта перехода (джиттер внутри звукахи?).
Малые значения тоже сопровождаются переколебаниями (видно опять же таки по
графику) - причём сами переколебания значений происходят и в середине уже
установленного значения.
В общем разумно я объяснить это не могу (есть только одно чувственное
наполнение ситуцации - бред какой то :D), потому что длина переколебаний
соответствует частоте около 8 кгц (квантование приведённого сигнала идёт на
частоте 48 кгц, занимает же переколебание около 6 замеров). Может быть дело в
ёмкостях которые стоят на выходе AY-ка?
щупом -- такого не должно быть.
на частоте 48кгц????
Не должно там влияние отражённой волны быть. Если бы там мегагерцы были....
Схему я рассмотрел,
там три канала микшируются на сопротивлениях, так что если где есть ёмкость или индуктивность, то это в самой сопре AY или в звукахе, на которой цифровалось. Одна последний вариант мне кажется маловероятным - ну не может быть чтобы производитель выпустил настолько ущебный продукт - который может штатно записывать в таком режиме и при этом подавать такие жуткие помехи.
Отсаётся только AY (у меня на самом деле YM) винить.
ПРОСЬБА. У кого есть возможность проведите аналогичные замеры и выложите самплы!
З.Ы. Длина провода была 14 метров, может быть на самом деле влияние эха.... Я попробую с более коротким проводом сделать....
З.Ы.Ы. на каждый отсчёт 48 кгц сигнала там приходилось по одному переколебанию, итого около 21 мкс на длительность одного отражения (если рассматривать как вариант, что помехи наводит отражённая волна). 21 мкс отнесённая к скорости прохождения волны по кабелю (=скорость света в вакууме ;)) - будет около 6,5 км туда сюда волна должна пробежать, т.о. кабель должен иметь длину 3,25 км. Кажется кабель у меня чуток короче ;)))))
Это не производитель, а пьяный китаец в подвале. ;)Цитата:
Сообщение от GriV
Кста ткнись картошкой прямо на выходы АУ, до резюков. Там точно нормальный сигнал (проверял осциллоглядом у себя).Цитата:
Отсаётся только AY (у меня на самом деле YM) винить.
херовый сигнал на выходе? Квак так???
В смысле что тогда сомнений не останется, что именно такая у тебя звуковуха. =)Цитата:
Сообщение от GriV
В смысле а после сопротивлений и после кабеля сигнал искажённый так же???Цитата:
Сообщение от lvd
Hемедленно нажми на RESET, Valery Grigoriev!
On Sat, 12 Nov 05 04:16:04 +0300, Valery Grigoriev wrote:
Цитирую письмо полностью:
Я нихрена не понял.Цитата:
Hello, lvd
херовый сигнал на выходе? Квак так???
... GriV aka Valery Grigoriev
Hемедленно нажми на RESET, Valery Grigoriev!
On Fri, 11 Nov 05 21:18:21 +0300, Valery Grigoriev wrote:
1. Меньше скорости света.Цитата:
вариант, что помехи наводит отражённая волна). 21 мкс отнесённая к скорости
прохождения волны по кабелю (=скорость света в вакууме ;)) - будет около 6,5 км
туда сюда волна должна пробежать, т.о. кабель должен иметь длину 3,25 км.
Кажется кабель у меня чуток короче ;)))))
2. С длиной кабеля оно не связано.
прохождения сигнала, которая принимается равной скорости света это связано. Стоячая волна повляется (точнее не тухнет а отражается) если выходы провода нескомпенсированы активным сопротивлением равным волновому сопротивлению провода (а волновое сопротивление связано с индуктивностью и ёмкостью проводов). Именно потому (может кто помнит? ;)) на коксель от компов, волновое сопротивление которого равно 50 ом, на концы вешали заглушки-резюки (тоже по 50 ом;)). Именно поэтому ограничением для 10MBit Ethernet является 2,5 км провода - чтобы надёжно детектировать помехи и отражённые волны.
А смысл такой - квак так может быть чтобы столь короткий провод формировал столь большие помехи - рядом ведь электросварка не идёт, и нет никаких мощных потребителей энергии (читай: наводчиков помех).
Я и прошу потому - если у кого есть возможность - запищите временную диаграмму.
Нифига не поэтому. Это произвольная длина, связанная с временем ожидания коллизии с момента окончания передачи пакета. Т.е. это время такое, что в него с 2.5км гарантированно успеет другой передатчик прийти, если он начал что-то передавать. Если сделать больше - то будут моменты, когда коллизия была, но передатчик об этом не узнал -> он посчитает пакет переданным, а он в каких-то точках может быть не принят (испортится из-за коллизии). В результате будет коматоз.Цитата:
Сообщение от GriV
В реальности ещё играет роль и ослабление и искажение сигнала по кабелю.