Via Tremor 7.1 - что за зверь?

[DIP20]

Обнаружил в одном из московских магазинов оную карточку. Стоит копейки - 12 долларов. Прошел слух, что это урезанный Envy24. Все бы ничего, но возле чипа стоят 2 кварца, прямо точь-в-точь как в обвязке Envy24. Быть может, реально оттуда честную цифру вытащить?

Перечитал всю ветку и сделал такую компиляцию.... (см. вложение)
https://forum.vegalab.ru/attachment....8&d=1228597678

[masterspammer]

Не очень понятна методика измерения - прежде всего наличие/отсутствие внешней синхронизации (от ЦАПа). Насколько я знаю, чтобы воспроизвести НЕ ту частоту нужно или исказить данные (потерять пресловутый bit perfect) или изменить частоту дискретизации - для борьбы со вторым внешняя синхронизация и используется - внешнему генератору RT/неRT - сугубо фиолетово.

Ну а то, что на внутренний генератор карты влияет другое железо и нагрузка на него - так с этим я совершенно согласен!

[anpir]

нужно или исказить данные .... или изменить частоту дискретизации

Вот второе наверное и происходит, но не в звуковой карте а до неё ...

[masterspammer]

Вот второе наверное и происходит, но не в звуковой карте а до неё ...

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

Я сам не понял Ваш ответ. У меня и тактируется тремор от ЦАПа и ядроRT и у меня есть bitperfect.

Важный вопрос - есть ли у Вас регистр(ы) пересинхронизации данных от источника ЦАПа? Если нет, то есть все условия для устранения временных искажений, но нет собственно устранения.

Я думаю что Вам нужно разделить мух от котлет. Железо это железо, ОС это ОС. Меняешь что либо качесвенно в железе или в ОС и звук другой. При RT задержка времени по постоянна. В отличии от обычного ядра. Не пляшет. Звуку естественно лучше.

Вообще-то задержек тут у нас две: одна задержка от получение информации до появления её на выходе (типовой пример - гитарный процессор в виде программы) - нам совершенно не важно, через сколько миллисекунд начнётся песня после нажатия кнопки (но гитаристу очень важно, с какой задержкой он услышит удар по струнам - вот тут и RT и хитрые звуковые подсистемы помогут) и вторая задержка (и опережение, кстати) между ожидаемым и реальным поступлением очередного отсчёта - она радикально меньше и от софта зависит уже опосредованно (из буфера в памяти данные выбираются аппаратными средствами), а что важно для нас - до какого-то предела её можно устранить полностью (а дальше - это уже ошибка, наблюдаемая и слышимая) - лишь бы была внешняя синхронизация (вот для этого и Tremor!)

Т.е. линуковская ASIO только не на уровне драйверов аудио, а на уровне и "драйверов" и на уровне ОС, вместе с аудиоплеером. Все аудиодистирбутивы на линуксе сделаны на RT, в том числе и плеер в них.
То что звук не зависит от операционки, достаточно распространнёное заблуждение, не знаю почему-так, наверное из-за непонимания и из-за незнания этой темы.

"линуковская ASIO" - нет такого предмета (если не брать во внимание wineasio); более того, можно вообще в порядке эксперимента направить поток на звуковую карту в обход почти всех лишних подсистем (это потребует программирования, будет неудобно, но для сравнения - вполне).

Звук __может__ не зависеть от операционки, для этого нужно, чтобы плеер, звуковая подсистема (если она есть) и драйвер не вносили изменений в передаваемую цифровую информацию (это типовой случай, наступление/достижение его - минимальное начальное требование) и не вносили временных искажений (практически нереально, очень сложно, вот тут и надо RT) или допускали устранение этих искажений (как раз синхронизация от внешнего источника).

Хотябы зависит отдрайверов, хотябы зависит оз звуковой системы, хотябы зависит есть или нет по пути сигнала к примеру звуковой микшер. ЛюБАЯ ОС это задержка в звуке от источника, которая состоит из частей - зв. файла до получателя в данном случае вход ЦАПа. У меньшая эту задержку и делая её постоянной мы приближаем вооставновление из электронной аудио-формы максимально точно сигнал.

См. выше про два вида задержки. Устранение влияния на данные драйверов, плеера, микшера (в случае VIA Tremor - установка его на 0db, чтоб 16бит оставались 16-ю битами) и формата (вот для примера wma, mp3, ogg - там как раз есть искажения, зато объём мал) - начальный этап, про него говорить не будем, устранение задержки до начала воспроизведения нас не интересует вообще (см. тут же на форуме тему про FIFO с большим буфером, там вообще эта задержка - секунды), а вот задержка очередного отсчёта (неравномерность отсчётов) нас очень интересует.

Неравномерность возникает от неравномерной (тавтология!) работы аппаратной схемы (нестабильность питания генератора, если он встроен, вообще нестабильность питания, а следовательно, логических уровней, наводки, сдвигающие уровни как фактические, так и пороговые, то вверх, то вниз, а значит и то влево, то вправо, поскольку крутизна фронтов небесконечна), от того, что буфер выбирается монотонно, а пополняется кусками (а от опустошения буфера возникают ошибки, сейчас не про них). Она зависит от нагрузки на процессор (меняет и скорость пополнения буфера и нагрузку на питание, а значит и его уровень, создаёт наводки), память (ПДП может обломаться на микросекунду или сколько там и подождать) и вот тут от RT и приоритета задач. Она зависит от размера буфера - маленький буфер пополняется равномерно, зато большой - редко.

Т.е. уменьшаем софтовый джитер. Кстати в настройках ядра линукса есть опция по уменьшению софт джитера. Написал своими словами.

Оставим это тем, кто не может джиттер устранить

[anpir]

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

После DSP все четко.
А откуда берется PCM поток в DSP , наверное из буфера ЗК который в оперативной памяти компа, последовательность пакетов (импульсов) из буфера должена быть стабильна относительно времени t.

Но получается что может плавать относительно частоты дискретизации, до 1000ppm и более

Мои замеры это подтверждают .... выше давал ссылку.

[_Summit_]

masterspammer, господин dalidovich у нас известный своими излияниями по поводу задержек, RT ядер, дистр. линукс и как все это кардинальным образом влияет на звук. Из сообщения в сообщение одно и тоже. Как пластинка заезженная.
Все никак понять не может, что никакие RT ядра и задержки на вывод звука не влияют. Временная составляющая аналогового сигнала на выходе ЦАП задается его тактовым генератором и ничем более. А в цифре она вообще не существует - файлы статичны и их содержимое не зависит от того в какой момент времени их воспроизводить (выполнять).

То что звук не зависит от операционки, достаточно распространнёное заблуждение, не знаю почему-так, наверное из-за непонимания и из-за незнания этой темы.

В правильно настроенной не зависит. Бит-перфект на выходе из компьютера может дать любая ОС. Компьютер для того и придумали, что бы он безошибочно работал с большими массивами данных. И работает он прекрасно. И выводит то, что нужно выводить.

---------- Сообщение добавлено 22:06 ---------- Предыдущее сообщение было 22:00 ----------

из буфера ЗК который в оперативной памяти компа

Ты в этом точно уверен. Нафига ЗК буфер в ОЗУ?

последовательность пакетов (импульсов) из буфера должена быть стабильна относительно времени t.

Зачем? У ЗК есть свой буфер. Его вполне достаточно для выборки генератором. Вот ген. должен быть стабильным. А все остальное пофиг.

[dalidovich]

Тему почистил от своих сообщений линукса. Не в коня корм. Не господин _Summit ошибаешься нас двое и надеюсь что anpir тоже второй.
А так же я, пишу господину _Summit, известен тем что и я взломал этот самый тремор и мы на этой ветке посвящённой тремору и люди им пользуются и я бесплатно выложивший свои наработки в сеть. И я хочу помочь людям и дальше, но не господинам. Господины пусть идут слушать свою заезженную пластинку про правильную настройку виндовс и про одинаковый звук в ОС. Есть куча народу ставивших аудиолинуксы хотя бы от нашего соотечесвенника tinimpd. И люди платят ему за доступ к новым сборкам по 1000 руб, вот идиоты да господин, вы бы наверное так никогда бы не поступили ведь виндовс звучит одинаково. А так же звучит одинаково по мнению господина ставивших к примеру хакинтошь. Про то как звучит настоящий макинтошь я промолчу. И насколько близко к дорогом СД стационарам звучит и наверное, о боже господин совсем на знает что настроить в макинтоше операционную систему под звук практически нечего.
У меня господин в Алческе ЛНР моя сборка на линуксе переиграла почему-то вот вдруг, всю аудиоапаратуру в городе в том числе и винил. И аудиокарта представляете какая-то джулия. Да по словам господина это не может быть, интересно как можно настроить виндовс чтобы хотя бы переиграла так недорогой СД стационар ну к примеру пару килобаксов. Т.е. около 120000 руб. Может господин откроет секретную методику. А слабо?
Я пишу про базовые знания в линуксе, но заставь дурака молиться он и лоб разшибёт, уже долго пишу но толку нет, наоборот появляются разные господины, у которых не получилсось, чтож бывает не все тянут тему, в инете ведь не подучишься, а самому учиться не получается, не могу ответить почему не получается учиться за этих людей, но гомнить того у кого получилось это да всегда за спасибо и в первых рядах. Ведь господин мог и пройти топик про тремор, ведь у господина ведь другая карта, но нет погомнить перевешило здравый смысл. Заметь господин ведь я твои высказывания не обсуждаю, а ты мои гомнишь, не хорошо получается, желаю тебе познать своё гомно самому. а специальные по настройке в инете нигде нет почему-то. И так везде. Профессиональных знаний нет в инете. и Я своих не собираюсь раскрывать. Да господин, представляешь в линуксе я ещё и делаю сам патчи на ядра и на программы, т.е. знания у меня есть и подтверждённые на ПРАКТИКЕ. Т.е. у меня теоретические знания которые я сам себе создал точно совпадают с практическими. Теоретические энания это не академическими терминами, а как я сам их понимаю. Поэтому господин ищи в моих высказываниях по твоему мнению несовпадения и неточности и цепляйся к ним. Но мне и моему хорошему другу в Алчесвке, Он гораздо старше меня, фиолетово на таких как ты.
Не получилось помочь masterspammer

[_Summit_]

вы бы наверное так никогда бы не поступили ведь виндовс звучит одинаково.

Конечно. Это ты сначала бредишь, потом трешь, потом опять бредишь. Мне абсолютно пофиг кто, кому платит за сборки, кто ставит хакинтош тоже. На вывод звука это не влияет.

[dalidovich]

anpir, Напиши в личку как ты мерил, я у себя померю.

[anpir]

Зачем? У ЗК есть свой буфер. Его вполне достаточно для выборки генератором. Вот ген. должен быть стабильным. А все остальное пофиг.

Где у ЗК буфер, покажите
http://gd.tuwien.ac.at/opsys/linux/a...y24HT091DS.pdf
Он в памяти компа ..... default interleaved DMA method ....

......................................
The following figure is a visual representation of the stereo pairs data transfer mechanism. This is an
alternative to the default interleaved DMA method. In this mode the data is not packed tightly for
time correlation. It allows independent stereo pair operation. A 12 layers deep buffer structure is
implemented for a seamless flow of each stream. If the PDMAi burst size is left at 8, no stereo pair
DMA is available except for SPDIFout/PDMA4 and Record DMAs which are always independently
controllable. As the burst size of PDMAi is decreased by writing to MT19, independently controlla-
ble playback stereo pair DMAs become available. 32-bit data transfers are used regardless of the
audio data resolution. All transfer data are left (MSB) justified. Each transfer request results into a
PCI bus master burst cycle. The burst size is always 8 PCI data cycles long, i.e. Left and Right for 4
consecutive sampling times. All stereo DMA pairs behave similarly.
.......................................



В реальном времени ничего не ждет
Цифровой звук работает, воспроизводя постоянный поток звуковых сэмплов (номеров) в цифроаналоговый преобразователь (ЦАП) вашей звуковой карты или аудиоинтерфейса. Образцы воспроизводятся с постоянной скоростью, известной как частота дискретизации. Для CD-плеера частота дискретизации составляет 44100 Гц, это 44100 стереокадров в секунду. Каждую секунду с одинаковой скоростью. Не быстрее, не медленнее. 44100 выборки кадров каждую секунду. ...................................
.........................В операционных системах общего назначения, таких как iOS, Android, Windows, Mac OS X или Linux, ваше программное обеспечение обычно не будет поставлять отдельные образцы в ЦАП, оно будет предоставлять буферы образцов драйверу или промежуточному слою ОС. Например, он может обрабатывать буферы 256 выборок со скоростью 179,26 Гц (это 44100/256). Затем нижние уровни системы подают отдельные выборки из каждого буфера в ЦАП на частоте 44100 Гц. http://www.rossbencina.com/code/real...ts-for-nothing
...................................

Чтобы у ЗК был свой буфер, наверное нужна своя память, прцессор и т. д.

[dalidovich]

Картинку anpira даже никто и не понял. Спасибо за просвещение тебе. Интересно _Summit будет и дальше хамить от непонимания или почитает всё таки то что привёл anpir?

[anpir]

anpir, Напиши в личку как ты мерил, я у себя померю.

http://www.baudline.com/
Окно input_devices показывает точную частоту семплирования в реальном времени http://www.baudline.com/manual/input.html#input_devices
Частотомером Ч3-33, замерял период с выхода ЗК (точность 0,1мкс) .

[dalidovich]

Спасибо.

[anpir]

Картинку anpira даже никто и не понял. Спасибо за просвещение тебе.

Да я сам еще толком не разобрался, но пытаюсь ....

[dalidovich]

Представляю если _Summit решить повторить твой опыт в измерении , вот ведь будет невезуха, ведь придётся если ты порядочный человек извиняться за свои слова и писать во всём вегалабе опровержения своих слов. Т.е. если человек не слышит разницы в звучании разных ОС то частотомер явно покажет все отличия в частоте, а ведь разница есть . И ещё раз, т.е. два раза
Правда эта программа есть только для линуксов, юниксов и мака, но ты подтвердил что при различных настройках в линуксе разница в Воспроизведении файла 1000Гц от этой 1000гц частота пляшет в Linux на выходе звуковйо карты разная и разная на разных звуковых системах и ядрах. Т.е. разный звук даже на одной и той же системе. Но я уверен что аналогичная программа есть и для винды. Да хотябы взять обычную программу генератор частоты в винде, я думаю что и там разница есть или взять нарезку аудиофайлов по 1000Гц прогнать в плеере и померить на выходе ЗК.
Anpir а можешь так сделать в винде? И выложить сюда в топик разницу. При одинаковой ЗК. Спасибо. У меня частотомера нет.
Я очень тебе благодарен за то что нашёл способ реально доказать и показать почему звук в линуксе лучше на приборах. Молодец. Всё гениально просто. Можно к примеру взять диапазон СЧ лучше всего слышимый человеческим слухом, для явного отличия в разнице. Т.е. на приборе ты подтвердил мои моноголетние слова, что звук на ядре реального времени лучше, и звук лучше на OSS4 чем на альзе.
Придуркам своего слуха недостаточно, нужно обязательно жопой попробывать иначе не поверят. Т.е измерения на приборах отклонение во времени частоты 1000гц, а значит всех частот есть место быть отклонения и то что ты подаёшь даже с битперфектом на выход аудиокарты толку я уверен нет, раз частота пляшет во времени. Ещё раз ОЧЕНЬ большое спасибо.
Я уверен что ядро реального времени на виндовс так же даст меньшее плавание частоты во времени чем обычное ядро в виндовс. Вот где бы его взять пиратски, стоит я думаю десятки тысяч уе и под это ядро нужно писать своё ПО.

[anpir]

Из личного опыта и анализа инфы с других форумов, за зиму
Самые хреновые результаты у систем на базе Mini_ITX.
Самые лучшие на топовых материнских платах.
Очень неплохие у ARM систем даже по дефолту, вот пример bela audio на Beagle Bone Black https://www.kickstarter.com/projects...tency-interact таких результатов можно добиться только с жостким RT - ядро Xenomai, QNX ......
Мне удалось добиться стабильной работы практичкски без буфера, всего 4 семпла - задержка 0,1мс, но пришлось подправить драйвер AP192. Система работает в в пределах 1мкс латенси, ядро PREEMPT_RT.
С ядром Xenomai латенси десятые доли мкс, но нужен софт для работы с ядром cobalt xenomai, у bela audio как то получилось....

---------- Сообщение добавлено 03:22 ---------- Предыдущее сообщение было 03:08 ----------

Anpir а можешь так сделать в винде? И выложить сюда в топик разницу. При одинаковой ЗК. Спасибо. У меня частотомера нет.

У меня винды нет но попробую ... Выше картинка была, наверное с вин



http://citeseerx.ist.psu.edu/viewdoc...=rep1&type=pdf
To determine practical sample rate deviations in sound devices, the audio output frequency of 4
desktop PC’s, 13 laptop PC’s, 10 laptop PC’s with USB sound device and 9 portable CD players
are measured, while playing a 1 kHz signal. The devices equipped with an audio input are
assumed to have approximately the same sample rate errors for recording operations. The
measurements are performed using a frequency co
unter (Philips/Fluke type PM 6685) using a
gating time of 10 s. Figure 3 shows the results.
---------- Сообщение добавлено 03:24 ---------- Предыдущее сообщение было 03:22 ----------

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

У AlSA если с мин. буфером, тож все нормально.

[dalidovich]

С ядром Xenomai латенси десятые доли мкс, но нужен софт для работы с ядром cobalt xenomai,

Именно из-за этого я отказался от ядра с жёстким RT. Наверное они сами писали к нему свой софт. То же соглашусь. "У AlSA если с мин. буфером, тож все нормально."
Есть кстати пиратское ядро RT но для виндовс ХР, но к нему нужно писать ПО понимающие этот RT, ядро идёт с комплектом разработчика и самое главное выхлопа не будет, ведь это пиратка, проблемы с законом могут быть.

[anpir]

RT ядро PREEMPT_RT нужно еще использовать правильно, у меня звуковая карта с наивысшим приоритетом на отдельном изолированном ядре 3
Jack с наивысшим приоритетом на отдельном изолированном ядре 0

В будущем Brutefir на своем, и наступит полная гармония
Все это отлаженно на RadHat - CentOS
Xenomai это уже совершенно другое ядро.

[dalidovich]

RT ядро PREEMPT_RT нужно еще использовать правильно, у меня звуковая карта с наивысшим приоритетом на отдельном изолированном ядре 3

Это народ даже не понимает. Что поставить только ядро RT и надеясь на то что это всё конец, глупо. Это ядро ещё и надо правильно использовать.
RTAI всё таки меньше задержка по сравнению с Xenomai но опять же оно жёсткое, т.е. для железа типа станков ЧПУ и т.п.

[anpir]

Нужно пробовать QNX - это полная жесть

[dalidovich]

Нужно пробовать QNX - это полная жесть

Не не вариант, драйверов нет, платная и для станков, автомобилей и т.п.

---------- Сообщение добавлено 02:36 ---------- Предыдущее сообщение было 02:31 ----------

Может всё таки LynxOS она совместима с линуксом.