Rst7
-
Постов
4 619 -
Зарегистрирован
-
Победитель дней
2
Сообщения, опубликованные Rst7
-
-
:bb-offtopic:
А можно несколько вопросов о приборе? По ходу повествованиия:
1) 16 каналов обе стороны я полагаю аналоговые, что то типа 16 канального пульта? Как вы их сделали? На кристале только один I2S.
Да, там 8 двухканальных АЦП и 8 двухканальных ЦАПов. 8 штук I2S прекрасно изготавливаются при помощи DMA-пересылки с GPIO (просто 8 бит порта рядом) в ОЗУ с последующим довольно хитрым алгоритмом транспонирования битовой матрицы (не в лоб).
2) Используется TCP, на ум приходит только линуксовый ДЖЕК с возможностью работать по сети. С какой хостовой ос работает ваше устройство? Какой протокол используете?ASIO-драйвер я написал, так что любой Windows-хост с любой DAW. Причем, т.к. транспорт там TCP, все катается в user-space без всяких драйверов в ядре. Два сокета открывается и без лишних обрамлений в каждом льются данные в нужную сторону. Хотел сначала один сделать, но оказалось, что в винде Fast Retransmit правильно работает только если данные идут только в одну сторону. Потому два сокета.
3) Джиттер меньше 500 мкСек. Т.е. 1 мсек буферизация на передающей стороне, 1-2 мсек буферизация на приемной. В обе стороны латенси около 6 мсек? Вы измеряли реальное значение?Именно так и есть. 1(вход)+1(обработка в DAW)+2(вывод)=4мс чистая цифровая задержка плюс задержки в фильтрах АЦП/ЦАП, набегает еще почти миллисекунда в сумме. Задержка измерена и рапортуется в DAW для точного позиционирования треков при записи через LoopBack-кабель.
4) Хотелось бы узнать ситуацию со свитчами. Вы наверняка проверяли такую конфигурацию.Главное в этом деле - применять самые тупые свичи. Тогда задержка в нем всего лишь на время передачи пакета в сети. В моей инфраструктуре сейчас так - комп гигабитом в свич, а в него - два таких устройства, одно - 16in/16out, второе - просто 8out, сами устройства, понятное дело, 100М. Что гигабитная карта, что гигабитный свич - обычная дешевка, купленная в первом попавшемся компьютерном магазине.
5) Как реализовали синхронизацию аудио кварцев? Я время от времени развлекаюсь со своим ЮСБ аудио и в качестве эксперимента делаю синхронный режим. По моим прикидкам время синхронизации с приличным подавлением джиттера ЮСБ СОФ получается около 1-2 сек. Что очень много.Я пару лет работал на АВИД, пилили АВБ аудио платформу. Избыточное решениея для домашних поделок, к тому же работающее только под макосью, условно работающее под линукс и напрочь отсутствующее в мире виндовс. Механизм синхронизации был черезвычайно сложный, совершенно неподъемный для самоделок.
Я не очень понимаю, о каких аудио-кварцах Вы говорите. В конкретно моем устройстве, которое 16/16, АЦП и ЦАПы тактируются одним и тем же MCLK/BICK/LRCK. В другом устройстве (которое чисто вывод) - просто цифровая PLL, причем с довольно малой постоянной времени в фильтре. Если никому не говорить, то никто из окружающих меня на студии золотоухих дьяволов не слышит никакого джиттера.
Заранее спасибо за ответы. Я вижу вы модератор, может вынесете мой пост в отдельную тему? Не хочется мешать топикстартеру.У меня нет полномочий именно в этом разделе. Надо попросить штатного модератора раздела, пусть разрежет ветку на две.
-
о! то что нужно.
примного благодарен
Ну оно там очень яростно рукожопо выглядит, сделано на очень скорую руку за один час. Без всякого окультуривания, так что пардон. Если будут вопросы - задавайте, я отвечу. Расценивайте это больше как пример, там, например, совсем некошерно с точки зрения загрузки проца смотрятся две функции CopyFromFrame_EMAC и CopyToFrame_EMAC. На самом деле надо заменить вот этот union
union { ARP_PKT arp; UDP_PKT udp; ICMP_PKT icmp; UINT8 rawpkt[sizeof(UDP_PKT)]; };на банальные указатели типа ARP_PKT *arp, UDP_PKT *udp, ...., и в основном коде, соответственно, arp.чего-то на arp->чего-то. И работать прямо по месту, в буферах местного MAC-уровня у Вашего процессора.
Я, к сожалению, не знаю, как устроен MAC в STM32 (не разбирался), но все они примерно по одному и тому же принципу - есть какая-то очередь приема, есть какая-то очередь передачи. Вот из одной надо брать пакеты (это самое начало тела цикла for(;;) в моем коде до p=arp.type; switch(p) ...), а в другую - укладывать (это ETH_Out).
-
можно. Но!
1. надо быстро.
2. надо еще заморочиться с драйвером физуровня.
на компе, винде, сырые сокеты простыми способами не поддерживаются.
Так кто-нибудь вообще пробовал?
Я просто оставлю это здесь.
На самом деле это tftp-бутлоадер для LPC1768. В нем есть ARP, ICMP (на пинг отвечает) и UDP (ибо сам tftp по UDP бегает).
Переделываете под свои нужды всякие InitEMAC()/ETH_Out() и отпиливаете все, что в ветке switch(udp.tftp_rq.opcode), ибо это уже TFTP. Крайне сложная цепочка функций SendUDP -> SendIP -> ETH_Out - вот это Ваше все будет. Для красоты не забудьте выбросить там лишнее копирование.
Ну а по поводу настоящего прибора - у меня тут многоканальный аудиоинтерфейс живет на Ethernet'е (проц LPC1768/100МГц), 16 каналов на вход, 16 на выход, 48кГц, 32 бита. Т.е. 25Мбит/с в каждую сторону. По TCP живет, шлет данные в обе стороны один раз в миллисекунду, с полноценной реализацией Fast Retransmit в обе стороны, так что джиттер в случае потери пакета не превышает 500мкс. И до 100% загрузки процессора там очень и очень далеко.
-
Предположим от АЦП приходит блок в 100 бит. Проводим свертку с какой-либо импульсной характеристикой.
Получаем в результате блок уже больше чем 100 бит. Подаем этот результат на ЦАП.
И тут возникает вопрос, а с какой частотой должен работать ЦАП?
С той же частотой, что и АЦП? Или с более высокой частотой(т.к. на ЦАП приходит блок бит более длинный чем от АЦП)?
Конечно с той же частотой. После свертки у Вас к блоку 100бит добавляется еще хвост размером с сам импульс. Вопрос "что делать с этим хвостом?" решается так: первые 100 бит Вы просто передаете в ЦАП, а вот хвост Вам надо будет просуммировать с результатом после свертки следующего блока. Для гугля ключевое слово будет "overlap-add", например.
-
Я, как модератор раздела - против. Там все вполне мирно уживается. И не такое огромное количество тем, чтобы требовалась дифференциация на подразделы.
-
А почему два параллельных источника шума вдруг производят шума меньше, чем один? Сигнал то не суммируется в параллели, почему SNR выше станет?
Сигнал суммируется (на оба ЦАПа подается один и тот же поток данных). Сумма двух одинаковых полезных сигналов - +6дБ, сумма двух некоррелированых шумов - +3дБ, итого выигрыш 6-3=3дБ.
Но это все пыль. Показываю мои любимые картинки из описания этого самого Lynx'а.
Волшебный способ получения аудиофильских выходных параметров обведен мной на скриншоте. Самое главное - это FFT size. Считаем:
Fbin=Fd/N=192k/512k=0.37Гц. Т.е. вот ширина отсчета - это 0.37Гц. В каждом таком отсчете есть сколько-то шума (ну вот по графику там на пару дБ больше, чем -145дБ).
Теперь пересчитывем эквивалент на полосу в 20кГц:
k=sqrt(Fbw/Fbin)=sqrt(20000/0.37)=234. Это на самом деле во столько раз шумнее на выходе в полосе 20кГц, чем на картинке (квадратный корень учитывает то, что шум некоррелирован). Итого, в реальности шум не -143дб, а на 20log(234)=47дБ выше. Т.е. уровень шума в полосе полезного сигнала где-то порядка -96дБ. Что вполне соответствует моей прикидочной оценке по сопротивлению резисторов.
В общем аудиофилия - она такая аудиофилия. И особенно смешно смотрится на профессиональном форуме электронщиков.
-
Шлак??? Каждому бы домой такой шлак.
Во-первых шум не коррелированный и в схеме вычитателя будет в корень из 2 раз меньше. Во-во вторых, если бы вы прочитали бы описание, то знали бы, что резисторы используются mma0204. На странице 8 "даташита" находим график зависимости шума от приложенного напряжения. При сопротивлении 13 КОм и входном напряжении вычитателя 2В имеем суммарные шумы 150-250нВ. При выходном напряжении в 2В динамический диапазон преобразования больше 140Дб.
Что-то вы считаете по-особенному, научите меня так.
Ой-ой-ой, вот это провал. Про тепловой шум резистора в ВУЗе Вас не учили?
А на странице 8 - это график дополнительного шума от приложенного напряжения. Причем непонятно, в какой полосе.
Чисто теоретический еще вопрос - нафига она ЦАПы паралелят?Ну как, каждое запараллеливание - это -3дБ к шуму. Только вот ставить при этом резисторы с сопротивлением в десятки килоом - это именно по аудиофильски.
И как обычно для таких понтов - нет балансных выходов. Что лично для меня однозначно определяет сей девайс в категорию "для золотоухих".
Нахрен не впились эти 140 дб, на записи и близко ничего такого нет, мне что, тишину генерировать и слушать на нем ?Да нету там 140дБ. Только первый каскад простым тепловым шумом уже гробит С/Ш до -110дБ, а там еще и второй есть (с номиналами подобного порядка).
-
Asahi Kasei Microdevices в 4490 аж на целых 4 варианта предлагает. И они отличаются. Верить или нет - дело ваше, но разработчики ЦАП это изменение свойств фильтра в большинстве своем слышат.
Ну вообще-то там переключение сделали не от того, что слышат, а от того, что часто важна задержка (например, в цифровых консолях/DAW). Был у них такой кошерный АЦП AK5394 (я его в гидроакустическом модеме как-то применял, он кошерен, как еврейское рождество). Все в нем хорошо было, но задержка в 63 семпла - это был перебор (особенно с учетом того, что типичная задержка на обработку в DAW на достаточно производительном компе выбирается меньше). В новой серии там уже можно переключиться на фильтр с малой задержкой. Да, ценой ухудшения подавления сигналов выше Fd/2 (имеется в виду уже после даунсемплинга, не на 6МГц, где там сигма-дельта работает) и/или ухудшения фазовых характеристик. Аналогичная история с ЦАПами. А вот это разное звучание - это все маркетинговый ход.
Дело не в микросхеме, а в том, как ее приготовили, попробуйте послушать ЦАП хотя-бы уровня Lynx D78.Да, если вы любите БАС в синтетической музыке, возможно уже уши подсели....
Вы хоть схему этого шлака откройте. 2*13кОм с шумом 20нВ/sqrt(Гц) не жмет? И это только в первом каскаде фильтра, а там еще есть.
-
Это вы журналами Радио за 95 год обложились? Студии Сони еще с 90х укомлпектованы микрофонами от басовых до конденсаторных зондов 40кГц, а с 2004-2005 переоборудованы под DXD/DSD. Какие там 44.1/16 бит; акститесь.Совершенно верно. Это называется DDD, DIgital recording, mixing, mastering. Чтобы получить SACD на выходе, на входе должен быть соответствующий тракт. Лентовое оборудование в студиях - это дань совместимости. Современная запись идет прямо на диски. Но аналогия не абсолютно верная. Аналогия тут прямая - частота - мегапиксели; raw-pcm24/32. Разве что DSD пишется как PWM, затем перегоняется в PCM DXD (по вашей аналогии из RAW в полутоновый поканальный) и монтируют привычным образом. Вы же понимаете что мегапиксели в камере превышают всякую разрешающую способность объектива, и на то есть причины.
Походу журналами "Радио" обложились именно Вы. 44.1/16 - это выходной формат. Накопление - это 44.1/24 (ну или местами 32). Не 192, не 384. В DSD ничего не накапливают, потому что нет смысла - для обработки надо превратить его в обычные отсчеты с таким-то количеством бит. Более того, все эти носители для "золотоухих" делаются просто с обычного выхода 44.1/16 - винилы так пишутся, этот же материал после мастеринга конвертируется в этот Ваш DSD (иногда воткнувши в разрыв какой-нибудь винтажный ламповый компрессор, дабы породить каких-нибудь гармоник выше 20кГц, ну чтобы не палиться полной пустотой, вдруг кто на спектроанализатор посмотрит).
Далее. Ленты на студиях (исключая ленточные сатураторы у особых любителей понтов) нет уже лет 25. Причем, 25 лет назад это был ADAT, чисто аналоговой ленты нет еще больше лет.
Ну и про микрофоны отдельно повеселили, да. "Басовые микрофоны" - это как раз показатель знатока студийного оборудования. "Конденсаторный зонд" - это вообще именно тот термин, которого всегда не хватало в музыкальной индустрии.
Вы-то хоть раз фейдер на консоли двигали? Я уж не говорю о том, знаете ли что такое DAW и прочее?
-
работала. ну да, сделанное до 2005 примерно года продолжают штамповать, но это уже не работа а эхо забытых дней.
студийные форматы давно добрались до сотен кГц. А в бытовухе... при подготовке SACD вообще все решается возможностями микрофонного тракта и выбором звукорежиссера.
Я не хочу Вас расстраивать, но Вы совершенно не в курсе дела.
Любая, это в подвале на Восстания?Нет. Abbey Road - нормально? Это как раз дятлы "в подвале на Восстания" будут Вам рассказывать про моднейшие 192кГц и прочее.
Чтобы осознать необходимость высоких частот дискретизации и большего разрешения подайте цифровой меандр частотой так в 18-20 КГц, в 44/16 и 192/24 и посмотрите форму сигнала на выходе. Много интересного узнаете про свой ЦАП.О, оказывается, что к нам на огонек заглянул человек, слышащий "звон импульсного отклика фильтра ЦАПа". Это да, особая стадия "золотоухости".
-
Почему вы забываете про аудиосигналы высокого разрешения?
Это какие-такие "аудиосигналы"? Вы вообще в курсе, что индустрия работает с выходом 44.1/16 бит (киношники - 48к)? Вот именно в таком формате Вы получите результат с мастеринга на любой студии. Других выходных форматов в музыкальной индустрии нет. DSD и прочее - это все баловство для аудиофилов на всю голову, не имеющее отношение к продакшну.
-
Но разница таки заметна
Да заметна. Только вот в изолированном случае (нет оригинала) - ничего там такого яростно портящего звук в мп3 нету. Вот и все.
-
Это так же может означать что люди не в состоянии верно объяснить разницу.
Ведь даже тут на форуме первый тестировщик ошибся но при этом точно почувствовал разницу.
Изначально разговор зашел о том, что люди различают разницу между mp3 и не-mp3. И вот прям mp3 - зло-зло, слушать невозможно, и так далее. С опровержением именно этого посыла такой простейший тест справился на пять баллов.
-
К сожалению, тестовое прослушивание каждый проводит на своей, зачастую, не оптимальной системе. Потому по такому эксперименту на форуме мы ничего не можем сказать. Информация не несет смысла, так как складываются два фактора - тракт и уши. Для полноценного сравнения ушей нужно застабилизировать одну переменную - тракт.
Несет смысл еще и какой. Главный смысл - сразу понятно ху из ху.
Прикладываю картинку того, что происходит на ВЧ при сжатии МП-3. Хороший тракт всю эту ВЧ грязь высвечивает.Т.е. то, что там полностью отрезаны ВЧ выше 16кГц - этого "хороший ВЧ тракт" не "высвечивает", да? Только внезапные превышения? Ну ок.
-
Дал брату послушать. Он назвал правильно где mp3-шка. Но добавил что разница слышна однозначно. А вот чтобы выбрать где оригинал где mp3 говорит нужно знать куда смотреть. Но так же добавил что без второго файла это не определить. Т.е. только сравнение двух файлов позволяет найти и понять разницу.
На самом деле при достаточно большом количестве ответов примерно 50 на 50 распределятся голоса, а это означает, что разница не слышна. Даже в таком упрощенном двухфайловом виде тест вполне работает.
-
Итуны требуются когда индуктивность начинает преобладать над потерями на излучение, в мощных концертных системах,
Все усилители для концертных АС - это обычные ИНУНы. До киловатта - это обычный AB (ну и всякие его разновидности с коммутацией питания для не такого провального КПД), выше - D-класс. Ну и как раз где-то с киловатта мощности уже делят полосы кроссовером до УМ, т.е. раздельные усилители на каждую полосу.
-
Как бы так сказать, чтобы не обидеть. Я удосужился послушать ЭТО.
Конечно-конечно. Всегда мне очень умилительно читать такие отзывы после оглашения результатов ;) Это один из необходимых элементов перформанса c двумя файлами - знатоки с других форумов, знатоки после оглашения результатов, неприятие исходного материала с любой из точек зрения (не такая музыка, не так записана, не так сведена), etc.
-
А какой битрейт мп3 тут?
Это pandora's pinata?
320.
Да.
Да, трек изрядно попортил мне мозг.Если в любое блюдо добавить майонез и кетчуп чили по массе равные блюду, то что вы почувствуете на языке отведав блюдо?
Вот примерно такие ощущения майонеза-кетчупа у меня возникли при прослушивании этого трека. Что это? Как это записано? Почему инструменты с голосом не выведены?
По - делу, в районе с 18-19 секунды начинает вылазить ВЧ песок от артефактов кодирования - декодирования мп3. Это прекрасно слышно. Я не поленился и запустил программку снять спектр. Да, в районе 18-26 секунды вылазы ВЧ. На Y все ровненько в районе 16 КГц идет. В X - все в районе 15 КГц порезано и всплески аж до 21КГЦ резкие. Если надо - пришлю спектры посмотреть. Вообще с ВЧ явные проблемы, что на оригинале, что на пере-MP3. Вступают тарелки, где тарелки? Не слышно их.
PS Удивительно неудачный выбор записи для оценки тракта. Это вы специально или оно само получилось?
Я как в воду глядел :))))))
Но сейчас должен кто-то обязательно проснуться и сказать "Я сразу услышал, что X - это mp3, только глухой бы не услышал, но не написал потому что потому". -
Хотя кое кто раскусил http://4pda.ru/forum/index.php?showtopic=3...&p=67182359
Тоже мне золотоухие дьяволы, "винил-рип напоминает". У меня диск на полочке стоит, нифига не винил ;)
-
Для таких сравнений предпочёл бы несколько тщательно и лично отобранных, изначально качественно записанных композиций своих любимых исполнителей.
Ну в общем настоящие тесты проводят так - материала, конечно, берут больше, сама методика прослушивания немного не такая, так называемый ABX-тест, а вот выбирать исходный материал экспертам не дают. Иначе это может сильно повлиять на результат.
-
Я понимаю если мп3 уменьшает количество информации, убирая лишнее. Но у Вас выходит наооборот.
Ну так внутри mp3 количество информации уменьшено. А после распаковки там еще может быть куча мусора. Вы разницу послушайте между этими файлами, она, конечно, коррелирует с музыкальным материалом, но шумов там масса.
-
Думаю можно огласить :)
Запросто.
X - mp3.
Y - оригинал.
Так что кого-то Вы будете поить пивом.
Но сейчас должен кто-то обязательно проснуться и сказать "Я сразу услышал, что X - это mp3, только глухой бы не услышал, но не написал потому что потому".
-
Правильно понимаете
Ну подождем минимально, вдруг кто-то еще захочет поделиться наблюдениями.
-
Детальностью не отличаются. На Клипш было бы намного заметнее
Правильно ли я понимаю, что Ваш голос суть "X - оригинал?"
Еще кто-то желает высказаться?
stm32 передать в ком поток 49мБит
в STM
Опубликовано · Пожаловаться
Не совсем. Сигнал LRCK генерируется банальным счетчиком (74HCчего-то, делитель на 256) от сигнала MCLK, а сигнал MCLK генерируется микросхемой AK4114, это в одном флаконе SPDIF-приемник/передатчик/тактовый генератор. Так исторически сложилось, потому что в качестве первой жертвы для экспериментов была взята карта Tascam US-1800 (ее собственная USB-часть была безжалостно отрезана путем завешивания местного процессора в z-состояние, использовалась только аналоговая часть плюс ЦАП/АЦП и SPDIF). А вот дальше начинается интереснее. Сигнал LRCK заведен на внешнее прерывание у моего процессора. По этому прерыванию процессор запускает собственный генератор BICK (сделаный из PWM), он же является сигналом запуска DMA (при помощи кое-каких извращений через дополнительный таймер), и на каждый фронт BICK происходит передача одного байта с порта в ОЗУ и наоборот (два канала DMA используются). Когда отрабатывается все 32 бита в протоколе I2S (у меня это превращается в 32 байта, ибо в одном байте сразу 8 сигналов данных), генератор BICK останавливается до следующего фронта/спада LRCK. Практически с точки зрения загрузки процессора это все ничего не стоит.
Можно и с аппаратно генерируемым BICK (чтобы он был красивым и синхронным с MCLK, как рисуют в даташитах), просто так, как у меня (со своим генератором), исторически сложилось. А на самом деле к BICK нет требований по синхронности с MCLK/LRCK. Может, конечно, кому-то и надо такое, но AKM'овским АЦП/ЦАПам пофиг.
Ну вот у меня Cubase в качестве DAW. Я на нем по 16 треков одновременно пишу, причем еще и обрабатываю для выдачи - я так концерты полноценные вживую озвучиваю, с обработкой барабанов, гитар, вокалов, с микшированием каналов мониторинга, всякая автоматизация и так далее, в общем использую DAW в качестве очень продвинутого микшерного пульта с кучей обработки да еще и с одновременной потрековой записью. Так вот, 16 потоков записи 48к/32 бита при попутной загрузке процессора всякой обработкой где-то в районе 50% - это достаточные по тяжести дисковые операции?
При этом комп - достаточно древний Core i7 860, ну какой-то винт (не SSD), 8Г ОЗУ. Все. Ах да, я еще и рулю этим делом по RDP через WiFi.
Вот такой вот стейдж-бокс у меня для выездов получается (на фото еще только начало коммутации):
Там DBX DriveRack PA+ для простоты настройки линейного усиления, обсуждаемый девайс, комп, WiFi-роутер из ближайшего магазина "все по 5 рублей", парочка аналоговых систем радиомониторинга. Все.
Да там нет ничего. Открываете ASIO SDK и в примере драйвера функцию sleep(1) меняете на send/recv из сокета.
ASIO в этом смысле асинхронный интерфейс (хотя правильнее было бы его назвать именно синхронным). Сколько семплов на вход DAW пришло, столько DAW на выход отдало. Так что получив очередные 48 семплов с АЦП, я посылаю их в комп, получаю в буфер при помощи recv, этот буфер размером 48 семплов DAW обрабатывает, затем из буфера посылается через send, попадает ко мне в девайс, и после буферизации попадает в ЦАП. Никаких проблем с передискретизацией или еще чем-то. Скорость данных с АЦП точно задает и скорость данных в ЦАП.