DAC + PC/PS4Pro/Malina - jakość dzwięku

[m4tech]

@morawka podziwiam Cię że chce ci się w ogóle dyskutować, ja już dawno odpuściłem dyskusję z tymi, którzy uważają granie z plików za kopiowanie piku z dysku C na dysk X.

Poniżej świeży test i porównanie kabli usb, Ci co porównują kopiowanie pdf do grania przez usb niech tego nie czytają, nie ma sensu :)

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ą )

[init0]

3 godziny temu, fozzie napisał:

To przeczytaj uważnie linki, które podałem, który również Ty podałeś. To nie są linki od sprzedawców kabli USB.

Tak jak wspomniałem mylisz pojęcia.

Typ asynchroniczny (nie tryb asynchroniczny) to jeden z trzech typów synchronizacji danych w trybie izochronicznym.

A USB audio obecnie najczęściej używa się trybu izochronicznego z asynchronicznym typem synchronizacji danych.

Tryb izochroniczny jest trybem jednokierunkowym.

Tak, jak piszesz, wystarczy przeczytać ze zrozumieniem.

Przeczytałeś, to teraz zastanów się teraz jaki ma wpływ kabelek usb? (warunek to spełnienie parametrów elektrycznych zgodnie ze standardem). Tak się składa, że jeśli zrozumiałeś konstrukcję protokołu to powinno być jasne, że rodzaj przewodu nie może mieć wpływu na "jakość" dzwięku. Tak to jest zaprojektowane.

To są w uproszczeniu po prostu kopiowane dane przez usb, a czy tam jest zapisana muzyka czy cokolwiek innego to zawsze dostajemy po drugiej stronie to samo (są mechanizmy które o to dbają). Jeżeli jest to tryb który nie ma korekcji i przewodnik nie spełnia warunków to transmisja jest zerwana.

Dla mnie audiofilskie kable USB i Ethernet to jest apogeum nabijania w butelkę. Z drugiej strony, jeśli komuś takie kable poprawiają dźwięk/percepcje/samopoczucie/cokolwiek to świetnie. Biznes się kręci i jest git.

5 minut temu, m4tech napisał:

@morawka podziwiam Cię że chce ci się w ogóle dyskutować, ja już dawno odpuściłem dyskusję z tymi, którzy uważają granie z plików za kopiowanie piku z dysku C na dysk X.

Poniżej świeży test i porównanie kabli usb, Ci co porównują kopiowanie pdf do grania przez usb niech tego nie czytają, nie ma sensu :)

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

 

Nie zrozumiałeś i przekręcasz. Transport - to kopiowanie danych z punktu A do B (czyli np odczyt danych z CD i wysyłanie do DACa lub odczyt pliku z NAS i wysyłanie do DAC).

Jeśli jest inaczej to wyjaśnij nam jak to wg Ciebie działa.

Czemu dowodzi ten test na podanym forum? Wg mnie temu, że jest w tym wielka kasa i masa ludzi która jest gotowa wydać sporą mamonę na takie "nowinki". 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[fozzie]

10 minut temu, init0 napisał:

Przeczytałeś, to teraz zastanów się teraz jaki ma wpływ kabelek usb? (warunek to spełnienie parametrów elektrycznych zgodnie ze standardem). Tak się składa, że jeśli zrozumiałeś konstrukcję protokołu to powinno być jasne, że rodzaj przewodu nie może mieć wpływu na "jakość" dzwięku. Tak to jest zaprojektowane.

A czy ja w dyskusji z Tobą cokolwiek napisałem o wpływie kabelka usb na dźwięk? Człowieku, czytaj uważnie. Ja piszę o tym, że w USB audio nie powtarza się przesyłu danych, bo nie ma takiej możliwości. Nic nie wspominałem o kabelkach usb.

Poza tym co napisałem o brzmieniu, długo przed Tobą, w poście:

 

Na temat przesyłu danych strzeliłeś babola i tyle w temacie. Próbujesz teraz rozmydlić temat kabelkami, o których nie wspominałem.

[hoobi]

W dniu 24.02.2019 o 04:17, init0 napisał:

2. Plik pobieram tak jak robi to mój sprzęt po DLNA i na koniec w miejscu docelowym sprawdzam sumę.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Pliki identyczne. Koniec.

 

Czesc, sprzet audio na pewno tak nie robi. Nie kopiuje pliku do siebie, tylko odtwarza po sieci. Nie mozna sprowadzac transmisji audio do poziomu kopiowania plikow, bo wtedy oczywistym jestem, ze pliki zrodlowy i docelowy beda ok. Sadzilem, ze potrafisz faktycznie sprawdzic od strony DACa co dostanie z transportu. To jest faktycznie interesujace. Nie stoje po zadnej stronie barykady, interesuja mnie zarowno technikalia jak i psychologia :) Tylko mam prosbe - traktujmy siebie powaznie, wiem, ze to forum audio i wiekszosc nie zna sie na linuxie itp, ale z tym scp wyszlo niezrecznie...

Kto sie podejme nasluchu tego co dostaje DAC?

[szaman777]

Podjąłem się kiedyś nasłuchu z Tidala i nagrywania tego co wychodziło w czasie rzeczywistym. 1:1 z płytą CD.

[init0]

W dniu 26.02.2019 o 23:56, hoobi napisał:

Czesc, sprzet audio na pewno tak nie robi. Nie kopiuje pliku do siebie, tylko odtwarza po sieci. Nie mozna sprowadzac transmisji audio do poziomu kopiowania plikow, bo wtedy oczywistym jestem, ze pliki zrodlowy i docelowy beda ok. Sadzilem, ze potrafisz faktycznie sprawdzic od strony DACa co dostanie z transportu. To jest faktycznie interesujace. Nie stoje po zadnej stronie barykady, interesuja mnie zarowno technikalia jak i psychologia :) Tylko mam prosbe - traktujmy siebie powaznie, wiem, ze to forum audio i wiekszosc nie zna sie na linuxie itp, ale z tym scp wyszlo niezrecznie...

Kto sie podejme nasluchu tego co dostaje DAC?

 

Właśnie tak to działa! Plik jest kopiowany po sieci tcp/ip (w przypadku dlna), buforowany i dopiero odtwarzany. Tak samo się dzieje po spdif ale tylko w tych lepszych dacach. Miałem tak w Naim DAC i mam w 272, siedzi tam kość DSP shark która robi mi. dejitter.

W dlna pliki są wystawiane po http i pobierane ("transportowane") do daca. Tak widzę na moim dacu co dostaje, jest pełne info dotyczące rodzaju pliku, częstotliwości i wypełnieniu bufora (bardzo przydatne przy słuchaniu gęstych plików po wifi). 

Napisałeś "sprzet audio na pewno tak nie robi" jeśli dalej się nie zgadzasz to napisz nam jak to robi. Co to znaczy wg Ciebie "odtwarza po sieci"? Czy to jest coś innego niż kopiowanie danych?

Co niezręcznego jest w scp? Mam pokazać na przykładzie wget/curl żeby było po http tak jak to się dzieje po DLNA/uPnP?

W dniu 26.02.2019 o 23:27, fozzie napisał:

A czy ja w dyskusji z Tobą cokolwiek napisałem o wpływie kabelka usb na dźwięk? Człowieku, czytaj uważnie. Ja piszę o tym, że w USB audio nie powtarza się przesyłu danych, bo nie ma takiej możliwości. Nic nie wspominałem o kabelkach usb.

 

Na temat przesyłu danych strzeliłeś babola i tyle w temacie. Próbujesz teraz rozmydlić temat kabelkami, o których nie wspominałem.

 

Co za bzrudy opowiadasz. Pisałem już o transmisji przeczytaj wcześniej, USB ma CRC i inne mechanizmy ponawiania transmisji. Tak może ponawiać i to robi. W czym problem? To jest 480Mb/s więc podczas odtwarzania pliku jakości CD może go przesłać dziesiątki razy. To nie problem, jest taka możliwość. Skąd to bierzesz że się nie da?

Może odpowiedziałem przypadkiem do Ciebie o kablach zamiast do innej osoby, jest już duży młyn. 

[init0]

W dniu 26.02.2019 o 23:56, hoobi napisał:

Czesc, sprzet audio na pewno tak nie robi. Nie kopiuje pliku do siebie, tylko odtwarza po sieci. Nie mozna sprowadzac transmisji audio do poziomu kopiowania plikow, bo wtedy oczywistym jestem, ze pliki zrodlowy i docelowy beda ok. Sadzilem, ze potrafisz faktycznie sprawdzic od strony DACa co dostanie z transportu. To jest faktycznie interesujace. Nie stoje po zadnej stronie barykady, interesuja mnie zarowno technikalia jak i psychologia :) Tylko mam prosbe - traktujmy siebie powaznie, wiem, ze to forum audio i wiekszosc nie zna sie na linuxie itp, ale z tym scp wyszlo niezrecznie...

Kto sie podejme nasluchu tego co dostaje DAC?

C.D. 

Mogę Ci podesłać dumpa z tcpflow gdzie wyraznie widać jak to działa i jak plik jest pobierany po http. Chcesz, wiesz jak to czytać?

Jak chcesz się traktować poważnie to nie pisz bzdetów w stylu "na pewno tak nie robi". Mimo że nie wiesz jak to pieszesz nie bo nie. Bo nie ogarniasz jak może inaczej to piszesz "na pewno nie tak" ? Czy Ty jesteś poważny? ;)

Wymiękam jak czytam takie "nie bo nie".

[szaman777]

1 godzinę temu, init0 napisał:

Co za bzrudy opowiadasz. Pisałem już o transmisji przeczytaj wcześniej, USB ma CRC i inne mechanizmy ponawiania transmisji. Tak może ponawiać i to robi. W czym problem? To jest 480Mb/s więc podczas odtwarzania pliku jakości CD może go przesłać dziesiątki razy. To nie problem, jest taka możliwość.

Niestety tu się mylisz. Nie robi tak. Masz to opisane w linkach wyżej.

To właśnie dlatego powstają mity cudownych kabli usb do audio.

 

Oczywiście masz rację CRC jest i jest wykorzystywane np. w komunikacji z drukarką.

 

"Isochronous transfers are used to transfer data in real-time between host and device. When an isochronous endpoint is set up by the host, the host allocates a specific amount of bandwidth to the isochronous endpoint, and it regularly performs an IN- or OUT-transfer on that endpoint. For example, the host may OUT 1 KByte of data every 125 us to the device. Since a fixed and limited amount of bandwidth has been allocated, there is no time to resend data if anything goes wrong. The data has a CRC as normal, but if the receiving side detects an error there is no resend mechanism."

 

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ą )

[fozzie]

2 godziny temu, init0 napisał:

Co za bzrudy opowiadasz. Pisałem już o transmisji przeczytaj wcześniej, USB ma CRC i inne mechanizmy ponawiania transmisji. Tak może ponawiać i to robi. W czym problem? To jest 480Mb/s więc podczas odtwarzania pliku jakości CD może go przesłać dziesiątki razy. To nie problem, jest taka możliwość. Skąd to bierzesz że się nie da?

Nieprawda. W USB Audio nie ma ponawiania transmisji. Ale jak ktoś nie chce się dowiedzieć dlaczego to ja go do tego nie zmuszę. Wszystko jest w linkach, również w tym Twoim, który podałeś.

[hoobi]

5 godzin temu, init0 napisał:

C.D. 

Mogę Ci podesłać dumpa z tcpflow gdzie wyraznie widać jak to działa i jak plik jest pobierany po http. Chcesz, wiesz jak to czytać?

Jak chcesz się traktować poważnie to nie pisz bzdetów w stylu "na pewno tak nie robi". Mimo że nie wiesz jak to pieszesz nie bo nie. Bo nie ogarniasz jak może inaczej to piszesz "na pewno nie tak" ? Czy Ty jesteś poważny? ;)

Wymiękam jak czytam takie "nie bo nie".

init0, zbastuj nieco. Transmisja audio USB nie dziala jak SCP po sieci LAN - to jest konkretne narzedzie, konkretnego systemu operacyjnego (lub rodziny) a nie standardu Audio USB. Dlatego w przypadku Audio USB nie moze to tak dzialac. Ja protokolu Audio USB nie znam az tak dobrze, zeby sie specjalnie wychylac. Wiem natomiast, ze plik nie jest najpierw kopiowany do DAC - wystarcz podcza odtwarzania odlaczyc kabel, zeby zobaczyc, ze w przypadku transmisji asynchronicznej jest kilka sekund bufora.

Koledzy nizej pisza o braku powtorzen w takiej transmisji - nie wiem i bede sie wypowiadal, czy jest korekcja bledow. Jesli ktos madrzejszy, chetnie bym przeczytal ekstrakt ze specyfikacji protokolu - to by moglo raz na zawsze zamknac usta jednej lub drugiej stronie kablarzy :)

pozdrawiam, hubert

ps. tcpflow chetnie zobacze z transmisji USB.

[szaman777]

To nie zamknie niestety nikomu ust bo zwolennicy kabli usb robionych na udzie dziewicy tego po prostu nie zrozumieją. 

Korekcji błędów nie ma w takiej transmisji. Jest niepotrzebna w związku z tym, że w takim przesyłaniu brak jakiegokolwiek urządzenia mechanicznego, które mogłoby zawieść (rysy na CD, wibracje przesuwające laser itp.). Ewentualne błędy są słyszalne przez trzaski, zerwanie streamu itp. Nigdy nie jest to jakiś brak basu, czy zmiany w scenie itp. 

[init0]

8 godzin temu, szaman777 napisał:

Niestety tu się mylisz. Nie robi tak. Masz to opisane w linkach wyżej.

To właśnie dlatego powstają mity cudownych kabli usb do audio.

 

Oczywiście masz rację CRC jest i jest wykorzystywane np. w komunikacji z drukarką.

 

"Isochronous transfers are used to transfer data in real-time between host and device. When an isochronous endpoint is set up by the host, the host allocates a specific amount of bandwidth to the isochronous endpoint, and it regularly performs an IN- or OUT-transfer on that endpoint. For example, the host may OUT 1 KByte of data every 125 us to the device. Since a fixed and limited amount of bandwidth has been allocated, there is no time to resend data if anything goes wrong. The data has a CRC as normal, but if the receiving side detects an error there is no resend mechanism."

 

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

 

Dalej jesteś 10lat w plecy. Od dawna np taki tani rDac od Arcam nie działa jak drukarka. Sprawdź i poczytaj. Poza tym jak w trybie "ciągłym" masz błędy to przedywa transmisje i są trzaski, a nie zmiana jakości czy dociążenia basu i inne bzdety. Nie chce mi się już tego wałkować, producenci w większości piszą jak działą ich sprzęt. 

3 godziny temu, hoobi napisał:

init0, zbastuj nieco. Transmisja audio USB nie dziala jak SCP po sieci LAN - to jest konkretne narzedzie, konkretnego systemu operacyjnego (lub rodziny) a nie standardu Audio USB. Dlatego w przypadku Audio USB nie moze to tak dzialac. Ja protokolu Audio USB nie znam az tak dobrze, zeby sie specjalnie wychylac. Wiem natomiast, ze plik nie jest najpierw kopiowany do DAC - wystarcz podcza odtwarzania odlaczyc kabel, zeby zobaczyc, ze w przypadku transmisji asynchronicznej jest kilka sekund bufora.

Koledzy nizej pisza o braku powtorzen w takiej transmisji - nie wiem i bede sie wypowiadal, czy jest korekcja bledow. Jesli ktos madrzejszy, chetnie bym przeczytal ekstrakt ze specyfikacji protokolu - to by moglo raz na zawsze zamknac usta jednej lub drugiej stronie kablarzy :)

pozdrawiam, hubert

ps. tcpflow chetnie zobacze z transmisji USB.

Nie pisałem o USB! przeczytaj wątek. Nie doczytałeś i piszesz bzdety, mowa była o transportach i przesyłaniu po DLNA. Jak sama nazwa mówi tcpflow czyli TCP! Nie doczytasz i piszesz o bastowaniu. Streamer czyta plik z serwera dlna tak jak pisałem po http. Nie wiem dlaczego wtrąciłeś usb do tego tematu. Czytałeś w ogóle poprzednie posty? To już masakra jakaś lidzie, mieszacie tematy.

Co za pomysły, nie jest kopiowany cały bo po co. Są paczki danych i są buforowane jak mówisz kilka sekund i to wystarczy. Oczywiście że kablarze usb tego nie kumają.

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

[init0]

7 godzin temu, fozzie napisał:

Nieprawda. W USB Audio nie ma ponawiania transmisji. Ale jak ktoś nie chce się dowiedzieć dlaczego to ja go do tego nie zmuszę. Wszystko jest w linkach, również w tym Twoim, który podałeś.

 

Cytat z podanej dokumentacji:

"Czasami może się zdarzyć, ż e odbiornik potwierdzi bezbłędny odbiór danych, natomiast
nadajnik wskutek błędu w transmisji zareaguje tak jakby przekaz się nie powiódł i jeszcze
raz transmituje te same dane. Mechanizmem, który pozwala odbiornikowi zorientować się,
że jest to retransmisja a nie nowa porcja danych jest kontrola sekwencji pakietów danych.
Mechanizm ten bazuje na sprawdzaniu zgodności identyfikatorów PID (DATA0 i DATA1) ze
stanem jednobitowych przełą czników ustawianych oddzielne w nadajniku i odbiorniku."
 

[fozzie]

Godzinę temu, init0 napisał:

Dalej jesteś 10lat w plecy. Od dawna np taki tani rDac od Arcam nie działa jak drukarka. Sprawdź i poczytaj. Poza tym jak w trybie "ciągłym" masz błędy to przedywa transmisje i są trzaski, a nie zmiana jakości czy dociążenia basu i inne bzdety. Nie chce mi się już tego wałkować, producenci w większości piszą jak działą ich sprzęt. 

To może ja odpowiem na razie. Szaman777 nigdzie nie napisał, że błędy transmisji danych objawiają się zmianą jakości czy dociążeniem basu i innymi bzdetami. Właśnie my też mówimy (piszemy), że błędy w transmisji w trybie izochronicznym objawiają się trzaskami, chwilą ciszy itp. Wystarczy nasze wypowiedzi czytać.

Godzinę temu, init0 napisał:

Cytat z podanej dokumentacji:

"Czasami może się zdarzyć, ż e odbiornik potwierdzi bezbłędny odbiór danych, natomiast
nadajnik wskutek błędu w transmisji zareaguje tak jakby przekaz się nie powiódł i jeszcze
raz transmituje te same dane. Mechanizmem, który pozwala odbiornikowi zorientować się,
że jest to retransmisja a nie nowa porcja danych jest kontrola sekwencji pakietów danych.
Mechanizm ten bazuje na sprawdzaniu zgodności identyfikatorów PID (DATA0 i DATA1) ze
stanem jednobitowych przełą czników ustawianych oddzielne w nadajniku i odbiorniku."

Szkoda, że tak wybiórczo cytujesz tę dokumentację. Akapit wcześniej jest wyraźnie napisane, że:

"Zwykle w przypadku wykrycia błędu nadajnik ponawia przekaz. Podobnie w przypadku braku
gotowości nadajnik może pominąć ramkę, w której transmisja została zatrzymana i przesłać
przypisane jej dane w następnej ramce. Tej możliwości pozbawiona jest jedynie transmisja
danych prowadzona w trybie przekazu izochronicznego."

Źródło podane przez Ciebie:

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Teraz inne źródło, którego nie chcesz czytać:

"USB Audio

USB Audio uses isochronous, interrupt and control transfers. All audio data is transferred over isochronous transfers; interrupt transfers are used to relay information regarding the availability of audio clocks; control transfers are used used to set volume, request sample rates, etc."

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ą )

I jeszcze trzecie źródło:

"Transfer modes

Data is exchanged over USB using one of the four possible modes:

1.Control Transfers: command and status operations,

2.Interrupt Transfers: device requires the attention of the host

3.Bulk Transfers: large volumes of data like print jobs

4. Isochronous Transfers: time sensitive information, such as an audio or video stream

a)Guaranteed access to USB bandwidth.

b)Bounded latency.

c)Stream Pipe - Unidirectional

d) Error detection via CRC, but no retry or guarantee of delivery.

e) Full & high speed modes only

----------------

Isochronous transfer

When the computer sends the audio stream to an USB port, if first reads the data from the hard disk and caches blocks of the data in memory.

It is then spooled from memory to the output port in a continuous stream (Isochronous mode).

Frames are sent out every millisecond. 
This happens whether there is any data in the frame or not. 
The rate at which the frames go out is determined by a oscillator driving the USB bus.
This rate is independent of everything else going on in the PC.
In principle this guarantees a constant flow of the frames.
In practice the frames might not be filled properly with data because some program simply hogs the CPU or the PCI.
Anti virus polling the internet at high priority are a well known example.

Isochronous transfer can be done with three possible types of synchronization modes in the USB audio device.

Synchronous, adaptive and asynchronous synchronization"

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

 

1 godzinę temu, init0 napisał:

To już masakra jakaś lidzie, mieszacie tematy.

Nie, to Ty mieszasz.

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ą )

[init0]

7 godzin temu, fozzie napisał:

To może ja odpowiem na razie. Szaman777 nigdzie nie napisał, że błędy transmisji danych objawiają się zmianą jakości czy dociążeniem basu i innymi bzdetami. Właśnie my też mówimy (piszemy), że błędy w transmisji w trybie izochronicznym objawiają się trzaskami, chwilą ciszy itp. Wystarczy nasze wypowiedzi czytać.

Szkoda, że tak wybiórczo cytujesz tę dokumentację. Akapit wcześniej jest wyraźnie napisane, że:

"Zwykle w przypadku wykrycia błędu nadajnik ponawia przekaz. Podobnie w przypadku braku
gotowości nadajnik może pominąć ramkę, w której transmisja została zatrzymana i przesłać
przypisane jej dane w następnej ramce. Tej możliwości pozbawiona jest jedynie transmisja
danych prowadzona w trybie przekazu izochronicznego."

Źródło podane przez Ciebie:

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

Teraz inne źródło, którego nie chcesz czytać:

"USB Audio

USB Audio uses isochronous, interrupt and control transfers. All audio data is transferred over isochronous transfers; interrupt transfers are used to relay information regarding the availability of audio clocks; control transfers are used used to set volume, request sample rates, etc."

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ą )

I jeszcze trzecie źródło:

"Transfer modes

Data is exchanged over USB using one of the four possible modes:

1.Control Transfers: command and status operations,

2.Interrupt Transfers: device requires the attention of the host

3.Bulk Transfers: large volumes of data like print jobs

4. Isochronous Transfers: time sensitive information, such as an audio or video stream

a)Guaranteed access to USB bandwidth.

b)Bounded latency.

c)Stream Pipe - Unidirectional

d) Error detection via CRC, but no retry or guarantee of delivery.

e) Full & high speed modes only

----------------

Isochronous transfer

When the computer sends the audio stream to an USB port, if first reads the data from the hard disk and caches blocks of the data in memory.

It is then spooled from memory to the output port in a continuous stream (Isochronous mode).

Frames are sent out every millisecond. 
This happens whether there is any data in the frame or not. 
The rate at which the frames go out is determined by a oscillator driving the USB bus.
This rate is independent of everything else going on in the PC.
In principle this guarantees a constant flow of the frames.
In practice the frames might not be filled properly with data because some program simply hogs the CPU or the PCI.
Anti virus polling the internet at high priority are a well known example.

Isochronous transfer can be done with three possible types of synchronization modes in the USB audio device.

Synchronous, adaptive and asynchronous synchronization"

Ukryta Zawartość

Zaloguj się, aby zobaczyć treść.

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

 

Nie, to Ty mieszasz.

Czekjaj czekaj, to ponawia czy nie? Pisałeś że nie ma takiej możliwości, a jednak jest i może to robić. To że są różne metody/implementacje w różnych dacach to jest jasne. Jak mam zacytować? Zacytowałem że jest taka możliwość w USB i tyle. Twierdziłeś uparcie, że nie ma.

Co Ty w ogóle chcesz mi udowadniać? Dla mnie jest jasne, że podczas błędów w transmisji są trzaski lub zerwanie dzwięku. Nie ma w tym żadnej zmiany barwy lub "głębokiego/płytkiego basu i podobnych. Koniec. Ile można to wałkować? 

O mieszaniu pisałem do hoobi, to on pomieszał TCP z USB i pisze jakieś brednie. scp był przykładem, można użyć dowolnej metody kopiowania. Co w tym ciężkiego do zrozumienia? Ludzie czytajcie swoje wpisy i odpowiedzi dotyczące swojego wpisu i na to odpisujcie.

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ą )

[fozzie]

15 minut temu, init0 napisał:

Czekjaj czekaj, to ponawia czy nie? Pisałeś że nie ma takiej możliwości, a jednak jest i może to robić. To że są różne metody/implementacje w różnych dacach to jest jasne. Jak mam zacytować? Zacytowałem że jest taka możliwość w USB i tyle. Twierdziłeś uparcie, że nie ma.

Człowieku! Skup się! Potrafisz czytać ze zrozumieniem?

W USB Audio nie ma możliwości powtarzania uszkodzonych danych!

[szaman777]

 

13 godzin temu, init0 napisał:

Dalej jesteś 10lat w plecy. Od dawna np taki tani rDac od Arcam nie działa jak drukarka. Sprawdź i poczytaj. Poza tym jak w trybie "ciągłym" masz błędy to przedywa transmisje i są trzaski, a nie zmiana jakości czy dociążenia basu i inne bzdety. Nie chce mi się już tego wałkować, producenci w większości piszą jak działą ich sprzęt. 

Kolego, nie imputuj mi słów, których nie napisałem i nigdy bym nie napisał.

Poruszamy się w dziedzinach ścisłych i nie ma tu miejsca na przekręcanie słów i wypowiedzi.

 

Ludzie są wystarczająco zmanipulowani cudownymi kablami USB, a Ty mimo niewątpliwej wiedzy odsłonić prawdy nie pomagasz, poprzez mieszanie różnych rzeczy i przekręcanie wypowiedzi innych.

 

Przeczytaj jeszcze raz cytat ze źródła, które podałem wcześniej (xmos), cytat, który z tego samego źródła podał @fozzie, jego inne źródła, a najlepiej cały dokument od xmos. Tam wyraźnie jest napisane kiedy CRC pracuje i jest możliwa powtórna transmisja, a kiedy nie. W przypadku danych audio przez usb nie ma resendu, jeżeli mówimy o transmisji w czasie rzeczywistym.

[antymalkontent]

I co w końcu wyszło malina PC czy coś innego lepsze porownywal ktoś (jeśli tak to z czym) i jak wypadły? Bo jakieś dziwne teorie opisujecie a w temacie widzę że nikt nie siedzi.