Выбор звуковой карты

[leshk]

В этой теме выбираем звуковые карты

Пофилософствовать на тему звука можно там

Флуд наказуем и преследуется по всей строгости правил

[Radio Bay]

Та в мене з USB якраз ніяких проблем не було

Для мене теж USB найліпший та найзручніший, а зараз взагалі Jcat Femto із зовнішнім живленням

[Scoffer]

Тому теза що USB "асинхронна за визначенням і джиттер там фіча" все одно якась дивна

В чому дивно? USB за визначенням асинхроний протокол. Синхроний режим там річ в собі і для звуку все одно ніким не юзається. Псевдосинхронізація через зворотній зв'язок вона все одно псевдо: ніхто не гарантує що шина відповість за строго NN наносекунд, нема там такого. Буде хост зайнятий чимось іншим для себе цікавим, флешкою там чи принтером, і всьо, пішов по отой фідбек. Ізохроний режим гарантує пропускну спроможність, не затримки!
Якщо ти хочеш справжньої синхронізації частоти з клієнта на хост, тобі потрібен s/pdif або aes3 з зворотнім клоком по шині Word Clock або хоча б по i2s. Вордклок підтримується більшою частиною студійної апаратури якщо що, так що знайти не так вже й важко. Звуковухи i2s я теж колись десь бачив, але це більш рідкісний звір.

[feson]

Але ти вже трохи пересунув ворота не туди. Спочатку 10 мс буфер сам усе виправляв, тепер з'явився ФАПЧ, який підтягує частоту.

А як же тоді всі цапи ES9018-9039 де свій власний ген на 100мГц та технологія Jitter Eliminated?

Тобто їм все одно що йде по I2C - вони збирають це у буфер та перетактовують та двигають як потрібно?

Чи важливий USB приймач при цьому?

[NST1983]

Тому теза що USB "асинхронна за визначенням і джиттер там фіча" все одно якась дивна

В чому дивно? USB за визначенням асинхроний протокол. Синхроний режим там річ в собі і для звуку все одно ніким не юзається. Псевдосинхронізація через зворотній зв'язок вона все одно псевдо: ніхто не гарантує що шина відповість за строго NN наносекунд, нема там такого. Буде хост зайнятий чимось іншим для себе цікавим, флешкою там чи принтером, і всьо, пішов по отой фідбек. Ізохроний режим гарантує пропускну спроможність, не затримки!
Якщо ти хочеш справжньої синхронізації частоти з клієнта на хост, тобі потрібен s/pdif або aes3 з зворотнім клоком по шині Word Clock або хоча б по i2s. Вордклок підтримується більшою частиною студійної апаратури якщо що, так що знайти не так вже й важко. Звуковухи i2s я теж колись десь бачив, але це більш рідкісний звір.

Ти знов змішуєш асинхронність USB-шини з asynchronous mode в USB Audio. Feedback там і не повинен прилітати через NN наносекунд: він повідомляє середню швидкість локального клока ЦАПа, а хост потім трохи змінює кількість семплів у пакетах, FIFO пережовує решту. Це ж було)))) Ці спори ще років 10-15 тому пережували і закрили, в користь USB./

Ізохронний USB теж не просто "ось тобі смуга і їдь як хочеш" під нього резервуються регулярні інтервали на шині. А Word Clock тут взагалі інша історія: він синхронізує обладнання спільним клоком, тоді як async USB спеціально зроблений так, щоб аудіоклок ЦАПа не залежав від USB-клока.

Відправлено через 1 хвилину 39 секунд:

Та в мене з USB якраз ніяких проблем не було

Для мене теж USB найліпший та найзручніший, а зараз взагалі Jcat Femto із зовнішнім живленням

Тут навіть не треба до бабки ходить і кликати на прослушки друзів аудіофілів)

[Scoffer]

А як же тоді всі цапи ES9018-9039 де свій власний ген на 100мГц та технологія Jitter Eliminated?

Вони всі працюють точно так як я написав раніше: буфер+фапч. І це, зненацька, вирішує всі проблеми з джиттерами незалежно від джерела.

[NST1983]

А як же тоді всі цапи ES9018-9039 де свій власний ген на 100мГц та технологія Jitter Eliminated?

Вони всі працюють точно так як я написав раніше: буфер+фапч. І це, зненацька, вирішує всі проблеми з джиттерами незалежно від джерела.

От і приїхали Спочатку все вирішував буфер, тепер уже буфер+фапч. Тобто сам буфер таки нічого чарівного не робить.

[Scoffer]

NST1983
Сам буфер повністю усуває джиттер. ФАПЧ усуває іншу проблему. Що тобі ще не зрозуміло?

Відправлено через 7 хвилин 18 секунд:
ФАПЧ усуває проблему розривів. Коли в результаті розсинхронізації доведеться або повторити, або викинути кадр. Це не джиттер. У джиттера інша природа і інші наслідки.

[NST1983]

У документації виробників jitter attenuator прямо складається з FIFO + PLL, де FIFO розв'язує короткі відхилення по часу, а PLL формує клок читання і тримає середню швидкість. Тому теза що сам буфер повністю прибирає джиттер, а PLL взагалі про іншу проблему - просто не відповідає тому, як ці конструкції реально працюють. На цьому я б і закрив тему, бо це трохи інший форум і вже реально пахне шизою

[Scoffer]

jitter

Як перекладається? Дослівно. Правильно, тремтіння.

Оце - джиттер

Для розсинхронізації частоти є окремі терміни frequency offset i frequency drift в залежності від природи і наслідків. І джиттер відрізняється від них обох.
Коли частота хоста 44101 а приймача 44099 це не джиттер. Це offset. А якщо хоста 44000-44200 в різні пори року то це drift.
То шо ти змішав в купу коней і людей - виключно твої проблеми.

Відправлено через 6 хвилин 12 секунд:
Так от, джиттер лікується буфером. Самий ефективний метод. Offset i drift лікуються фапч. Буфер їм не потрібен і не допоможе. Так само як фапч не допоможе проти джиттера. Зрозуміло?

[Radio Bay]

Scoffer
От я не розумію, як, якщо ми змінили сигнал, повернемо до попереднього стану, це я про картинку джитера

[Scoffer]

Radio Bay
Уяви це собі як конвеєр на складі де з однієї сторони дядя Вася вже в хлам з самого ранку і накидує ящики як прийдеться, а з іншої твереза тьотя Люба забирає чітко коли загориться зелена лампочка. Так от ящики це пакети даних, а конвеєр - FIFO буфер. Отак і працює.

Відправлено через 1 хвилину 54 секунди:
А ФАПЧ в цій схемі це автоматичний регулятор швидкості конвеєрної стрічки в залежності від душевного стану дяді Васі. А точніше від середньої кількості накиданих ящиків на стрічці.

[Radio Bay]

Так от ящики це пакети даних

Де гарантія, що пакети стануть у правильному порядку, а тьотя Люба, не розкладе їх, як заманеться, але рівно?

[Scoffer]

Де гарантія, що пакети стануть у правильному порядку, а тьотя Люба, не розкладе їх, як заманеться, але рівно?

Тому що це труба. Буфер не перевпорядковує данні. В тому порядку в якому зайшли, в тому і вийдуть з іншої сторони за визначенням FIFO буфера.

[Radio Bay]

Тому що це труба

То я звісно розумію

[NST1983]

Scoffer

Ти походу правильно розділив jitter, offset і drift. Але ".. фапч не допоможе проти джиттера" - це вже фантазія. PLL буквально використовують як jitter attenuator: смуга петлі визначає яку частину вхідного джиттера вона пропустить, а яку приглушить. І FIFO сам по собі джиттер не "лікує" - він лише дає можливість читати дані іншим, чистішим клоком. У нормальних S/PDIF-приймачах FIFO і PLL саме тому працюють разом, а не кожен лікує якусь абсолютно окрему заразу.

Cirrus прямо описує S/PDIF receiver: elastic buffer поглинає timing variations, а PLL генерує low-jitter clock, причому вони мають бути спроєктовані разом.

А Analog Devices взагалі прямо називає PLL1 jitter attenuator і пише, що вузька смуга PLL відкидає більшу частину jitter/noise вхідного reference.

https://statics.cirrus.com/pubs/whitePa ... t_2006.pdf
https://www.analog.com/media/en/technic ... c7044b.pdf

Я ж просив, досить вже писати на оверклокерському форумі технічні деталі про які можна спорити безкінечно. SPDIF це вже застарілий спосіб передачі у порівнянні з сучасним USB. Тут люди звукові карти і цапи обирають а ти знов все зводиш до флуду і ще половину пишеш взагалі мимо.

Давай ще роз'єми обговоримо, мережевий кабель до цапа, фазу в розетці, заземлення, напрямок проводу і підставки під кабелі.

[Scoffer]

NST1983
"Читаю книгу, бачу фігу".
Вони ніде не пишуть що фапч виправляє джиттер вхідного сигналу. Вони пишуть що сама фапч у них генерує лоу-джиттер такт. Було б дуже дивно якщо б генерувала хай-джиттер. За відсутності фапч цим би займався тактовий генератор на якомусь кварцевому резонаторі.
Перестань писати бредні якщо не розумієш як і чому це працює.

SPDIF це вже застарілий спосіб передачі у порівнянні з сучасним USB.

Спочатку беруть "сучасний юсб" а потім скиглять шо він сере перешкодами по шині і треба фільтр за 250 баксів. Як-то кажуть, ССЗБ.

Відправлено через 3 хвилини 30 секунд:
Через таких от хайпожорів потім нормальної техніки не купиш
По твоєму інженери соні і філіпса просто по приколу опторозв'язку зробили? Від того що нудно жилось? А можна було взяти шнурок від принтера і отримати щастя

[NST1983]

У доках Analog Devices прямо написано, що вузька PLL використовується саме для ослаблення джиттера і фільтрує шум/джиттер вхідного клока.

Ось дивись, ти пишеш

Буфер їм не потрібен і не допоможе. Так само як фапч не допоможе проти джиттера.

і

Вони ніде не пишуть що фапч виправляє джиттер вхідного сигналу.

А тепер відкриваємо datasheet Analog Devices HMC1031

І "attenuate this incoming jitter" а вище ще пряміше "incoming noise is filtered out by the PLL and VCXO combination". Тобто в документації прямо написано що PLL-схема використовується для ослаблення вхідного джиттера, а її смуга визначає наскільки він буде придушений. Сам Analog Devices ще й в Applications вказує Low bandwidth jitter attenuation. Так ото оце вже не питання трактовки. Ти написав що ФАПЧ проти джиттера не допомагає, виробник пише протилежне. Попався яяк то кажуть, класичний та дуже болючий "Self-Own" сам себе переграв і знищив

І ще

спойлер

HMC1031 - це не конкретно S/PDIF-приймач, а спеціалізована PLL-схема для очищення clock. Тому доводить вона саме те, що PLL може використовуватися для придушення вхідного jitter, а не що будь-яка PLL у будь-якому DAC однаково добре це робить.

Через таких от хайпожорів потім нормальної техніки не купиш

Ну так, сидів би зараз на проперженому совковому кріслі, і дивився би у кінескоп, а так да - технології зло Може пора випити ліки і піти спать?

[Scoffer]

NST1983
До тебе не доходить різниця між джиттером даних і джитером самої фапч як генератора майстер/вордклоку. Бо всі генератори мають той чи інший джиттер. ВСІ. Замінюєш фапч на сталий тактовий генератор і, знанацька, нічого не змінюється. Джиттер на даних так само щезне і прирівняється до джиттера генератора. Але, можливо, залишаться розриви, в залежності від розсинхронізації вхідної і внутрішніх частот. От щоб не залишились потрібна фапч. При цьому розсинхронізації може і не бути. І тоді фапч просто простоює.

[NST1983]

Ти пишеш, що якщо замінити ФАПЧ на сталий генератор то нічого не зміниться. Ось це вже не сходиться навіть з описом реального S/PDIF receiver.

https://statics.cirrus.com/pubs/whitePa ... t_2006.pdf у своїй роботі по S/PDIF прямо пише що DPLL лочиться на вхідні дані, петля designed to attenuate jitter, а elastic buffer поглинає ту частину часових відхилень яку петля відфільтрувала. Далі PLL формує low-jitter clock для виходу.

Тобто FIFO і PLL там не живуть окремо кожен зі своєю хворобою, вони частини однієї системи. А якщо просто поставити незалежний кварц замість PLL то при найменшій різниці середніх частот FIFO рано чи пізно приїде в overflow/underflow. Щоб цього не було потрібен PLL, ASRC або інший механізм підгонки частоти.

І тоді фапч просто простоює

- Вона якраз постійно тримає фазу і частоту в межах своєї петлі.


Санітарів тобі вже можна визивать, чи ще ні?

[Scoffer]

NST1983
Перечитай сто раз що ти сам написав поки не дійде. ФАПЧ не впливає на джиттер даних і крапка. ФАПЧ впливає на розриви. Overflow/underflow це не джиттер. Це розриви. Я ж кажу "Читаю книгу, бачу фігу". Понабирали блін гуманітаріїв по об'яві. Не можуть зрозуміти такої простої концепції що це не одна проблема, а декілька, і вирішують їх декілька апаратних блоків

Відправлено через 1 хвилину 28 секунд:
Може бути абсолютно нульовий джиттер вхідного сигналу, і розриви