А сервер HQP включён в точку доступа?
был включён ранее, проблема такая же, сейчас включён в свитч между кинетиком и точкой доступа
А разве клиент способен выбирать регион?
возможно там как с WAN (синим портом) который можно настроить в полудуплекс в режиме АП, а потом переключаясь на клиент - полудуплекс остается
т.е. я бы переключил в АП, указал testMode в регионе, сохранил, и потом переключил в клиента.
эксплуатирую нетисы (феликса) уже не один год, канал держат очень хорошо (между друг другом) 173ий
1 лайк
Похоже, Алексей “нащупал” проблему. В Клиенте тоже надо выбрать Тестовый Режим. Только это можно сделать когда он Точка Доступа. Сохраниться и снова переключится в Клиент. Тогда Клиент будет искать все каналы и найдёт 177 или 173 и подключится.
Интересно
Вроде бы сработало. Первый раз hqp увидел эндпойнт на 177.
Хотя это чисто hqp заморочки. На 177 канале остальное работает беспроблемно. Я написал Юсси, от ответил, но я ничего не понял:
Since HQPlayer operates over IP protocol stack, and WiFi channels are
many OSI layers below the IP stack, the channel selection shouldn’t
really matter for this.
The only reasons I can think of why this could be happening is packet
loss on the higher channels. There’s some 500-600 MHz higher frequency
on those higher channels, so they get blocked by obstacles somewhat
easier. Since the multicast discovery uses UDP, notable packet loss can
result in failure to detect the endpoint. And another reason I can think
of is some kind of bug in the WiFi bridge firmware regarding multicast
traffic and IGMP subscriptions.
No, there’s no way to define static IP address for endpoints, the entire
concept assumes that the IP addresses are not static but instead tend to
change over time. So discovery is used to find the devices by their
names instead of IP.
However, mDNS is is not used for this purpose, instead it is a custom
protocol more similar to Avahi/Bonjour.
Спасибо вам и Алексею, работает. Неочевидная вещь.
Может, стоит добавить в инструкцию? Ещё бы предложил добавить следующее: когда нетис подключается для первой настройки, он пускает при обычном подключении, но сразу после перевода в режим моста пускает в админку только при переключении сетевой карты компьютера в ручной режим с выставлением ip, отличным от ip нетиса.
Это происходит из-за того, что при первоначальной настройке роутер Netis выступает и в качестве DHCP-сервера, поэтому подключенный комп получает от него ip соответствующей подсети. При переводе в режим НЕроутер (клиент или АР) сервис сервера DHCP не подымается, и комп не получает ip из рабочей подсети. Я бы рекомендовал вообще на компе, с которого выполняются настройки, устанавливать ip вручную на постоянной основе, точно понимая его адрес и к какой подсети он привязан.
2 лайка
Какой номинал конденсаторов под замену в Netis n4? Есть предпочтения?
Смотря какой звук хочется получить. Если монолитно чугунный, то большие ёмкости, если подвижный и пластичный, то оперировать сотней, другой мкф.
1 лайк
В итоге не помогло. Сначала работало, но вот пришлось клиент отключить от питания и вновь включить, не видит AP
Избавляясь от шума Ethernet
Найджел Белл, основатель и главный разработчик Reiki Audio Limited
RH: Сегодня практически все слушают музыку через стриминговые сервисы, а значит, в аудиосистеме присутствует проводное Ethernet-подключение. Почему оно может ухудшать качество звука?
NB: Именно так. Еще несколько лет назад даже увлеченные аудиофилы использовали стриминг в основном для ознакомительного прослушивания музыки, которую затем покупали на виниле, CD или скачивали, чтобы воспроизводить «по-настоящему». Однако стремительное развитие стриминговых сервисов (более обширные каталоги, записи высокого разрешения), оборудования для стриминга (стримеры наконец стали зрелыми устройствами) и технологий в целом (экспоненциальный рост скорости интернета) привело к тому, что для многих аудиофилов стриминг стал одним из основных, а зачастую и главным способом прослушивания музыки.
Проводной Ethernet доминирует, поскольку Wi-Fi-приемники и медиаконвертеры на оптоволокне (FMC — к ним мы еще вернемся, поскольку они действительно могут быть полезны) создают и излучают радиочастотные помехи (RFI) рядом с чувствительными аудиосхемами. Однако у проводного Ethernet есть собственный недостаток — он переносит эти радиочастотные помехи по проводникам.
RFI является частью более широкого спектра электромагнитных помех (EMI), который сам по себе находится далеко за пределами человеческого слуха. Но если эти помехи проникают в аналоговые цепи ЦАП, они начинают интермодулировать с аудиосигналом, создавая слышимые искажения по всему слышимому диапазону частот. Уберите их — и разница становится очевидной: атака малого барабана, воздух в вокале, богатая фактура звучания виолончели приобретают большую насыщенность и естественность. Услышав это однажды, забыть уже невозможно.
Решение заключается в тщательном подборе и правильном размещении устройств и кабелей, уменьшающих количество RFI, достигающих ЦАП. Это включает использование оптимизированных для аудио сетевых коммутаторов и Ethernet-кабелей (именно о них мы сейчас говорим), а также самого стримера и кабелей SPDIF или USB между стримером и ЦАП. Последние, однако, выходят за рамки нашей беседы.
Хотя аудиофилы редко бывают полностью удовлетворены и постоянно ищут улучшения, большинство из нас в целом довольны звучанием своей системы — кажется, что никакой проблемы нет. Но существует возможность сделать звук лучше. И когда слышишь ту же систему с меньшим количеством помех или вовсе без них, это становится настоящим откровением — точнее, «откровением для ушей». После этого возвращаться к прежнему звучанию уже не хочется.
Расскажите об общей концепции ваших устройств и о том, как они защищают аудиосистему от помех, приходящих по сети Ethernet.
Основная задача при разработке продукции Reiki Audio — максимально эффективно устранять все виды радиочастотных помех: проводимые, излучаемые и создаваемые самим устройством. Если не решить хотя бы одну из этих проблем, общее качество звучания неизбежно пострадает, независимо от того, насколько успешно устранены две остальные.
Фраза «помехи, переносимые Ethernet» наверняка заставит некоторых сетевых инженеров поморщиться. Да, радиочастотные помехи действительно распространяются по проводникам и экранам Ethernet-кабелей, однако они никак не влияют на сами цифровые данные и не повреждают их — просто сопровождают их. Поэтому точнее говорить не о «помехах Ethernet», а о «сетевых помехах». Теперь, когда мы это уточнили и наши коллеги-сетевики могут вздохнуть спокойнее, можно продолжать.
Именно проводимые радиочастотные помехи обычно становятся первым объектом борьбы, поскольку их устранение быстрее всего приносит слышимый результат. Наиболее эффективно они устраняются двумя способами: во-первых, с помощью конструкции сетевого коммутатора (магнитные элементы Ethernet-портов, предназначенные для защиты оборудования от перенапряжений, одновременно защищают и от RFI, распространяющихся по проводникам); во-вторых, с помощью оптического волокна, которое гарантирует полное отсутствие проводимых помех во входящем сигнале. Правда, обратное преобразование света в электрический сигнал обычно само по себе создает дополнительные помехи. Несмотря на столь разные принципы работы, оба подхода обеспечивают существенное снижение уровня шума.
Не менее важно бороться с радиочастотными помехами, излучаемыми бытовыми устройствами — светодиодным освещением, микроволновыми печами, а также трансформаторами и электронными схемами другой аудио- и видеотехники. Основными средствами защиты здесь становятся конструкция корпуса устройства и правильное экранирование кабелей. Поскольку RFI имеет очень высокую частоту, она легко проникает даже через мельчайшие отверстия. Наши корпуса имеют толщину не менее 5 мм (10 мм у серии X), выфрезерованы из цельной алюминиевой заготовки высокого качества (по сути, состоят только из оболочки и основания) и дополнительно облицованы медью для усиления защиты. Мы придерживаемся очень жестких производственных допусков и устраняем любые отверстия, не являющиеся абсолютно необходимыми для воспроизведения музыки, включая потенциально ненужные разъемы и даже небольшие отверстия под светодиоды.
Особую проблему представляют кабели. С одной стороны, экранирование защищает проводники от внешних помех. С другой — если экран соединен с металлическими разъемами RJ45 с обеих сторон, как это обычно бывает, сам экран превращается в проводник радиочастотных помех. Именно поэтому большинство аудиофильских Ethernet-кабелей построены на стандарте Cat 8: они хорошо защищают проводники от внешнего излучения, но экран при этом может проводить шум по всей линии. Неэкранированный кабель лишен этой проблемы, однако становится уязвимым для излучаемых помех, которые затем сам же переносит дальше. Решением является заземление экрана только с одной стороны. Такая конструкция обеспечивает преимущества экранирования без недостатка в виде проводящего экрана. Само наличие экрана и его одностороннее подключение обеспечивает примерно 90% преимуществ такого кабеля независимо от направления его установки. Оставшиеся 10% зависят от того, куда именно отводятся помехи: в идеале — к расположенному выше по цепи сетевому коммутатору, а не к стримеру.
Наконец, необходимо минимизировать радиочастотные помехи, создаваемые самими устройствами, которые мы добавляем в сеть. Для этого внутри коммутатора или FMC тщательно подбираются компоненты, исключаются шумящие драйверы светодиодов и применяются дополнительные меры подавления электромагнитных помех.
Возвращаясь к оптоволокну: оно действительно может быть очень полезным, поскольку само волокно физически не способно проводить электрические помехи. Однако необходимо учитывать шум, возникающий при обратном преобразовании оптического сигнала в электрический. Именно поэтому большинство пользователей отмечают улучшение звучания, если между FMC и стримером устанавливается сетевой коммутатор. Для многих систем такое сочетание технологий оказывается оптимальным.
Каким еще образом качество Ethernet-инфраструктуры влияет на звук?
Я уже говорил о нашей бескомпромиссной борьбе с радиочастотными помехами. Но сначала хотел бы затронуть две темы, о которых многие, вероятно, ожидали бы услышать, хотя мы считаем их отвлекающими факторами.
Во-первых, специализированные аудиосетевые устройства и кабели не способны улучшить сами цифровые данные — включая их временные характеристики. Ethernet работает асинхронно, передает данные пакетами и использует механизмы обнаружения и исправления ошибок. Именно поэтому этот протокол настолько надежен. Джиттер действительно представляет проблему уже после стримера, в цифровом потоке, поступающем на ЦАП, поэтому точность и стабильность тактового генератора стримера действительно имеют значение. Но в пределах самой сети Ethernet это никак не влияет на качество звука.
Точно так же нет смысла обсуждать характеристики кабелей, актуальные для аналоговой техники, например скин-эффект или параметры LCR. Электрический сигнал, представляющий цифровые данные, достигает своей цели, а протокол Ethernet гарантирует правильную интерпретацию всех единиц и нулей. Следовательно, музыкальные данные поступают в абсолютно корректном виде. Форма электрического импульса — крутизна фронтов и прочие подобные параметры — в мире Ethernet просто не имеет значения.
Еще год-полтора назад я бы сказал, что на этом все заканчивается: устраните RFI — и задача решена.
Однако в последнее время нас удивило, насколько серьезное влияние на звук оказывают дополнительные факторы. Первый из них — качество источника питания. Мы всегда особенно гордились конструкцией наших блоков питания; некоторые даже называют это «секретным ингредиентом» Reiki. Но при разработке серии X мы уделили этой теме еще больше внимания, и полученный результат оказался неожиданно значительным.
Второй фактор — вибрации. Мы понимали, что корпус толщиной 10 мм будет лучше корпуса толщиной 5 мм не только благодаря более эффективному экранированию, но и большей жесткости. Когда же мы начали экспериментировать с виброизолирующими опорами, ожидали лишь небольшого эффекта: все-таки речь идет не об акустической системе, а о твердотельном устройстве, где возможны лишь микровибрации. Однако, как и в случае с блоками питания, полученный звуковой результат нас действительно удивил. Именно так началось наше сотрудничество с компанией Stack Audio.
Я вполне ожидаю, что другие производители будут уделять все больше внимания конструкции корпусов, источников питания и виброизоляции. Для аудиофилов это может быть только хорошей новостью.
Что могут сделать читатели, чтобы улучшить работу уже имеющегося оборудования?
Ранее я упоминал правильное размещение оборудования, и теперь хочу вернуться к этому вопросу. Меня удивляет количество аудиофилов, которые используют или пробовали использовать сетевой коммутатор, но устанавливают его рядом с маршрутизатором. Да, это помогает отделить аудиосистему от остальных домашних устройств и соединений, однако практически не снижает общий уровень радиочастотных помех, достигающих стримера, а затем и ЦАП. Помехи накапливаются по мере прохождения сигнала, поэтому бороться с ними эффективнее всего непосредственно перед стримером. Наилучший вариант — один коммутатор сразу после роутера и второй непосредственно перед стримером. Но именно второй, расположенный ближе к стримеру, оказывает наибольшее влияние на качество звучания.
То же относится и к кабелям: последний участок соединения наиболее критичен. Если используются Ethernet-кабели разного качества, то самый качественный и самый короткий (неэкранированный или с односторонним заземлением экрана) следует устанавливать между коммутатором и стримером. Прежде чем покупать новое оборудование, имеет смысл убедиться, что уже имеющиеся компоненты используются там, где они способны дать максимальный эффект. Тогда и любые дальнейшие инвестиции в оптимизацию сети принесут наибольшую пользу.
Удалось ли окончательно решить проблему сетевых помех, или впереди еще могут появиться новые технологии, способные дополнительно улучшить звук?
На каждом этапе своего развития Reiki Audio стремилась создавать лучшие продукты без каких-либо компромиссов. Мы всегда гордились своими устройствами и тем, как их воспринимают пользователи, будучи уверенными, что сделали максимум возможного. Но проходит год или чуть больше — и мы снова обнаруживаем возможность раздвинуть границы еще дальше.
Поэтому мне хотелось бы ответить: «Да, проблему сетевых помех мы решили». Однако накопленный опыт подсказывает, что это не конец. Я уже достаточно давно занимаюсь этим делом, чтобы понимать: никогда не стоит говорить «никогда». И сравнительно короткая история существования Reiki Audio снова и снова это подтверждает.
https://www.theabsolutesound.com/articles/removing-ethernet-noise/
10 лайков
Давайте не превращать общую тему в персональную техподдержку, пожалуйста.
Создайте свою и желающие вам там помогут.
2 лайка
Любопытная идея, надо будет проверить на своих Asus, особенно как обратно мост сам поднимается после одновременного сбоя в питании.
1 лайк