Сетевое хозяйство меломана — роутеры, хабы и сетевые хранилища (часть 1)

Спойлер - старая шапка

Тут все как раз просто - сеть не должна быть аудиофильской - она просто должна быть правильно организованной. :slight_smile:

1 Наименьшее количество посредников между точками (то есть D100 или что-то еще - роутер).Без дополнительных хабов между ними - для примера.
2 Хороший роутер (по максимуму ) для пропускной способности без ограничения.
3 NAS с хорошей скоростью (причем не только потока , но и мелких запросов).
4 Управляющее устройство - полноправный элемент , если оно использует вайфай (как обычно) то для роутера еще прибавляется головняков для передачи между беспроводным и проводным сегментами.

Ну это так - основное. Еще много нюансов на самом деле. Типа утилизации сети посторонними потребителями во время использования для аудио.

Особенно все влияет на устройства с потоковым исключительно вариантом получения контента, при этом не являющимися самими сервером для его “получения”.

Краткая история компьютерного аудио в вольном перессказе:

Общепринятыми “заветами” по организации сетей в аудио раньше были такие:

эпоха 2000-2010 года, выход большого количества внешних ДАКов на рынок

  1. наикратчайший путь данных (сервер как можно ближе к цапу)
  2. никаких wi-fi в аудио не допускается - только кабели и оптика

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

Наигравшись вдоволь с большими PC, переделав кучу железных и программных твиков аудиофилы стали обращать внимание на более “легкие” и менее шумные в электрическом плане решения ввиде цифровых транспортов на основе одноплатных компьютеров SoC (серия rendu от sonore, хайп по RPI итд)

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

появления tidal 2014й год - первый loseless стриминг сервис для аудиофилов

В связи с этим аудиофилы всего мира стали обращать внимание на то что организация “лановского” сетевого хозяйства ощутимо сказывается на качестве и характере воспроизведения. Появляются аудио патчкорды, начинается применение свитчей для очищения сигнала от помех. Идея “короткого тракта” данных (“завет” номер 1), таким образом отбрасывается как несостоятельная. Знаковый момент это принятие сообществом энтузиастов решения от jplay (популярных в PC эпоху разработчиков аудиософта), основанного на разделении сервера и endpoint с помощью локальной сети. Такой подход потом стал общепринятым в индустрии.

2017й год появление бесконечной ветки эзернет твиков на форуме computer audiophile (сейчас audiophylestyle)

2018 по нынешнее время

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

– лето-осень 2020 эксперименты с воздушной развязкой на dastereo

Во время начала пандемии в РФ я обратил внимание что завет2 (про неприменимость wi-fi в аудио) тоже сомнителен. Ведь все стереотипы про wi-fi связаны с качеством встроенных в стримеры приемников, которые никто ранее не пробовал улучшать.

С помощью глобального фидбека от сообщества dastereo и ближайших коллег по хобби, это привело к идее воздушного моста, как способа изоляции аудиосистемы от компьютерных помех:

UPD: Wifi-Bridge Trend, начало примерно в ноябре 2020!
Схема:

Идея в двух словах:
Есть два участка сети: “чистый” и “грязный” берег. “Чистый” - аудио, “Грязный” - все остальное.

Они разделены Wi-Fi мостом. Почему? Чтобы не было соединения берегов через физический кабель езернет или оптику. Оба переносят с одного берега на другой весь сопуствующий передачу данных мусоро-шум. Оптика это делает с конвертацией, частично отсекая самые вредные шумы, но чистки или, точнее изоляции, полноценной не происходит.

Грязный берег” справа, где обычный роутер и куча мультимедии: компы, роутеры, сервера, ТВ приставки и т.д. На этом берегу в идеале иметь БП, которые не гадят в общую электро-сеть (если аудио девайсы подключены туда же) и чтоб езернет кабели не проходили близко или вдоль электро-проводки, т.е. опять же в сеть не просачивался мусор-шум через наводки из езернет кабеля.

Чистый берег” слева, где у нас аудио система. Основная идея здесь: отделить грязный берег с помощью минимально шумащего Wi-Fi моста (чем проще девайс, тем лучше, гасим все ненужные фишки, понижаем мощность, если сигнал и так хорош, 100Мб приоритет, для RedBook можно понижать до 10Мб.). И уже его отделить от стримера еще проще свичем, как никак Wi-Fi шумный девайс. Оба девайса посадить на качественное питание. Кабельная обвязка и БП тут критичны. Вваливаем по полной, товарищи, на чистом берегу.

12 лайков

Т.е. тут ещё и смартфон влияет, где запущена Bubble UPNP для Tidal?

Ужос! :grin:
Но к флешки больше не вернусь. Уж очень удобно с NAS.

При очень большом количестве разномастного контента - да , удобно. :slight_smile:
Второй вариант организовать питание для внешнего винта (SSD вообще супер со всех сторон кроме цены) и все будет тоже неплохо.

Влияет не сам смартфон - а производимые софтом манипуляции с его помощью.

Вариант воткнуть сетевой плеер напрямую в NAS минуя роутеры и хабы предпочтительнее?

Если NAS имеет возможность подлерживать функционирование сети( по сути он и есть еще и роутер). В противном случае необходим координатор всего сетевого хозяйства.

1 лайк

Не имеет. Всего одна сетевая дырка у него. Я готов отказаться от управления с iPhone (ведь есть родной пульт от плеера) если вариант подключения напрямую лучше чем через роутер.

Тогда без посредника не обойтись. Кто то должен рулить сетью, увы.

хотите сказать, что без “посредников” д100 воткнутый напрямую в НАС не будет играть (видеть файлы)?
Я готов отказаться от сети, если д100 играет лучше когда НАС подключён напрямую в д100.

А кто скажет d100 что у него NAS на другом конце кабеля, а не просто хабик? Кто поддержит протокол,даст адреса устройствам и прочие коммунальные удобства? Было бы так просто все бы так и делали. :slight_smile:

1 лайк

Ай, карамба! Забыл совсем про DHCP.

1 лайк

Приходится терпеть все тяготы и лишения классического сетевого построения.

  1. Я знаю отличную шутку про UDP, но не факт, что она до вас дойдет.
  2. Я знаю отличную шутку про TCP, но если она до вас не дойдет, то я повторю.
  3. А кто знает отличную шутку про ARP?
  4. А вы слышали шутку про ICMP?
  5. Вам еще кто–то рассказывал шутку про STP?
  6. Я подожду Антона и расскажу классную шутку про QoS.
  7. Про MTU тоже есть кла
  8. XML
  9. А про FSMO роли шутить могут не более пяти человек.
  10. Подождите все, я расскажу шутку о сети типа “шина”.
  11. Я бы рассказал отличную шутку про Token Ring, но сейчас не моя очередь.
  12. Стой–стой, послушай сначала шутку о прерываниях.
  13. Помню времена, когда шутка про модем пшшшшшшш…
  14. Только что, специально для сообщества пришла шутка про мультикаст.
  15. Жаль, что шутка про Fault Tolerance не может состоять больше, чем из одного слова.
  16. Настало время рассказать шутку про NTP.
  17. Я сейчас расскажу отличную шутку про VPN, но ее поймет только один.
  18. К шутке про SCTP вначале должны все подготовиться.
  19. Из–за одного, кто зевнул, придётся заново рассказывать шутку про frame relay в топологии point–to–multipoint.
  20. А шутки про HDLC обычно не понимают те, кто знает другие шутки про HDLC.
  21. Про DWDM шутят сразу несколькими голосами.
  22. Шутка про Е3 — это 30 одинаковых шуток про Е1 и еще две шутки, понятных только тем, кто в теме.
  23. Лучшее в шутках про проприетарные протоколы это УДАЛЕНО.
  24. Единственная проблема в шутках про Token Ring в том, что если кто–то начнёт рассказывать шутку пока говорите вы, обе шутки обрываются.
  25. Все любят шутки про MitM. Ну, кроме Алисы и Боба, все.
  26. идти Самое про BitTorrent — они могут порядке. в шутках лучшее в любом
  27. Я бы рассказал шутку про CSRF, если бы ты САМ только что этого не сделал.
  28. IGMP шутка; пожалуйста, передай дальше.
  29. Нет… Нет ничего… Нет ничего забавного… Нет ничего забавного в шутках… Нет ничего забавного в шутках про определение MTU.
  30. PPP шутки всегда рассказываются только между двумя людьми.
  31. Шутки про RAID почти всегда избыточны.
  32. Фрагментированные шутки…
  33. … всегда рассказываются…
  34. … по кусочкам.
  35. Вы уже слышали шутку про Jumbo фреймы? Она о–очень длинная.
  36. Самое клёвое в шутках про rsync, что вам её рассказывают только если вы не слышали её до этого.
  37. Проблема с IPv6 состоит в том, что их трудно вспомнить.
  38. DHCP шутки смешны, только если их рассказывает один человек.
  39. Жаль никто не помнит шутки про IPX
  40. У кого есть кабель? Есть смешная шутка про RS–232 и полусмешная про RS–485
  41. Я сейчас всем расскажу шутку про бродкаст
  42. У меня есть примерно 450 000 шуток про BGP
  43. У кого есть пароли, приходите за шутками про RADIUS
  44. Шутку про 127.0.0.1 каждым может пошутить себе сам
  45. А что, шутки про IPv4 уже закончились?
  46. Шутки про RFC1918 можно рассказывать только своим
  47. Шутки про IPv6 плохи тем, что их мало можно кому рассказать
  48. Шутки про SSH–1 и SSH–2 несовместимы между собой
  49. Про Schema Master шутит только один в этом лесу
  50. Шутки про MAC–адрес могут не дойти до тёзок
    xx. Тут шутка про Banyan подросла
  51. DNS–сервер не понял шутку про DDoS и ему её стали пересказывать сто тысяч раз в секунду
  52. В шутках про IPSec надо говорить, кому их рассказываешь
  53. И ГОСТ и ISO согласны, что есть 7 уровней рассказывания шуток
    52.1 Министерство обороны США понимает только четыре уровня шуток
  54. Шутки про шутки про шутки часто звучат в туннелях
  55. Шутки про 10/100/1000BASE–T вряд ли услышат с расстояния больше 100 м
    Off: Шутки про TFT оставляют смазанное впечатление
22 лайка

Приятно видеть админов :)))

Sonic transporter вам в помощь! :slight_smile:

Это что?

A что , не гуглится ? :slight_smile:

You’re are welcome.

Пользуюсь Яндекс. Так вот он не знает про это.