Наши статьи

[Игорь-клг]

В 18.04.2016 at 07:33, Painmailer сказал:

Придумал как сделать компенсатор глитча. Так что можно ожидать не 0.1 nV * S, а 0.01..0.02.

Антон, Вы где то писали про интегральный цап с ультра низким глитчем. Не могу найти, а название забыл и среди даташитов с библиотеке не вижу. Напомните?
Или это чистый стринг был от ti?

[アントン]

4 минуты назад, Игорь-клг сказал:

Антон, Вы где то писали про интегральный цап с ультра низким глитчем. Не могу найти, а название забыл и среди даташитов с библиотеке не вижу. Напомните?
Или это чистый стринг был от ti?

Завтра поищу. 16 бит стринг. TI или AD не помню.

[Маратище]

http://www.ti.com/lit/ds/symlink/dac8554.pdf

[Игорь-клг]

5 минут назад, Painmailer сказал:

Завтра поищу. 16 бит стринг. TI или AD не помню.

Наверное от Ti   DAC85**   Не, чистый стринг. Никуда не годится. Представляете в серию 65 с лишним тысяч резисторов?))

[Маратище]

Они тормозные и не сильно точные. Можно глянуть на http://www.linear.com/product/LTC1650

[Игорь-клг]

2 минуты назад, Маратище сказал:

Они тормозные и не сильно точные. Можно глянуть на http://www.linear.com/product/LTC1650

Я просто вспомнил про низкий глитч, хотел полюбопытствовать что за архитектура. Кроме 85** серии от ti не нашел. А там вся серия чистый стринг....  Представляешь как шумит)

[Маратище]

Коррелированный шум - самый поганый. 

[Friedrich Schorr]

Раз тут смежная тема обсуждается, задам полуоффтопный вопрос насчет вычислительных мощностей. Тут постоянно темы всплывают - то крутой апсемплер, то корректор помещения, то, допустим, прога по пересчету всех аудиопотоков в dsd256 для соответствующего цапа, ориентированного на подобные потоки (или там все сразу - вначале корректор  с максимальным качеством, а потом пересчет  в дсд...) так вот, насколько подобные проги (и сейчас, и в принципе/в обозримой перспективе) юзают а) GPGPU расчеты на CUDA или OpenCL (с  отдельным подвопросом - нужны ли FP64) и б) насколько они юзают всякие продвинутые инструкции процессоров вроде AVX. 

Если вести речь о звуке с основного домашнего компа - он у меня под виндой и игровой, так что наличие достаточно мощного проца и видюхи предусматривается по умолчанию - тут единственный вопрос, нужно ли при смене видюх обращать внимание на FP64 производительность, тк ее часто режут - Невидия так почти всегда, кроме Титанов, а сейчас вроде и АМД что-то в этом направлении делает. 

Но для основной аудиосистемы я собираюсь собрать выделенный только под нее хакинтош (пока ориентировочно на i2600k в номинале, благо у меня скоро высвободится такая связка мать-проц-кулер-память, практически бесшумная) и вот думаю - ставить ли туда видюху или обойтись встроенной. В вопросе шумности это особо не проблема, можно найти малошумную, особенно не при 100% загрузке. Понятно, что этот вопрос можно решать не сразу - пока собрать без видюхи, а если появится чей-то ресурсоемкий GPGPU апсемплер или корректор, то поставить, исходя из его требований, но все-таки хочется прикинуть на будущее. 

[Маратище]

Большинство существующих алгоритмов основано на FIR фильтрации и не отличается ресурсоемкостью. Хотя, конечно, наворотить что-то циклопическое вполне можно.

Для системы Кости Костина строю восьмиствольный цап с поканальным оверсемплером на борту (чтоб USB лишней тучей данных не затыкать; возможно, этот подход ошибочен и лучше всё в одном месте делать), а разделением полос с задержками и фильтрацией будет заниматься мак. Посмотрим, что вылезет. Кстати, принимаю советы насчет софтины.

[Friedrich Schorr]

Ну вот в соседней ветке Пэйн кидал тест своего корректора - там уже для 24-192 системные требования болтались где-то на грани для сравнительно современных четырехядерников средней руки. То есть сделать 384, что-то где-то подкрутить (я не знаю, насколько это повлияет на общее качество, но мало ли) - и вот уже задача требует по сути выделенного близкого к топу компа, хорошо если четырехядерника. Может, подобные задачи на GPU обойдутся какой-нибудь средней руки карточкой. Ну и идя дальше - могло бы быть удобно делать подобные выделенные аудио-компы на чем-то вроде амд-шных процов со встроенными видюхами. Новое поколение обещает быть довольно быстрым и в плане GPGPU тоже, плюс к тому, если оно послужит основой для нового поколения маков - то не будет проблем и с хакинтошами под последние макоси. Было бы удобно собрать комп под аудио на каком-нибудь Bristol Ridge, если навороченные аудиообработчики будут юзать плюсы гетерогенной архитектуры. Или это лишний гемор писать, сужая аудиторию по сравнению с ориентацией тупо на всех владельцев мощных CPU? 

[Маратище]

Да проект и так единичный. Пока у меня один заказ на такое, не знаю как у Антона. Потому и две крайности - либо наколеночно на компе, либо вещь-в-себе на ДСП и ПЛИСках, воткнул и играет. Второе может послужить маркетинговой морковкой, но есть ли аудитория? По-моему, ее еще предстоит построить.

[ansouv]

47 минут назад, Маратище сказал:

Кстати, принимаю советы насчет софтины.

Ну, если что, телефон знаешь.

[Маратище]

4 минуты назад, ansouv сказал:

Ну, если что, телефон знаешь.

Лучше лично. Отлаживаю цапу, и!

[ansouv]

3 часа назад, Маратище сказал:

Лучше лично. Отлаживаю цапу, и!

И...жарим шашлыки. Купил Kamado Grill, теперь можно поаудиофилить.

[Мусатов Костя]

Gpu, сколько помню, не работает с высокой разрядностью. Потому его использовать под аудио не очень. Хотя однозначно сказать про все модели и не возьмусь, возможно кто из них и умеет работать с высокой разрядностью

[Archun]

4 hours ago, Маратище said:

Большинство существующих алгоритмов основано на FIR фильтрации и не отличается ресурсоемкостью. Хотя, конечно, наворотить что-то циклопическое вполне можно.

Для системы Кости Костина строю восьмиствольный цап с поканальным оверсемплером на борту (чтоб USB лишней тучей данных не затыкать; возможно, этот подход ошибочен и лучше всё в одном месте делать), а разделением полос с задержками и фильтрацией будет заниматься мак. Посмотрим, что вылезет. Кстати, принимаю советы насчет софтины.

Года три назад, Костя писал на портале что вот вот будет реализован цирокросс на писюке....
так и нету его... Чот мне боязно, но успехов искренне желаю)))))

Мак ось ведь не риал тайм? Если так, то отладка паралельных процесов добавит седых волос. И думаю, что целиться надо надо сразу на железяку, будет длинее по срокам, но результативнее.

[K K]

3 минуты назад, Archun сказал:

Года три назад, Костя писал на портале что вот вот будет реализован цирокросс на писюке....
так и нету его... Чот мне боязно, но успехов искренне желаю)))))

Это было год назад. 

Пробы с PC оказались крайне опасны, я пожег один пищик. Потому мне удобнее решения воткнул, настроил, оставил. Пока Deqx hdp-4 работает на нч. 

[Archun]

17 minutes ago, kostya kostin said:

Это было год назад. 

Пробы с PC оказались крайне опасны, я пожег один пищик. Потому мне удобнее решения воткнул, настроил, оставил. Пока Deqx hdp-4 работает на нч. 

Может и год, не в этом вопрос. Делюсь выше мыслЯми того времени. В вопросах програмирования не эксперт, так, рядом стоял... но очко жим жим делает относительно реализации на Маке или писюке. Еслиб я рули проектом , то делал бы даки и усиление в первую очередь, в надеже что цифрокорос родится сторонний, в железе. если нет, то потом делать его.

Пищики дорогие)))

[アントン]

По факту, мой FIR корректор - это и есть цифрокросс. Точнее то, что от него осталось.

Основные препятствия для цифрокросса лежат в совсем другой плоскости нежели алгоритмы или процессорная мощность. Главная проблема  в том, что цифрокросс подходит крайне ограниченному числу систем. Причём ограничения прежде всего геометрические и связаны с тем, что тянуть восемь сигнальных каналов это накладно и крайне неудобно.

[VGA]

5 hours ago, Friedrich Schorr said:

Раз тут смежная тема обсуждается, задам полуоффтопный вопрос насчет вычислительных мощностей. Тут постоянно темы всплывают - то крутой апсемплер, то корректор помещения, то, допустим, прога по пересчету всех аудиопотоков в dsd256 для соответствующего цапа, ориентированного на подобные потоки (или там все сразу - вначале корректор  с максимальным качеством, а потом пересчет  в дсд...) так вот, насколько подобные проги (и сейчас, и в принципе/в обозримой перспективе) юзают а) GPGPU расчеты на CUDA или OpenCL (с  отдельным подвопросом - нужны ли FP64) и б) насколько они юзают всякие продвинутые инструкции процессоров вроде AVX.

HQplayer позволяет задействовать Nvidia CUDA, но есть ограничения: видеокарта должна поддерживать Minimum Compute Capability CUDA level 3.0, да и для апсемплинга в DSD256 с фильтрами closed-form процессор i2700k слабоват - на практике, даже с разгрузкой с помощью GPU, желателен i6700k.
 

[アントン]

2 минуты назад, VGA сказал:

HQplayer позволяет задействовать Nvidia CUDA, но есть ограничения: видеокарта должна поддерживать Minimum Compute Capability CUDA level 3.0, да и для апсемплинга в DSD256 с фильтрами closed-form процессор i2700k слабоват - на практике, даже с разгрузкой с помощью GPU, желателен i6700k.
 

Хреновые алгоритмы. Там же банальный IIR. Прикидываю, что должно хватать одного ядра на 2 ГГц.

[VGA]

Just now, Painmailer said:

Хреновые алгоритмы. Там же банальный IIR. Прикидываю, что должно хватать одного ядра на 2 ГГц.

Не спорю  Вопрос был о готовых решениях.
 

[K K]

48 минут назад, VGA сказал:

HQplayer позволяет задействовать Nvidia CUDA, но есть ограничения: видеокарта должна поддерживать Minimum Compute Capability CUDA level 3.0, да и для апсемплинга в DSD256 с фильтрами closed-form процессор i2700k слабоват - на практике, даже с разгрузкой с помощью GPU, желателен i6700k.
 

Старый Titan заменён на 1080 от nvidia. Она поддерживает? 

[VGA]

1 minute ago, kostya kostin said:

Старый Titan заменён на 1080 от nvidia. Она поддерживает?

Должна, по паспорту Compute Capability level 6.1
 

[アントン]

Никто всерьёз на Cuda или OpenCL писать подобные приложения не будет. Хотя можно. Но крайне не универсально. Конкретная программа под конкретное железо.