Последний раз редактировалось Konkere; 06.12.2011 в 09:33.
Вот человек мучился изучал линукс , настройки там всякие , глаза портил а вы его порыв души не поняли ) мне бы обидно было .
Последний раз редактировалось Faustrip; 17.03.2017 в 00:06.
Он во всех областях ничего не знает. Его линуксовые потуги того же порядка. Я с чипами Envy работаю фактически с момента их разработки, когда ещё IC-Ensemble не была куплена VIA, и даже даташиты не раздавались, а давались под NDA. Даже до сих пор помню пароль доступа на сервер IC-Ensemble, а уже прошло более 10 лет.
интересно когда via под pci-e что то подобное родит , уже и pci родных не осталось на mb а его все мучают .
Насколько я знаю - ничего ПОДОБНОГО не планируется. VIA в своё время выгодно купила IC-Ensemble и получила чип с битперфектом и прочими вкусностями. Самостоятельно они такой чип не разрабатывали бы. Поскольку считается, что массовому сегменту такие возможности не нужны (а чип Envy изначально был разработан именно для узкого профессионального применения, и конкурентов среди одночиповых решений у него не было).
Для шины PCIe разрабатывается дешёвое массовое решение с ресэмплингом. Никакого битперфекта там не будет. Просто ещё один вариант стандартного компьютерного звука, чтобы делать кристаллы на своей фабрике.
Всем заправляют маркетологи. Сейчас модно или выводить через HDMI (с обязательной защитой контента), или на дешёвые комповые системы 5.1-6.1-7.1-8.1. Остальное - узкая ниша, специалистам-маркетологам с глобальными амбициями это не интересно.
Зачем? Есть "мосты" от асмедии писиай-и ту писиай, это дешевле чем новый чип под писиай-и дизигнить.
---------- Сообщение добавлено 01:19 ---------- Предыдущее сообщение было 01:13 ----------
anpir, ты завязывай ханку жрать, потом локти кусать будешь, а не отпустит уж.
Последний раз редактировалось Denisius; 17.03.2017 в 02:48.
Касаюсь струн, держу суперсимметрию.
Фиг вам ....
Про задержки, латенси и пр. в аудио системе.
http://kokkinizita.linuxaudio.org/papers/usingdll.pdfКак правило, обработка звука выполняется в периоды - сэмплы обрабатываются в блоках фиксированного размера. В частности, все приложения с поддержкой JACK работают таким образом, и ситуация не очень отличается при использовании ALSA напрямую. Нет никакой жесткой связи между временем, когда данный блок выборок действительно доступен для обработки, и временем, когда сигнал, представленный этими образцами, будет существовать или существовать как физический звук или как аналоговый электрический сигнал. Когда сигнал представлен данными в компьютерной памяти, его реальное время также становится данными, которые каким-то образом должны быть сохранены вместе с образцами. Мы можем, каждый раз, когда мы начинаем обрабатывать период, читаем системный таймер. Это даст приблизительное представление о том, когда (в системное время) звук был или будет слышен. Для этого необходимо рассмотреть еще пять факторов:
Latency.
Это время между выборкой, которая была (или будет) преобразована из (или в) в аналоговый домен (или в формат, который имеет физическое время), и время, когда звуковое оборудование создаст прерывание, которое вызовет обработку Блок, в который входит этот образец. Задержка, определенная таким образом, является только функцией от объема буферизации, выполняемой аудио аппаратурой, и не будет рассматриваться далее в этой статье.
Delay.
Между прерыванием HW будет какая-то задержка, а в моменте мы можем прочитать системное время. Это состоит из прерываний, обработки и планирования задержек.
Jitter.
Задержка, упомянутая в предыдущем пункте, не будет постоянной. Успехи в проектировании и реализации ядра Linux значительно уменьшили этот вариант, но он все еще существует и останется. Типичная хорошо отлаженная система будет показывать небольшую среднюю задержку с некоторыми нерегулярными пиками.
Timer quantisation.
Системный таймер может иметь значительную ошибку квантования, например, он может увеличиваться с шагом в миллисекунду. Когда период времени является точным кратным шагу таймера, это будет генерировать постоянную ошибку. В другом случае квантование таймера проявляет себя как дополнительное дрожание.
Sample frequency errors.
На большинстве аппаратных средств тактовые импульсы дискретизации не заблокированы каким-либо образом на том, который управляет системным таймером. Это означает, что реальная частота выборки (при измерении относительно системного времени) будет не совсем равна номинальной, и что любое отображение, основанное на номинальной частоте выборки, покажет ошибку.
Задержка может быть компенсирована, когда мы знаем драйвер и конфигурацию HW. В следующих разделах будет показано, что также могут быть устранены ошибки дрожания, квантования и частоты дискретизации. Единственная оставшаяся ошибка - это среднее прерывание для задержки чтения таймера.
В системе, настроенной для работы с аудио, она должна быть небольшой, и постоянное смещение удалит большую часть.
...................
В то время как для большинства (на основе PCI) звуковых карт дрожание в основном определяется задержками планирования.
USB-аудиоинтерфейсы показывают и дополнительную проблему: джиттер временного периода в основном является результатом переупаковки образцов ALSA в периоды запрошенного размера. Теоретически этот джиттер должен находиться в диапазоне 1 мс (период прерывания USB), но на практике наблюдаются колебания в диапазоне до 4 мс. В качестве примера на рис. 5 показана ошибка цикла для USB-интерфейса автора. Это также показывает, что петля адаптируется к среднему прерыванию к задержке чтения таймера, которая в этом случае довольно высока.
На рисунке 6 показан оставшийся джиттер после фильтрации DLL. Это уменьшается от начального значения ± 2 мс до диапазона около ± 10 мкс. Большинство звуковых карт PCI имеют значительно меньше дрожания для начала, и отфильтрованный результат будет лучше, чем одна микросекунда.
Как можно не понимать влияния системы на звуковую карту ???
Операционная система с драйверами управляет всем железом включая звуковую карту - от рабочих частот до питания.
Используемый софт - тоже имеет значение.
Само железо, куда установлена звуковая карта влияет на качество звука и не только ....
Латенси системы или джиттер системы напрямую зависит от качества железа и настроек операционной системы. У правильно отлаженной системы латенси будет 1мкс и менее, кривую систему будет колбасить до 1000мкс и более.
Последний раз редактировалось anpir; 19.03.2017 в 11:18.
Тут все это понимают. Только у тебя оно какое то особенно извращенное.
Согласен. Только надо определиться, рабочих частот чего?? И да, драйвер управляет геном и даже не одним, но частоту семплирования он только указывает, но не задает.
Конечно. Есть софт, который преобразует данные, например ресемплер и регулятор громкости в микшере DS. Мы тут про такое не говорим.
И снова верно! Поздравляю коллега. Проблема только в том, что не ядром или латентностью оно влияет, а тем сколько неотфильтрованных ЭМ помех пройдет в аналоговую часть. Нормальным ЦАПам это не грозит.
Это может влиять на производительность и стабильность работы компьютера. Если эти параметры будут критичными, будут глюки и треск, но не аналоговые искажения.
Ты сам то это читал? Или только в гугл перевел, увидел знакомые слова и нам сюда подсунул, мол сами разбирайтесь?
Последний раз редактировалось anpir; 19.03.2017 в 13:02.
Статья для тех кто пишет музыку , им да важны задержки, а тем кто ее слушает фиолетово , и то уже вроде все написание музыки идет софтово , мощностей современных ПК хватает ,
Это раньше пихали кучу dsp микросхем на карту , так как мощности cpu пенька 4 го не хватало на все обработки , сейчас таких проблем нет .
В статье задержка упоминается один раз и не более, не об этом статья, смотрите внимательней.
Latency.
Это время между выборкой, которая была (или будет) преобразована из (или в) в аналоговый домен (или в формат, который имеет физическое время), и время, когда звуковое оборудование создаст прерывание, которое вызовет обработку Блок, в который входит этот образец. Задержка, определенная таким образом, является только функцией от объема буферизации, выполняемой аудио аппаратурой, и не будет рассматриваться далее в этой статье.
http://hifi-audio.ru/hifi/аудиофильн...на-pulseaudio/
Ну вот статья , у вас либо есть битперфект либо его нету , все остальное не важно , и то это вопрос вкуса , кто то ставит плагины пленки винила лампы , это их личное дело .
"Замполит, чайку?"(с)"Охота за Красным Октябрем".
"Ну что, можете меняться обратно."(с)типа анек.
<-- http://altor1.narod.ru --> Вопросы - в личку, е-мейл, скайп.
При общении с тобой, я себя начинаю чувствовать полным муд@ком, коим ты являешься.
А, ты про это? А я думал про ядра и про задержки. Но даже на "этом" видно 2 кварца для разных сеток частот.
Теперь еще остается перевести на русский.
Вот и иди сундук засирать. Там таких "любознательных" как ты с гугл переводчиком 99%.
Абсолютно. Есть только устройства с плохой реализацией USB (мне такие попадались), но там щелчки...
"..ремонт вообще невозможно закончить, его можно просто прекратить!"(с)ММЖ.
"Замполит, чайку?"(с)"Охота за Красным Октябрем".
"Ну что, можете меняться обратно."(с)типа анек.
<-- http://altor1.narod.ru --> Вопросы - в личку, е-мейл, скайп.
Кстати, автор документа который я цитировал выше, разработчик софа http://kokkinizita.linuxaudio.org/linuxaudio/ звукорежиссер Fons Adriaensen
Интересное интервью с ним http://libremusicproduction.com/arti...ons-adriaensen
Вот интересно; я вижу как минимум один вариант временных искажений, сходный с джиттером:
DMA выгребает данные из оперативной памяти и в этот момент происходит другое обращение к памяти (процессор) - возникает небольшая задержка и неравномерность (подозреваю, что производители уже сделали что-либо, чтоб скорректировать её, например грузят несколько заранее, так что задержка остаётся совсем малая, примерно как возникающая из-за коррекции ошибок на CD). Величина задержки/неравномерности - ДОЛИ периода тактовой частоты, если больше, это уже ошибка передачи (и вот выше "производители уже сделали" - это даже скорее чтоб ошибки не было, чем чтоб задержки) и мы о ней не говорим. Замедлить тактовый генератор (он у нас тут внешний) всё это не в силах - данные остаются на месте, передача синхронна, только фронты дрожат.
Тут влиять будут размер буфера (причём скорее парадоксальным образом - чем буфер больше, тем его дольше заполнять и больше вероятность конфликта), нагрузка на память "вообще" и процессор (через память), многозадачность (опустошения кэша процессора -> обращения к памяти, которых могло не быть) и прочее. Можно решать задачу экстенсивно "методом долгоносика - посадим 100ГА сахарной свеклы - пусть подавится", а можно, пользуясь наличием образцового тактового генератора, убрать ВСЕ эти искажения полностью (и с CD транспортом внешняя синхронизация для того же). Вот если внешний генератор не подключить, то, действительно, придётся подбирать настройки и т.д..
Ну и про возможность устранения - проверяется легко:
регистр устраняет небольшие неравномерности по логике своей работы (фронт будет тогда, когда фронт у синхросигнала), большие неравномерности превращаются в ошибки, так что если вы не слышите явных искажений (и сохраняется bit perfect, если уж совсем въедливо проверять), так что всё хорошо... ну если пересинхронизация реализована как надо(*); если пересинхронизация "не получается", то может быть искажения длительности слишком велики, а может быть имеет смысл сдвинуть момент тактирования регистра (он совпал со средним моментом переключения сигнала, то есть то успевает, то нет), так или иначе, искажения или чудовищные или их нет вообще; недоверчивые могут проверить bit perfect (а вдруг по какому-то стечению обстоятельств страдают только младшие биты) и на этом вопрос закрыт.
(*) тут можно вспомнить, как masterspammer чуть не поставил ИР22 вместо ИР23, но ведь не поставил же
-----
Про PDF с измерениями - учитывая, что чем ближе к портативу, то тем чаще не кварц, а PLL "всё в одном", то там уже влияние через напряжение питания будет большим (см. мои эксперименты c CM108 и, соответственно, PLL там).
Сейчас я лекцию прочту https://www.youtube.com/watch?v=-gzzxe1mMy0
Несколько упрощенно: У звуковой есть 2 массива буфера, ОС периодически опрашивает ЗК - есть ли сейчас пустой массив буфера, если есть - заполняет опустевший массив буфера и ждет, пока освободится(опустеет) другой. Т.е. звуковой для качественного воспризведения вообще не страшны никакие там latency/jitter системы(разве что система оочень сильно тормознутая/глючная).
ОС так же дает установки ЗК - с какой частотой ей эти данные из буфера необходимо дальше по i2S передать. И так получается, что звуковая работает на своей частоте, система на своей - все просто.
Latency в смысле размера выходного буфера ASIO - это уже немного другая опера, нужно только для проф применения.
Социальные закладки