Wybór interfejsu audio

[industry.project]

A jaka jest odpowiedź na jego pytanie?

[matiz]

Nie chodzi o kłótnie i udowadnianie, kto wie lepiej. Można udowadniać, że bit jest bit i ma długość bitu, i aj się z tym zgadzam, ale praktyka pokazuje co innego. Nie wiem, dlaczego, nie znam się na architekturze komputerów, za to na audio się znam, podłączyłem, zmierzyłem, i wyniki mi wyszły jakie wyszły - interfejsy thunderbolt mają prawie dwukrotnie niższą latencję od bardzo cenionego Apogee. Różnice są znaczące i IMO różnica w opóźnieniu samych przetworników nie może być jedynym wyjaśnieniem, są raczej jeszcze jakieś inne rzeczy, jak np. przemilczany bufor wyjściowy w firewire.
Jeżeli komuś na niskiej latencji zależy, to dla niego może być ważne, jeżeli nagrywa tylko żywe instrumenty korzystając z direct monitoringu, to może mieć mniejsze znaczenie. W żadnym wypadku jednak nie pomijałbym znaczenia wartości latencji dla komfortu pracy i jakości finalnej nagrań - zwłaszcza, gdy ktoś nie zdaje sobie z tego sprawy lub co gorsza, zdaje i bagatelizuje to zjawisko.

[addsig]

[industry.project]

Witam,

ja z kolei trochę bym się nad tym ukłonił. Po przeanalizowaniu tego wątku mam pewne obawy.

Na codzień używam przetworników RME (tak zainwestowało studio w którym pracuje i nic mi do tego) W zasadzie latencja i tym podobne nigdy mnie nie interesowały, ze względu na synchronizację (czasową) cyfrową i direct monitoring.

Dzisiaj sprawdziłem jak tam z tymi "opóźnieniami" w naszym systemie i trochę zgroza patrząc na ten link, który Pan PWA wkleił.

Zaciekawiło mnie co to za "super rozwiązanie" ten thunderbolt.


Analizując ten wątek i "matematycznie" podchodząc do sprawy - na przykładach w artykule:

"44.1k/64 buffer" czyli 64/44100 = 0,00145 * 2 (gdyż roundtrip to ma być) * 1000 = 2,9 ms latencji najmniej.

dalej

"96k/128 buffer" czyli 128/96000 = 0,00133 * 2 * 1000 = 2,7 ms latencji najmniej.

U mnie w programie, pokazuje:

dla pierwszego przypadku - 4,3 ms (dolicza parę sampli na coś) w artykułe również 4,3
dla drugiego - 3,8 ms (dolicza parę sampli na coś - prawdopodobnie program coś potrzebuje) w artykule 3,1


Czyli wygląda na to, że cały ten thunderbolt różni się groszowo jeżeli chodzi o latencje audio względem usb 2.0, ma pewne uproszczenie w przetwarzaniu danych, ale dla 0,7 ms nie wiem czy warto by było skupiać swój wybór na interfejsie proponującym ten protokół komunikacji - na pewno nie było by to dla mnie krytycznym punktem jeżeli chodzi o wybór.

0,7 ms w latencji to pomijalne zjawisko, w przypadku nagrań wielościeżkowych takie rzeczy się kompensuje, głównie ze względu odległości mikrofonów od źródeł dźwięku.


I teraz pytanie do zaangażowanych w dyskusje:

Czemu falłorm błądzi we mgle jak dziecko? Wydaje mi się, że słusznie stawia pytanie. Po przeczytaniu paru artykułów Thunderbolt w kontekście interfejsów audio osobiście uważam, że ten protokół jest przereklamowany. Różnice w praktycznym zastosowaniu są żadne.

PS
Gorąco zachęcam do odpowiedzi na moje pytanie w osobnym wątku odnośnie przedwzmacniacza.

[fallworm]

...Według standardu USB 3 teoretyczna szybkość transmisji danych wynosi 5Gb/s. Zgodnie
ze standardem Thunderbolt 1 jest to 10 Gb/s. Oznacza to, że Thunderbolt prześle w
jednostce czasu (w tym wypadku sekunda) 1 bit informacji 2 razy szybciej niż USB 3.0...
tyle jeżeli chodzi o szybkość przesyłania. ... 

No i w tym momencie przypomniały mi się u profesora Gmyrka (PŁ) wykłady, na których
powiedział "Jeżeli ktoś z was sądzi, że protokół USB1.0 jest szybszy niż 2.0 to jest w
błędzie" Tak herezje, tak szkoła. eh . No dobra, pomijając już moją wiedzę i
wykształcenie
Umiesz odpowiedzieć na pytanie dlaczego 1 bit danych przepłynie szybciej lub nie
szybciej za pomocą różnych protokołów?
Pamiętaj, że w protokołach nie zmienia się szybkość tylko przepustowość - BANDWITH, a
1bit jest niepodzielny tych trybach komunikacji.
Wydaje mi się, że ta dyskusja jest bezsensowna. Każdy będzie wierzył jakimś tam
marketingowym artykułom itd.
 
Tak samo jest bezsensowne udzielanie się że ktoś "błądzi jak dziecko we mgle" lub
"głosi herezje", jeżeli samemu nie potrafi się udzielić odpowiedzi na pytanie.

Forum jest od dyskusji, poddawaniu wątpliwości, czegoś co może być nie pewnym. W tym
samym kontekście, ja mógłbym napisać, że ten to się nie zna, ten to ten, a tamten to
tamten, tylko po co? Każdy chce czerpać wiedzę, więc mu ją dajcie, jeżeli się nie
zgadzacie w wypowiedzią przedmówcy, napiszcie DLACZEGO. Chyba, że to forum amatorów -
tak bo tak, nie bo nie, bo tak napisał artykuł lub tak powiedział kaczor donald w
komiksie.

[matiz]

To, co "pokazuje program", to jedno, a rzeczywista latencja to drugie. Program nie uwzględnia opóźnień przetworników na przykład. Ja po prostu to brutalnie zmierzyłem i wyszło mi, że (z tych mierzonych oczywiście) interfejsy thunderbolt są pod tym względem najlepsze. Nie tylko opóźnienia są mniejsze, ale i obciążenie komputera czyli realna możliwość pracy z małym buforem też. Kto próbował ustawić bufor 64 na tanim interfejsie USB wie, o czym piszę
Nie wiem, dlaczego porównujecie dane z jakiegoś artykułu z tym, co "pokazuje program" i ze swoimi wyliczeniami. Realna sytuacja jest taka, że opóźnienia się różnią. Dla kogoś to ma znaczenie, dla kogoś nie. Oczywiście 0,7 ms to w sumie nic, ale praca z buforem 64 rzadko się udaje, w praktyce jest to conajmniej 128, a spotkałem się ze stwierdzeniami, że i 256 nie słychać. No cóż, jak 20ms nie słychać, to po co przepłacać

Tak, mam na tym punkcie lekką obsesję

[addsig]

[matiz]

Umiesz odpowiedzieć na pytanie dlaczego 1 bit danych przepłynie szybciej lub nie
szybciej za pomocą różnych protokołów?

Jak pisałem - to nie ma znaczenia, bo oczywiście jest, jak piszesz. Jednak opóźnienia interfejsów są różne, i co na to poradzisz?

[addsig]

[adn_01]

...
...


Niestety, wymądrzasz się jak to napisał ktoś na tym forum, głosisz herezje
...

W takim razie uprzejmie proszę o sprostowanie, poparte wiarygodnymi badaniami odnośnie tego tematu. Moje pytanie brzmi: dlaczego 1 bit informacji przepłynie przez thunderbolt szybciej niż przez usb i o ile szybciej.


bit (paczka, ramka) przepłynie z prędkością na jaką pozwoli mu magistrala. różnica polega na tym, że zanim popłynie kolejny upłynie ileś tam czasu. w usb więcej w thunderbolt mniej. 

wyobraź sobie to jak ruch na ulicy. w miasteczku USB zasuwasz np. 250 na godzinę ale co kawalek stajesz na światłach. w przypadku thunderbolt po prostu zasuwasz obwodnicą.

różnica nie jest wielka w przypadku audio, ale jest. 

[matiz]

http://en.audiofanzine.com/homestudio/editorial/articles/should-you-bolt-to-thunderbolt.html
... 

W końcu rzuciłem okiem - ten artykuł jest trochę tendencyjny, porównuje thunderbolt z firewire - w takim porównaniu oczywiście firewire jest bez szans. USB jest lepsze, ale znów - niewystarczająco lepsze. 

[addsig]

[fallworm]

Zdenerwowałem, się bo zaszły pewne niejasności, a na zadane konkretne pytanie nie ma odpowiedzi, zostałem nazwany "dzieckiem błądzącym we mgle" i "heretykiem" To trochę świadczy o poziomie doradczym użytkowników.

"Wiedza, jest dostępna w artykułach".

Kuźwa, parę lat temu broniłem drugą pracę magisterską, z architektury przepływu danych i żaden z artykułów na ten temat nie pomógł, nawet niektóre przedstawiały sprzeczne informacje, niezgodne z prawdą, ale zgodne z trendami rynkowymi.

Oprócz tego wiele lat pracuje w audio i znam większość niuansów i śmieszne rynkowe chwyty których dopuszczają się sprzedawcy.

Protokołu Thunderbolt nie znam, ale śmierdzi mi on jeżeli ktoś pisze "2x razy szybszy, 5x szybszy, 100x szybszy" . W przypadku audio, gdzie przepływ danych jest na prawdę groszowy to nie może być nawet 1,5 razy szybciej. Dla tego zadaje pytanie - dlaczego?

Ale już mniejsza o odpowiedź, może kiedyś ktoś mi wyjaśni.

Jak dla mnie na ten moment różnice czasów latencji dla różnych protokołów są bez znaczenia. <1 ms to jest nic i na pewno nie przekona mnie jakikolwiek artykuł, że pomiędzy 2,9 ms, a 3,4 ms jest 2x więcej jakiejś szybkości bo to bzdura zależna od dziesiątek czynników i od środowiska i systemu w którym pracujemy.

Jeżeli jestem źle postrzegany na forum to przepraszam, nie będę już się udzielał w tematach które mogą wydać się większości kontrowersyjne.

[matiz]

...Zdenerwowałem, się bo zaszły pewne niejasności, a na zadane konkretne pytanie nie ma odpowiedzi, zostałem nazwany "dzieckiem błądzącym we mgle" i "heretykiem" To trochę świadczy o poziomie doradczym użytkowników.

"Wiedza, jest dostępna w artykułach".

Kuźwa, parę lat temu broniłem drugą pracę magisterską, z architektury przepływu danych i żaden z artykułów na ten temat nie pomógł, nawet niektóre przedstawiały sprzeczne informacje, niezgodne z prawdą, ale zgodne z trendami rynkowymi.

Oprócz tego wiele lat pracuje w audio i znam większość niuansów i śmieszne rynkowe chwyty których dopuszczają się sprzedawcy.

Protokołu Thunderbolt nie znam, ale śmierdzi mi on jeżeli ktoś pisze "2x razy szybszy, 5x szybszy, 100x szybszy" . W przypadku audio, gdzie przepływ danych jest na prawdę groszowy to nie może być nawet 1,5 razy szybciej. Dla tego zadaje pytanie - dlaczego?

Ale już mniejsza o odpowiedź, może kiedyś ktoś mi wyjaśni.

Jak dla mnie na ten moment różnice czasów latencji dla różnych protokołów są bez znaczenia.
Jeżeli jestem źle postrzegany na forum to przepraszam, nie będę już się udzielał w tematach które mogą wydać się większości kontrowersyjne.
... 

KONKRETY!!!!!

Teoretyzujesz, mając całkowitą rację, że jeden bit trwa 1/44100 sekundy, i nikt z tym nie zamierza (chyba) polemizować. Jednak piszesz też, że: "przepływ danych jest na prawdę groszowy to nie może być nawet 1,5 razy szybciej", "nie przekona mnie jakikolwiek artykuł, że pomiędzy 2,9 ms, a 3,4 ms jest 2x więcej jakiejś szybkości bo to bzdura zależna od dziesiątek czynników i od środowiska i systemu" oraz "różnice czasów latencji dla różnych protokołów są bez znaczenia" - a to już nadużycie. Dla mnie różnice latencji nie sąbez znaczenia, są to wartości różniące się DWUKROTNIE, i to w porównaniu z jednym z najlepszych interfejsów USB, na tym samym komputerze i oprogramowaniu. Nie odpowiem na pytanie dlaczego, bo nie wiem, ale to nie znaczy, że te różnice nie istnieją. Istnieją, unikami tego nie zmienisz

[addsig]