Új hozzászólás Aktív témák

• #47 emvy félisten schawo #46

  Új Válasz 2011-09-23 14:38:31 #47

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  emvy

  félisten

  válasz schawo #46 üzenetére

  Hm, de az aszinkron USB audio mellett ez mar nem olyan kritikus, azaz felesleges egy USB->SPDIF atalakitoval megbonyolitani a dolgot.

• #41 emvy félisten szab.tam #40

  Új Válasz 2011-09-23 13:11:47 #41

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  emvy

  félisten

  válasz szab.tam #40 üzenetére

  Gondolom egy csomoan igy is ertik, leforditani nincs idom/kedvem, szerintem aki izokron USB audiorol akar olvasni, az tanuljon meg angolul.

• #36 emvy félisten FefeeX #35

  Új Válasz 2011-09-23 12:56:20 #36

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  emvy

  félisten

  válasz FefeeX #35 üzenetére

  Sajnos ez nem igy mukodik.

• #34 emvy félisten dabadab #33

  Új Válasz 2011-09-23 12:53:24 #34

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  emvy

  félisten

  válasz dabadab #33 üzenetére

  Mindenki igy csinalta az elejen (2005-os cikk, azota valtozott, de tenyleg csak azt allitom, hogy az USB audio alapvetoen nem volt perfekt kb. 2009-ig).

  One interesting tidbit about isochronous streams is that there is no error correction. There is a rudimentary error detection, but no mechanism for doing anything about it, no retries or ECC codes. I read somewhere that its estimated that for a 44.1 stream running 24 hours a day there will be an error about once a month or so. The standards committee did not consider this worth doing anything about. I guess if you detect an error you can either flash a light on the front pannel to let people know an error occured, or you can just play the previous sample. (or maybe interpolate with the next)

  Now on to the fun part, the syncronization modes. In all casses the data from the bus goes into a buffer and gets clocked out by a clock, how that clock is generated and how it interacts with the bus is the differences between the modes.

  Synchronous: in this mode the readout clock is directly derrived from the 1KHz frame rate. There is a PLL that takes in the start of frame signal and genrates a clock. Using this scheme its rather difficult to generate 44.1, but very easy to generate 48KHz. This is a primary reason why many early USB audio devices only supports 48KHz, they used this mode. As you can guess this mode is very susceptible to jitter on the bus, pretty much anything that causes the output from the host to be jittered (PS noise, vibrations, interference etc) AND things that can cause jitter on the interconnect (interference, reflections, ground noise etc) will wind up with jitter on the readout clock. This is a VERY poor mode to use for decent quality audio.

  Adaptive: in this mode the clock comes from a separate clock generator (usually implemented as a PLL referenced by a crystal oscillator) that can have its frequency adjusted in small increments over a wide range. A control circuit (either hardware or firmware running on an embedded processor) measures the average rate of the DATA coming over the bus and adjusts the clock to match that. Since the clock is not directly derived from a bus signal it is far less sensitive to bus jitter than synchronous mode, but what is going on on the bus still can effect it. Its still generated by a PLL that takes its control from the circuits that see the jitter on the bus. Its a lot better than synchronous mode, but still not perfect by a long shot. This is the mode that MOST USB audio devices use today.

  Asynchronous: in this mode an external clock is used to clock the data out of the buffer and a feedback stream is setup to tell the host how fast to send the data. A control circuit monitors the status of the buffer and tells the host to speed up if the buffer is getting too empty or slow daown if its getting too full. Note this is still isochronous, the host is continuousley sending samples, there is no "per packet handshake" going on. Since the readout clock is not dependant on anything going on with the bus, it can be fed directly from a low jitter oscillator, no PLL need apply. This mode can be made to be VERY insensitive to bus jitter.

  The reality: There are NO USB audio chips that out of the box support asynchronous mode! If any one here is aware of any please let me know. I have researched the field quite thoroughly and not found any. There are a few that theoretically do support it, but their firmware has to be rewritten to support asynchronous transfer. I have been trying to do this for one of these chips for the last several months and have been running into a lot of roadblocks. Sometime in the future I hope to get it working, but for now I have to live with chips that support adaptive mode.

  [link]

• #31 emvy félisten

  Új Válasz 2011-09-23 12:29:16 #31

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  emvy

  félisten

  A szinkron USB-s DACok tenyleg lehetnek problemasak, de mar vannak aszinkronok is, ami viszont (altalaban) jobbak (adott arban), mint az SPDIF.

Új hozzászólás Aktív témák