Audiofilski Switch?

[Krzysztof_56775]

15 godzin temu, piszcz4 napisał:

Dzięki za info. Czyli sobie odpuszczę. Jeżeli piszesz, że "

Ogólnie połączenie światłowodem brzmi gładziej, trochę cieplej, kosztem rozdzielczości i dynamiki" to ja za to dziękuję, ponieważ jest to ograniczenie sygnału. 

Jaki kabel proponujesz?

Nie poddawaj się, warto spróbować.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[sir.jax]

15 godzin temu, piszcz4 napisał:

Dzięki za info. Czyli sobie odpuszczę. Jeżeli piszesz, że "

Ogólnie połączenie światłowodem brzmi gładziej, trochę cieplej, kosztem rozdzielczości i dynamiki" to ja za to dziękuję, ponieważ jest to ograniczenie sygnału. 

Jaki kabel proponujesz?

Tani i robi robotę.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

Zależy ile metrów potrzebujesz, jak niedużo, ale chcesz znacznie lepiej, to ten:

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) Edytowane 28 Listopada 2023 przez sir.jax

[kaviter]

Ten Lapp jest OK, ale nie umywa się do dedykowanych kabli audio. Do tego jest gruby i bardzo sztywny, zasadniczo nie przeznaczony do terminacji wtykami (da się na niego załozyć tylko telegartnery). Swoją drogą niezłą przebitkę mają za kabel który w detalu kosztuje 8zł za metr.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[ASURA]

35 minut temu, kaviter napisał:

Ten Lapp jest OK, ale nie umywa się do dedykowanych kabli audio. Do tego jest gruby i bardzo sztywny, zasadniczo nie przeznaczony do terminacji wtykami (da się na niego załozyć tylko telegartnery). Swoją drogą niezłą przebitkę mają za kabel który w detalu kosztuje 8zł za metr.

U Conrada drą przez głowę… mam do kina po piętrach wtopione w ścianę trochę metrów i tam styknie.
Oczywiście wszystko zarobiłem sobie na Telegartnerach. Do audio z modemu mam specjalnie robiony i jest mz. Ok

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[kaviter]

18 minut temu, ASURA napisał:

mam do kina po piętrach wtopione w ścianę trochę metrów i tam styknie

 

Ja też całą sieć w domu mam zrobioną tym przewodem. 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[RCD]

Ten Lapp nie nadaje się na ostatni odcinek w audio, (do transportu czy streamery) nie ma nic wspólnego z gładkością i muzykalnością 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[piszcz4]

Jeśli chodzi o kabel, to potrzebuję 1,5m. Myślałem właśnie o Wireworld Starlight ewentualnie o Chroma. Tak naprawdę nic nie ma w internecie o kablach ethernet i ciężko wybrać coś do testów. Inna sprawa, że to tylko 0 i 1, ale jeśli 0 i 1 to zawsze taki sam sygnał, to dlaczego każdy streamer gra inaczej? Przecież dalej jest DAC i dopiero w torze analogowym powinny zachodzić zmiany w skutek zniekształceń. No tak czy nie? Więc albo wmawiają nam, że każdy streamer gra inaczej i kłamią bo to nieprawda, albo jednak kabelki ethernetowe mają sens, ale ich czas jeszcze nie nadszedł:-). Jak czytam internet, to drewniane podkładki za 30 tysięcy już są przeszłością 🙂 Jeśli chodzi o Lapp to zrobiłem sobie kiedyś z przewodu tej firmy kabel zasilający i tragicznie mi to grało. Strasznie technicznie i szorstko, a to w porównaniu do zwykłego kabla z marketu więc lapp od 10 lat leży w szufladzie. Wypożyczę sobie oba Wireworldy  i zobaczymy co z tego wyjdzie. Mam też zamiar wypożyczyć sobie zasilacz liniowy do routera. Jeśli będą zmiany na plus to zasilacz i kable zostaną. Kolejny krok to chyba zrobię izolację i sam się przekonam. Nie są to duże koszty, myślę że warto spróbować. Oczywiście wszystko po kolei w odstępach czasowych.

Dam znać jakie były efekty testów. Jeśli ktoś ma jakieś sugestie, pomysły etc to proszę pisać. 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) Edytowane 28 Listopada 2023 przez piszcz4

[RCD]

10 minut temu, piszcz4 napisał:

Jeśli chodzi o Lapp to zrobiłem sobie kiedyś z przewodu tej firmy kabel zasilający i tragicznie mi to grało. Strasznie technicznie i szorstko,

Dobrze słyszysz, ten kabel tak samo gra w sieci Ethernet, nie może być stosowany jako ostatni odcinek bo będzie właśnie technicznie i ostro, ale cóż jak widać niektórzy tak lubią 

 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[ProjectPi]

Grajace w ethernecie skretki. Cuda na kiju.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[jar1]

27 minut temu, piszcz4 napisał:

Jeśli chodzi o kabel, to potrzebuję 1,5m. Myślałem właśnie o Wireworld Starlight ewentualnie o Chroma. Tak naprawdę nic nie ma w internecie o kablach ethernet i ciężko wybrać coś do testów

Ja, po separacji optykiem mam takiego:

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

Mnie spasował całkiem fajnie, jedynie musi grać z tydzień. 

Chyba, ze ktoś bardziej słucha dźwięków niż muzyki, to raczej nie przypasuje.

 

 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[ProjectPi]

Wireworld

"Na początku warto zwrócić uwagę na powielany błąd – że w przesyle sygnału cyfrowego nie dochodzi do strat informacji, ponieważ to „po prostu” „jedynki” i „zera”

Kiedy przesyłamy te zera i jedynki przez kabel i kiedy te jedynki i zera pojawiają się na jego drugim końcu, kiedy zapiszemy plik wiemy, że dotarły na miejsce, ponieważ działa tam system korekcji, który przesyła ponownie wszystko, czego ewentualnie brakuje przy pierwszym przesyle.

Jeśli przez chwilę nad tym pomyślimy, zrozumiemy że system korekcji błędów jest prawdopodobnie niezbędny i tak naprawdę nie wszystkie informacje docierają na miejsce za pierwszym razem.

Dlatego właśnie sygnał musi być przesłany raz jeszcze. Kiedy Streamujemy muzykę przez kabel Sthernetowy lub USB, nie działa żaden system korekcji błędów, nie ma ponownego przesyłania informacji.

Cokolwiek zostanie przesłane za pierwszym razem, będzie to cała muzyka, którą potem usłyszymy.

Widać więc, że argument o jedynkach i zerach, jest błędny.

A kiedy naprawdę posłuchamy Streamowanej muzyki przez różne kable cyfrowe, zobaczymy że kiedy zmienimy kabel, zmieni się też dźwięk.

To, czego tak naprawdę szukamy, to kabel, który pozwoli nam usłyszeć jak najwięcej muzyki, która jest przesłana.

Gdyby to był idealny przesył, muzyka powinna brzmieć dokładnie tak samo, jak brzmiała zanim przesłaliśmy ją przez kabel.

Właśnie dlatego firma Wireworld opracowała przewód Ethernet CAT8.

Chodziło o to, aby przygotować kabel, który będzie szybszy, cichszy i będzie wprowadzał mniej błędów - już wiemy, że mamy tylko jedną szansę.

Kiedy słuchamy muzyki za pomocą Starlight 8 Ethernet, słyszymy więcej detali, większą dynamikę, lepszą czystość, wszystko jest bardziej podobne do oryginalnego sygnału, zanim został przesłany przez kabel."

 

Grubo. A pozniej ktos to czyta, na tej podstawie kupuje, a jak ma zapedy to jeszcze kontynuuje trend publikowania bzdur.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[jar1]

Każdy w miarę rozgarnięty człowiek wie, że marketing jest dla idiotów. A tu widzę, że co chwile ktoś wpada, i odkrywa  coś,  co powszechnie nawet dzieci w podstawówce znają. 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[piszcz4]

42 minuty temu, ProjectPi napisał:

Dlatego właśnie sygnał musi być przesłany raz jeszcze. Kiedy Streamujemy muzykę przez kabel Sthernetowy lub USB, nie działa żaden system korekcji błędów, nie ma ponownego przesyłania informacji.

Już to gdzieś czytałem. Ciekawe tylko, dlaczego wszędzie ta korekcja jest, a w sprzętach audio akurat nie ma? Śmierdzi mi to, więc jeśli są różnice to raczej nie wynikają one akurat z braku tej korekcji. Muzyka na żywo jest tylko na koncercie! W domu sygnał zawsze przesyłany jest z opóźnieniem, z tym że w zależności od urządzenia różny jest czas opóźnienia. 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) Edytowane 28 Listopada 2023 przez piszcz4

[ProjectPi]

21 minut temu, piszcz4 napisał:

Już to gdzieś czytałem. Ciekawe tylko, dlaczego wszędzie ta korekcja jest, a w sprzętach audio akurat nie ma? Śmierdzi mi to, więc jeśli są różnice to raczej nie wynikają one akurat z braku tej korekcji. Muzyka na żywo jest tylko na koncercie! W domu sygnał zawsze przesyłany jest z opóźnieniem, z tym że w zależności od urządzenia różny jest czas opóźnienia. 

Nie watpie, ze juz gdzies czytales, tak dziala powielanie bzdur. Korekcji nie ma przy transmisji izochronicznej jak miedzy streamerem a DACem. Przy transmisji pakietowej po skretce w ramach ethernet korekcja jak najbardziej jest. Nawet dla sprzetu audio.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[Piopio]

3 godziny temu, ProjectPi napisał:

Korekcji nie ma przy transmisji izochronicznej jak miedzy streamerem a DACem.

Za to jest bufor. 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[marcinmarcin]

2 godziny temu, Piopio napisał:

Za to jest bufor. 

a co pomoże bufor na źle przesłane (błędne) dane? Inna sprawa że nie demonizowałbym błedów transmisji - sprawdzałem zarówno z maliny jak i PC na RME Adi i było bitperfect.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[jar1]

Bufor i separacja, to przecież najważniejsze. 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[ProjectPi]

3 godziny temu, Piopio napisał:

Za to jest bufor. 

I obudowy czarne tez sa.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[Pseudodrummer]

27 minut temu, jar1 napisał:

Bufor i separacja, to przecież najważniejsze. 

galwaniczna

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[pmcomp]

Godzinę temu, marcinmarcin napisał:

a co pomoże bufor na źle przesłane (błędne) dane? 

No zgadnij …

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) Edytowane 28 Listopada 2023 przez pmcomp

[xsnailx]

W dniu 28.11.2023 o 13:23, ProjectPi napisał:

Nie watpie, ze juz gdzies czytales, tak dziala powielanie bzdur. Korekcji nie ma przy transmisji izochronicznej jak miedzy streamerem a DACem. Przy transmisji pakietowej po skretce w ramach ethernet korekcja jak najbardziej jest. Nawet dla sprzetu audio.

Po 1. nie każdy dac używa tego trybu - jest całkiem sporo a nawet większość które działają w ludzkim czyli asynchronicznym trybie 😉

po 2.  Poniższy wycinek z loga serwera roona powinien załatwić temat dyskusji o wpływie kabli / zegara w switchu raz na amen skoro argumenty bazowane na budowie protokołu tcp/ip nie docierają:

 

Cytat

12/21 10:11:31 Info: [Okto] [zoneplayer] Open result (Queueing): Result[Status=Success]
12/21 10:11:31 Info: 
--[ SignalPath ]---------------------------------------------
SignalPath Quality = Lossless
Elements:
    Source Format=Flac 44100/16/2 BitRate=648 Quality=Lossless
    Raat Device=DAC8STEREO
    Output OutputType=Local_Alsa Quality=Lossless SubType= Model=DAC8STEREO
------------------------------------------------------------
12/21 10:11:33 Trace: [Okto] [Lossless, 16/44 FLAC => 16/44] [100% buf] [PLAYING @ 0:02/7:05] Omrids - Lauge / AES Dana
12/21 10:11:33 Trace: [Okto] [zoneplayer/raat] sync DAC8STEREO: realtime=1777145788718 rtt=500us offset=-8059112211us delta=-200us drift=4785us in 1777,0395s (2,693ppm, 9,694ms/hr)
12/21 10:11:33 Info: [stats] 12045mb Virtual, 1413mb Physical, 746mb Managed, 353 Handles, 83 Threads
12/21 10:11:38 Trace: [Okto] [Lossless, 16/44 FLAC => 16/44] [100% buf] [PLAYING @ 0:07/7:05] Omrids - Lauge / AES

 

Czyli praktycznie mamy cały utwór zbuforowany w odtwarzaczu ... co zatem robi w tymczasie switch / zegar w nim - a no nic

 

 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[ProjectPi]

9 minut temu, xsnailx napisał:

Po 1. nie każdy dac używa tego trybu - jest całkiem sporo a nawet większość które działają w ludzkim czyli asynchronicznym trybie 😉

Nie kojarze, zeby z jakims DACem bylo inaczej. Izochronicznosc to nie synchronicznosc, nie jest przeciwstawna asynchronicznosci w rozumieniu tego, ktory zegar steruje przeplywem i czy jest dostarczana na ten temat informacja zwrotna. Transmisja w ramach usb audio jest izochroniczna i asynchroniczna zarazem.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[xsnailx]

2 minuty temu, ProjectPi napisał:

Nie kojarze, zeby z jakims DACem bylo inaczej. Izochronicznosc to nie synchronicznosc, nie jest przeciwstawna asynchronicznosci w rozumieniu tego, ktory zegar steruje przeplywem i czy jest dostarczana na ten temat informacja zwrotna. Transmisja w ramach usb audio jest izochroniczna i asynchroniczna zarazem.

Kiedy komputer wysyła strumień audio do portu USB, najpierw odczytuje dane z dysku twardego i buforuje bloki danych w pamięci. Następnie jest buforowany z pamięci do portu wyjściowego w postaci ciągłego strumienia (tryb izochroniczny) i Ramki danych są wysyłane co milisekundę. Dzieje się tak niezależnie od tego, czy w ramce znajdują się jakieś dane, czy nie. Szybkość wysyłania ramek jest określana przez oscylator sterujący magistralą USB. Szybkość ta jest niezależna od wszystkiego innego, co dzieje się na komputerze - W zasadzie gwarantuje to stały przepływ ramek.
W praktyce ramki mogą nie być prawidłowo wypełnione danymi, ponieważ jakiś program po prostu obciąża procesor lub magistralę PCI / PCI Express. Transfer danych Audio poprzez usb do DAC można następnie wykonać za pomocą trzech możliwych typów trybów synchronizacji (Synchroniczna, adaptacyjna i asynchroniczna ) USB.

• Synchroniczny 

1. Zegar sterujący przetwornikiem cyfrowo-analogowym jest bezpośrednio wyznaczany na podstawie częstotliwości odświeżania 1 kHz.
2. Ten tryb był używany przez wczesne urządzenia audio USB i praktycznie wypadł z obiegu
3. Były ograniczone do 48 kHz 

• Adaptacyjny

1. W tym trybie taktowanie jest generowane przez oddzielny zegar.
2. Obwód sterujący (zgadywanie częstotliwości próbkowania) mierzy średnią szybkość danych przychodzących magistralą i dostosowuje do niej zegar.
3. Ponieważ zegar nie jest wyprowadzany bezpośrednio z sygnału magistrali, jest znacznie mniej wrażliwy na jitter magistrali niż w trybie synchronicznym, ale to, co dzieje się na magistrali, nadal może na niego wpływać.
4. Nadal jest generowany przez PLL, który przejmuje kontrolę od obwodów rejestrujących jitter na magistrali.

• Asynchroniczny

1. W tym trybie używany jest zegar zewnętrzny do wyprowadzania danych z bufora, a strumień informacji zwrotnej informuje hosta, ile danych ma wysłać.
2. Obwód sterujący monitoruje stan bufora i informuje hosta, aby zwiększył ilość danych, jeśli bufor jest zbyt pusty, lub zmniejszył, jeśli staje się zbyt pełny.
3. Ponieważ zegar odczytowy nie jest zależny od niczego, co dzieje się na magistrali, może być zasilany bezpośrednio z oscylatora o niskim jitterze, bez konieczności stosowania PLL.
4. Ten tryb jest praktycznie niewrażliwy na jitter magistrali

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[ProjectPi]

I to pozostaje w zgodzie z tym, co napisalem. Jest izochronicznie zawsze, bo strumieniowo, a czy przy tym synchronicznie czy asynchronicznie, to zalezy. W usb audio najczesciej asynchronicznie, a dla spdif synchronicznie.

Skutkiem izochronicznosci jest niemoznosc korygowania raz wyslanych danych.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[xsnailx]

7 minut temu, ProjectPi napisał:

I to pozostaje w zgodzie z tym, co napisalem. Jest izochronicznie zawsze, bo strumieniowo, a czy przy tym synchronicznie czy asynchronicznie, to zalezy. W usb audio najczesciej asynchronicznie, a dla spdif synchronicznie.

Skutkiem izochronicznosci jest niemoznosc korygowania raz wyslanych danych.

Tylko ze ta izochronicznosc występuje nie jako warstwę niżej niż asynchroniczność. wiec praktycznie można ja pominąć. 

oczywiście zawsze można znalesc "edge-case" w postaci błędów w oprogramowaniu sterownika czy to kontrolera usb w pc czy  karty sieciowej który będzie np. szatkował dane mimo zgłoszenia poprawnego odebrania ramki. ale to jest tak pomijalne obecnie ze nawet nie warto o tym dyskutować - Bo każdy producent takiego sterownika wyleci z rynku 🙂

Oczywiscie jak ktos chce sprawdzic w jakim trybie pracuje dany dac to polecam podlaczyc dac do komputera z windows i uzyc tego narzedzia :  

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

w wypadku asynchronicznego daca powinno po wybraniu go z wybieraka w oknie znalesc sie cos takiego w sekcji 'endpoint descriptor'  wartosc bmAttributes = 0x5 (USB_ENDPOINT_TYPE_ASYNCHRONOUS).

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[ProjectPi]

10 minut temu, xsnailx napisał:

Tylko ze ta izochronicznosc występuje nie jako warstwę niżej niż asynchroniczność. wiec praktycznie można ja pominąć. 

Nie wtedy, gdy mowa o braku mozliwosci korygowania, bo to jest bezposrednia konsekwencja izochronicznosci.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[xsnailx]

2 minuty temu, ProjectPi napisał:

Nie wtedy, gdy mowa o braku mozliwosci korygowania, bo to jest bezposrednia konsekwencja izochronicznosci.

tak, w trybie adaptacyjnym i synchronicznym. tyle ze to zamierzchle czasy usb audio przed ok 2010 -  oczywiscie warto sobie dac sprawdzic w/w narzedziem by spac spokojnie

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[ProjectPi]

Asynchronicznosc nic tu nie wniesie, bo i tak dalej bedzie izochronicznie, a co za tym idzie bez korygowania.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[xsnailx]

24 minuty temu, ProjectPi napisał:

Asynchronicznosc nic tu nie wniesie, bo i tak dalej bedzie izochronicznie, a co za tym idzie bez korygowania.

Xmos jednak twierdzi troche inaczej: 

owszem audio leci izoscynchronicznie lecz używany jest transfer w trybie interrupt do zarządzania statusem + bufor 2 ramkowy i ew retransmisja - a i tak każda ramka w usb na poziomie kabla ma pole CRC - poza handshake (ale to nie ma znaczenia w tym wypadku)- ramka data wygląda tak:

 

• Ukryta Zawartość

  Zaloguj się, aby zobaczyć treść.
  Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

• Ukryta Zawartość

  Zaloguj się, aby zobaczyć treść.
  Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

• Ukryta Zawartość

  Zaloguj się, aby zobaczyć treść.
  Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą )

[ProjectPi]

Cytuje

"Isochronous: Periodic and continuous transfer for time-sensitive data. There is no error checking or retransmission of the data sent in these packets. This is used for devices that need to reserve bandwidth and have a high tolerance to errors. Examples include multimedia devices for audio and video."

 

"Both UAC1 and UAC2 define the use of isochronous transfers for audio data."

 

"As mentioned earlier, UAC uses isochronous transfers to guarantee bandwidth availability and every UAC device must therefore implement Isochronous Endpoints."

Feedback do zarzadzania nie jest czescia izochronicznej transmisji danych audio.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

Zaloguj się, aby zobaczyć treść (możliwe logowanie za pomocą ) Edytowane 21 Grudnia 2023 przez ProjectPi