Кабеля так сильно меняют звук?

  • Автор темы Автор темы NoiVS
  • Дата начала Дата начала
Смотрю разные источники, и как-то по-разному в разных местах написано. Вот тут: http://microsin.net/programming/arm-working-with-usb/frame-usb-and-transfer-types.html, например тут вообще сказано так: "Isochronous Transfer. Это длинные пакеты без CRC. Изохронные передачи планируются с фиксированными интервалами времени. ". В принципе звучит логично. Зачем считать контрольную сумму, если все равно у нас нет возможности повторно запросить пакет? Что приняли, то приняли. CRC при такой передаче имела бы смысл, если позволяла ошибку не только проконтролировать, но и на ходу исправить.
А вот тут: https://www.beyondlogic.org/usbnutshell/usb4.shtml пишут, что CRC есть. Но не написано, что пакет с неправильной контрольной суммой отбрасывается целиком.
А вот здесь: https://electronics.stackexchange.c...upt-transfers-for-usb-where-to-learn-about-it как раз сказано, что при изохронной передаче ошибка в отдельных битах незаметна для слушателя, и что контрольная сумма игнорируется (It was assumed that single-bit errors couldn't possibly affect the quality (human perception) of sound or video, so the protocol didn't have much of control overhead and ignored CRC errors ).
Но еще написано, что в настоящее время из-за роста скорости передачи изохронный способ уже устарел и в USB 3.0 для передачи аудио применяется уже нормальный Bulk протокол, который упевает и контрольную сумму посчитать, и запросить повторно плохо переданный пакет.
при желании можно что хошь сделать, включая игнорирование контрольной суммы. Только черевато. На сколько я вижу и слышу - таки выбрасывают пакеты (отчетливые щелчки или даже треск)
На счет bulk - есть стандарт - UAC1\2 (usb audio class).
Вроде третий родили и может там bulk и юзают(не читал), но в реальной жизни все используют версию 1 (для примитивных моно\стерео гарнитур) и 2 (для многоканального аудио), а там написано изохронный режим с обратной связью и точка.
 
  • Like
Реакции: Alexander Yakuba
На сколько я вижу и слышу - таки выбрасывают пакеты
А смысл? Зачем вместо незначительного и мало заметного на слух искажения делать явный щелчок? Ведь каким бы качественным ни был кабель, особо сильная помехп все равно может испортить сигнал.
Естественно, щелки и треск аудиокарты мы все слышим, когда буфер не успевает выдать вовремя очередной пакет. Но это совсем другая история.
 
Зачем вместо незначительного и мало заметного на слух искажения делать явный щелчок?

А как это должно быть реализовано то на деле? Цифровой поток слетает, система должна всё притормозить на некоторое время, как-то апроксимировать соседние пакеты и заменить результатом потерянный? Или перезапрашивать недошедшие?

щелчок — очевидная реализация KISS принципа же…
 
  • Like
Реакции: Alexander Yakuba
А смысл? Зачем вместо незначительного и мало заметного на слух искажения делать явный щелчок? Ведь каким бы качественным ни был кабель, особо сильная помехп все равно может испортить сигнал.
Естественно, щелки и треск аудиокарты мы все слышим, когда буфер не успевает выдать вовремя очередной пакет. Но это совсем другая история.

я прошу прощения за возможно бестактный вопрос - но вы точно инженер?
Если да - то объясните мне, от чего вы берете за постулат вот это - "незначительного и мало заметного на слух искажения"?
Обычно при проектировании исходят не из наиболее благоприятного _непрогнозируемого_ события (ошибки в данном случае), а наоборот - из самого неблагоприятного. Там может один бит поменялся а может и нет. Может та меандр на полную амплитуду колбасит на 15 кгц и "привет твитер" за несколько сбойных пакетов к ряду (да, фантастика, но ровно такая же как и "всего один бит")
 
Может та меандр на полную амплитуду колбасит на 15 кгц и "привет твитер" за несколько сбойных пакетов к ряду (да, фантастика, но ровно такая же как и "всего один бит")
Это крайне маловероятное событие.
Пытаюсь найти правильную документацию, где бы явно указывалось, что происходит в изохронной передаче в при возникновении CRC Error. Пока не нашел. По-прежнему куча разных мнений, но ни одного прямого документа. Если у вас есть подобный документ, я был бы рад ознакомиться.
 
Это крайне маловероятное событие.
Пытаюсь найти правильную документацию, где бы явно указывалось, что происходит в изохронной передаче в при возникновении CRC Error. Пока не нашел. По-прежнему куча разных мнений, но ни одного прямого документа. Если у вас есть подобный документ, я был бы рад ознакомиться.
да причем тут документация - есть же просто разумный подход. Неверный пакте должен быть дропнут - может там постоянка?
Другими словами - если вы стоите перед открытыми дверьми шахты лифта и там темнота - то разумно предположить что там нет лифта и вы разобьетесь.

PS у рме (но то был файрфейс вроде, на файрвайре) - в панели настроек был счетчик ошибок (дропнутых пакетов).
Теоретически конечно можно заморочиться и пытаться восстановить пакет, эмпирически оценив стпенеь его "опасности" - но я так понимаю что их просто отбрасывают ибо ситуация как ни крути авариайная, и тут важнее дать понять что "эй юзер -у тебя что то не так с соединением" чем продолжать "замазывать шрамы чтоб было не видно"

Но тут дискуссия переходит уж совсем в плоскость "я художник я так вижу", так что смысла продолжать мучать друг друга не вижу =)
Очевидно что выбор того как обработаь нештатную ситуацию недоставки пакета лежит на разрабочтике и что тут спорить....
Но напомнбю что изначально все завертелось с того что "пакеты теряются чуть чуть" -> "ачх меняется чуть чуть да и ладно"
Таки считаю что это как минимум не нормальный режим работы и тут надо лечить а не замазывать.
 
  • Like
Реакции: Alexander Yakuba
Да ты чооо! Ну так читай тему-то? Или скажешь буквы непонятны? Во, гляди - первая же мессага:

Или опять непонятно?
Саша, мне как раз таки все понятно, а кому непонятно тот тему и завел. Ты какой-то агрессивный стал. Давай без нападок.
 
  • Like
Реакции: Long
PS у рме (но то был файрфейс вроде, на файрвайре) - в панели настроек был счетчик ошибок (дропнутых пакетов).

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

Сейчас просматривают