Stationær vs Bærbar til USB Audio

[harmonic]

Hva med en  top notch nas server det mÃ¥ vel være det ultimative.

El er jeg helt galt på den ?

( følger med i denne trÃ¥d med store øjne i og med jeg benytter en imac/xtern hardisk sb3  lydkilde)

mvh

[lydkaj]

Så har jeg fået eksperimenteret lidt mere. Det virker ikke som det gør nogen egentlig forskel om en ekstern USB eller intern disk anvendes.

Jeg prøvede også at bruge en lille USB hub med ekstern strømforsyning, det ændrer heller ikke rigtigt på noget. Den stationære (MD8828) er stadig den der spiller bedst.

Alle power saving features er disabled, dog gør det egentlig heller ikke den store forskel. PC'erne lyder ret ens om power saving er i "ballanced" eller helt slået fra.

Hilsner,
Karsten

 

Det lyder som om det er alvorligt ,jeg har oplevet noget ligende med en Transporter, den blev først kørt som DAC signalet fik den fra et CD drev, det lød  rimeligt fornuftigt, der efter blev skiftet til en bærbar som kilde , det var simpelt sÃ¥ dÃ¥rligt at jeg faktisk nægtede at tro det var sandt, men det var det vist.

Men hvad er der galt? i store træk er det jo kun strømforsyningen der er afgørende forskel pÃ¥, plus at den  bærbare er lidt svagere.

[Karsten@StudioSound]

Hej Karsten

Har du prøvet med andre stationære pcér evt en gammel model ?
MVH Kampko

En gammel stationær diskvalificerer typisk sig selv med blæserstøj, så det er ikke så interessant. Desuden har jeg mest held med Vista.

Det er desværre lidt omfattende at komme til bunds i dette emne, så det mest rigtige er måske at bygge en PC fra bunden for at se hvad der gør hvad.

Hilsner,

Karsten

[Karsten@StudioSound]

Det lyder som om det er alvorligt ,jeg har oplevet noget ligende med en Transporter, den blev først kørt som DAC signalet fik den fra et CD drev, det lød  rimeligt fornuftigt, der efter blev skiftet til en bærbar som kilde , det var simpelt sÃ¥ dÃ¥rligt at jeg faktisk nægtede at tro det var sandt, men det var det vist.

Men hvad er der galt? i store træk er det jo kun strømforsyningen der er afgørende forskel pÃ¥, plus at den  bærbare er lidt svagere.

Det kunne vel være jitter relateret. MÃ¥ske ogsÃ¥ derfor jeg har haft mest held med konvertere der ikke er voldsomt jitterfølsomme.

Hilsner,

Karsten

[Karsten@StudioSound]

Hva med en top notch nas server det må vel være det ultimative.

El er jeg helt galt på den ?

( følger med i denne tråd med store øjne i og med jeg benytter en imac/xtern hardisk sb3 lydkilde)

mvh

Det virker ikke som det gør den store forskel om data hentes internt eller eksternt, mere hvordan de proceseres.

Hilsner,

Karsten

[Patriarken]

Hejsa

Du snakker om balanced powersettings og high performance, men det betyder ikke at strømstyring osv er slået fra eller er holdt til et minimum.

har du været herinde og indstille her?





Btw Hvilke chipsset er der tale om på hhv bærbar og stationær?

Er det intel (945, g965express, "nvidia nforce hyper maniac SLI" osv)

og har du enablet onboard USB 2.0 controller på hhv bærbar/stationær?


Selv ville jeg aldrig vælge en USB baseret lydkortløsning da USB  standarden ikke har bÃ¥ndbreddereservation og ikke virker tilstrækkelig stabil ift mine erfaringer. Skulle jeg vælge et eksternt lydkort ville jeg gÃ¥ efter en Firewireløsning da denne standard overkommer USB(2.0)'s begrænsninger.

mvh Anders

[lydkaj]

 

Det kunne vel være jitter relateret. MÃ¥ske ogsÃ¥ derfor jeg har haft mest held med konvertere der ikke er voldsomt jitterfølsomme.

Hilsner,

Karsten

[/quote]

 

Det er et godt bud, der var en ret lang ledning ved det jeg oplevede, Jeg ved ikke om USB er en strøm overførsel, SPDIF er normalt ikke, det kunne man etablere med kredsen AD844 i begge ender, men det er jo desværrer ikke sÃ¥ lige til, fakta er at strømoverføring er spæningsoverføring totalt overlegen. sÃ¥ jeg vil da prøve det ved lejlighed.

[Karsten@StudioSound]

Hej Anders,

Jo jeg har været igennem hele power setting afsnittet.

Hvor er den USB 2.0 enable/disable funktion, BIOS? Udfra de overførselshastigheder jeg får, vil jeg dog skønne at der køres USB 2.0

Jeg kikkede lige hurtigt i enhedshåndtering på den bærbare, der er noget med båndbreddebegrænsning der lige skal prøves/sammenlignes.

Vender lige tilbage med yderligere info når tiden tillader...

Hilsner,
Karsten

[Patriarken]

Hejsa

 

Det er et godt bud, der var en ret lang ledning ved det jeg oplevede, Jeg ved ikke om USB er en strøm overførsel, SPDIF er normalt ikke, det kunne man etablere med kredsen AD844 i begge ender, men det er jo desværrer ikke sÃ¥ lige til, fakta er at strømoverføring er spæningsoverføring totalt overlegen. sÃ¥ jeg vil da prøve det ved lejlighed.

Usb trækker 5volt på en leder, ground på en anden, derudover er der to ledere til data. (Datalederene er parsnoet.)

mvh Anders

[JJAZ]

Det kunne vel være jitter relateret. MÃ¥ske ogsÃ¥ derfor jeg har haft mest held med konvertere der ikke er voldsomt jitterfølsomme.

Hilsner,
Karsten

Jitter og USB i samme sætning??? USB er pakkebaseret transmission så det giver ikke rigtig mening at snakke jitter her hvis du spørger mig.

 

Clocken i dit USB-lydkort er det som generer din sp-dif og medmindre USB overførslen er totalt fucked up (eller lydkortet har for dårligt styr på transmissionen) så bliver jitteren genereret i lydkortets clock og ikke i USB-overførslen.

 

Som Patriarken så rigtigt skriver er USB egentlig uegnet til overførsel af lyd, hvorimod Firewire virker. Nærmest samtlige prof. lydkort kører iøvrigt Firewire.

[xo]

Hvis maskinen er presset kan det nok også give en problemer, men nok mest med udfald. Windows Device Driver Model (WDDM) 1.0 (Vista) er heller ikke helt "færdigbagt". Der er allerede planlagt en WDDM 2.0 (post-Vista) der skulle gøre Vista mere modstandsdygtigt mod udfald (i video og lyd) grundet en ny model for forudtømmende kontekstskift. Men det må tiden vise...

USB 3 er optisk, så er det slut med PC'en som strømkilde ad den vej. Men Trends UD-10 har da også sit eget separate strømindtag.

[Karsten@StudioSound]

Jitter og USB i samme sætning??? USB er pakkebaseret transmission så det giver ikke rigtig mening at snakke jitter her hvis du spørger mig.

 

Clocken i dit USB-lydkort er det som generer din sp-dif og medmindre USB overførslen er totalt fucked up (eller lydkortet har for dårligt styr på transmissionen) så bliver jitteren genereret i lydkortets clock og ikke i USB-overførslen.

 

Som Patriarken så rigtigt skriver er USB egentlig uegnet til overførsel af lyd, hvorimod Firewire virker. Nærmest samtlige prof. lydkort kører iøvrigt Firewire.

Jeg fandt lige denne interessante beskrivelse på Computer Audio Asylum:

"The USB audio class implementation uses the isochronous mode of data transfer over the USB bus, with three possible types of synchronization:

synchronous, adaptive and asynchronous. I will go over these in detail a little further down, covering how they work and their jitter rammifications.

But first some detail on isochronous mode and covering some myths about USB. The USB bus works very differently than an ethernet connection works and this has given rise to some erroneous assumptions I hear a lot of around here. First off the host (computer) is in complete control of the bus, there is no way too many devices trying to talk at once can "overload" the bus such as can happen on an ethernet. Data is sent out in frames that go out every millisecond. This happens whether there is any data in them or not. The rate at which the frames go out is determined by the oscillator in the host transmitter, not by the speed at which the computer is running, or the software running on it. Some piece of software bussily running in the background cannot "slow down" the bus. It might prevent a program from keeping up with the bus (providing data to it) or accepting data from it, but the data rate on the bus stays constant (or at least fairly constant within the limits of the oscillator in the host PHY)

Now on to isochronous, this means that the host reserves bandwidth on the bus for an endpoint. (your DAC is an endpoint) This is easy for it to do since it is in complete control of the bus, nobody else can "steal" it. It doesn't matter that you have a 300gig hard drive, a scanner, a mouse or whatever else on the bus, once an isochronous endpoint is setup they all have to work around it, they get whats left over. If you try and setup too many isochronous endpoints such that the bus cannot handle it, the host will not allow them all.

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.

These adaptive chips are not bad, they actually have quite good jitter performance, much better than I thought they would have when I started working with them. But its not perfect, or really even close. Because of this the DAC is still sensitive to whats going on with the cable and the host, not a lot, but it is definately there.

As the quality of the power supply, DAC board layout and output stage have increased the level of grundge and noise from these sources on the output signal have decreased to the point where the jitter effects are a larger percentage of problems with the sound. You probably will have a hard time hearing these effects on a stock transit for example, there is too much else going on that is masking these effects. But once this other stuff is diminsihed significantly the effects of the interface jitter are much more noticeable.

Of course there is another way to deal with this, throw out the USB audio spec and write your own using the bulk protocol. Of course this means you have to write your own windows, MAC and linux drivers, AND your own firmware for a generic USB interface chip. It CAN be made to work and if done right could provide a very low jitter interface, but it is one heck of a lot of work, one I don't have the time for (unless someone here is willing to support me and my familly so I can spend full time on this)

I guess thats enough of my soapbox for now, I'll get off and return you to your regularly scheduled assylum.

John S. "

[Onsdagssneglen]

Jeg fandt lige denne interessante beskrivelse på Computer Audio Asylum

Plejer det ikke at være god forum-kotume, at komme med en linkhenvisning, når man citerer fra andet end det, der kan læses i tråden?

[xo]

Plejer det ikke at være god forum-kotume, at komme med en linkhenvisning, når man citerer fra andet end det, der kan læses i tråden?

 

Den klarer google.

[JJAZ]

Jeg fandt lige denne interessante beskrivelse på Computer Audio Asylum:

Super interessant læsning.. og det forklarer jo ret godt hvorfor USB indtil videre er temmelig uegnet til lyd i high-end kvalitet.

Det kan også meget vel forklare hvorfor du oplever stor forskel på forskellige computere hvis deres 1mS pakke-frekvens får lov at bestemme noget som helst. Samtidig vil det også betyde at selvom én stationær lyder godt så er det ikke sikkert at en anden stationær (selvom den ligner en tro kopi af den første) vil lyde lige så godt. Det er ikke lige til den slags transmission at man bruger krystaller med mindst mulig jitter.