Analog skrev: Larry Osterman skrev: One other thing to consider - most current audio CDs are rendered so hot that their signals are clipped on the CD - so losing some fidelity isn't going to make a difference to that content. Måske ikke lige den rette indstilling.....

Det er blot en konstatering, han siger jo ikke at der sker noget tab.

xo skrev: Analog skrev: Larry Osterman skrev: One other thing to consider - most current audio CDs are rendered so hot that their signals are clipped on the CD - so losing some fidelity isn't going to make a difference to that content. Måske ikke lige den rette indstilling..... Det er blot en konstatering, han siger jo ikke at der sker noget tab.

Nej, det er et smaddergodt indlæg. Endelig noget konkret funderet. Man kan så diskutere om et sample rate konverteret signal, der får tilføjet dither i den proces for at mindske kvantiseringsstøj, er lige så godt som et, der ikke er blevet behandlet.... Næppe. Selvom der ikke er forsvundet et helt bit. Men nu er det da til at forholde sig til på et konkret grundlag. Det gør det værd at følge med i tråden. Det kan jeg kun sige positivt om.

Jeg blev bare lidt provokeret af bemærkningen om, at når mange CD'er er elendige, kunne det være lige meget. Hvis det er indstillingen, skal jeg ikke ha' noget af min lyd den vej igennem, tak - med eller uden dither!

Men tak for det fine indlæg.

Mere korrespondence nedenfor.

Larry Osterman skrev: Nobody on the audio team (myself included) is willing to guarantee end-to-end, bit-for-bit transparency even for the KS path.  What we WILL guarantee is that if you're using directKS, ASIO, or WASAPI in exclusive mode no audio processing is done by Windows - the bits are handed to the driver without modification. What happens after the bits are sent down to the driver is up to the driver.  Having said that, if the driver is an hdaudio device (and thus supports waveRT), then if you're rendering via WASAPI exclusive mode, the app's audio samples are copied directly into the driver's DMA buffer, so they are effectively handed directly to the render hardware with no audio device driver intervention.  I can't speak to ASIO or directKS, since I don't know how they work.

Dermed er det sat på plads at det er muligt, også i Windows Vista, med de rette indstillinger og drivere, at få bit-perfekt levering af audio data til hardware enheden.

napsi skrev: Ghammel & Suhr skrev: Fil systemer benytter naturligvis også CRC så man kan være sikker på at data læses korrekt og ens programmer kan køre korrekt. Igen, hvis du kan læse det her, så har jeg ret :D Ja, men hvad så med audio data - dem forholder du dig ikke til... Audio-data er en delmængde af data. Så enkelt kan det siges. Audio-data er den venlige delmængde, mens program-data er meget utilgivende overfor fejl, men begge behandles med samme kærlige omtanke fra filsystemets side. :)

Hey Napsi,

Et både etisk og poetisk smukt og rent forsøg på udtryk

Selvom data umiddelbart behandles ens af filsystemet, kan der sagtens være et progressivt - ja, endda regressivt - slutresultat af databehandlingen

Prøv nu for dæwleren af få de dersens fysikere til at fortælle dig lidt om, hvordan en +/- bit ser ud på et højopløsnings-scope.

Og om forholdene omkring opfyldelsen af en "absolut" bit.

Og måske nok så navnlig hvorfor begrebet "en absolut bit" er ikke-eksisterende

Du har på din uddannelsesinstitution alle muligheder for at grave helt ned i dybden, så hvad holder dig tilbage...?





__________________
Denny Crane tilbage på TV, dammit!

Strøm FAQ - lavet af forummet

Stop klynkeriet - kvinden tilbage i kvindekroppen!

xo skrev: Digitalitet er netop dét at man ikke behøver bekymre sig om mindre analoge forskelle, ubeagtet at platformen er analog; om den er det i det uendelige er der vist delte meninger om. Så hvorfor skal vi blande fysikerne ind i en debat om digital signaltransport? Bare det dog var så enkelt. Men det er det jo ikke. "Digitalt=analogt med" synes at være den gængse opfattelse. Wrong. Hvis man går tæt nok på, så består selv bits af små, bitte sinus-kurver. Og såfemt den enkelte sinuskurve afviger fra sin ideelle sinus, så taler vi om forvrængning i forhold til det oprindelige signal. Udfra hvad du tidligere har skrevet, Ghammel & Suhr, har jeg på fornemmelsen at du fokuserer på jitter, snarere end bitfejl, da det vist er lidt svært at dokumentere at bitfejl skulle være særligt forekommende for audio data. TCP/IP er komplet agnostisk overfor den ene eller den anden type data, det samme er din harddisk. Det der derimod måske kan være tale om, er måske at der kan forekomme mere jitter med TCP/IP end med andre protokoller, hvis det vel og mærke implementeres hovedløst. Igen teori fra den ideelle verden Jeg foretræker imidlertid at beholde hovedet på kroppen (så regner det heller ikke ind ;-) og beskrive emnet udfra velkendte problematikker. Selv TCP/IP har en fejlmargin. I den virkelige verden er INTET perfekt - selv en bit kan f.eks. være i modfase Men vi skal vel ikke til at se på harddisken og små analoge fænomener i denne, når blot denne overfører data korrekt til en buffer. Jowda, hvorfor ikk'?  Det er ikke spor utænkeligt, da digital teknik i yderste konsekvens reelt er analog teknik, da det stadig er strøm, vi taler om. Altså lissom "back-to-basics" Som med protokoller er digitalitet også en abstraktion. Please...

__________________
Denny Crane tilbage på TV, dammit!

Strøm FAQ - lavet af forummet

Stop klynkeriet - kvinden tilbage i kvindekroppen!

ArneBjarne skrev: Ghammel & Suhr skrev: xo skrev: Digitalitet er netop dét at man ikke behøver bekymre sig om mindre analoge forskelle, ubeagtet at platformen er analog; om den er det i det uendelige er der vist delte meninger om. Så hvorfor skal vi blande fysikerne ind i en debat om digital signaltransport? Udfra hvad du tidligere har skrevet, Ghammel & Suhr, har jeg på fornemmelsen at du fokuserer på jitter, snarere end bitfejl, da det vist er lidt svært at dokumentere at bitfejl skulle være særligt forekommende for audio data. TCP/IP er komplet agnostisk overfor den ene eller den anden type data, det samme er din harddisk. Det der derimod måske kan være tale om, er måske at der kan forekomme mere jitter med TCP/IP end med andre protokoller, hvis det vel og mærke implementeres hovedløst. Men vi skal vel ikke til at se på harddisken og små analoge fænomener i denne, når blot denne overfører data korrekt til en buffer. Som med protokoller er digitalitet også en abstraktion. Nemmerli', hr. xo - gode pointer!  Nogle bør blot passe en smule på, at "digitalitet" ikke går hen og bliver "analogt med"  Fejl er ikke nødvendigvis deciderede bit-fejl. Man kan også betragte alt, hvad der ikke oprindeligt er på kildematerialet som fejl. Og det er netop, hvad jeg gør. Ser vi dernæst på deciderede fejlaflæsninger (sker langt oftere, end de fleste forestiller sig), så vil der ved korrektionen (som erstatning for det oprindelige signal) være tale om en interpolation. Altså ikke en eksakt, men i stedet en tilnærmet værdi. Er fejlene i lyden (jitter) først introduceret ved aflæsningen (og oftest forøget undervejs), så er de der, uanset hvad, og uanset hvad der måtte være af senere fejlretning. Jitter i forbindelse med TCP/IP som transport protokol har jeg ikke hørt om, kun regulær datakorruption (det er jo også slemt nok ;-), så fortæl gerne noget mere om det. Det er nok ikke urealistisk, da jitter jo bliver mere eller mindre jævnt induceret i hele transportforløbet. De fleste CD-ROM/DVD drev synes jeg i øvrigt er af så tilpas kummerlig kvalitet, at man bør se sig forholdsvis godt for, hvis man skal buge det til musik. For den del år siden legede jeg med nogle maskiner til en kunde, og fik så den ide at sætte nogle specielle (hundedyre) teflon SCSI kabler på både CD drev og Harddisk. Selv om prisen på teflon-kablerne var mere end 10 gange så høj, så var den lydmæssige forbedring hver en øre værd. Forbedringen var klart bedre opløsning, flere detaljer, bedre rumgengivelse og i det hele taget renere lyd. ALtså typisk de samme ting der sker, når niveauet af jitter nedsættes. Generel dataoverførsel gik i øvrigt mellem 10 og 20 pct. op, afhængig af applikationen. Desværre har jeg ikke set disse teflon kabler her i DK (markedet er vel for lille), så hermed en opfordring til en evt. medlæsende importør - og også gerne til ATA, tak  Så overførselshastigheder set under et har jeg lige siden haft en mistanke om bliver reduceret, hvis der opstår jitter undervejs. Og tiden har kun vist det samme. Hvis man har et ATA RAID system derhjemme med 4 diske, hvor alle drev er sat op som Master, kan man jo prøve at klippe den løsthængende sekundære kanal af kablet (tag først strømmen fra). Dette skulle også gerne give et mærkbart performance boost, omend det er i den mindre afdeling. Mens det selvfølgelig er rigtigt, at der pricipielt ikke ændres på data undervejs, vil jitter-induceret data stadig fremstå som korrekte data hos diverse kontrol- og fejlretningsfunktioner. Og skulle der være enkelte fejl, vil de selvfølgelig også blive rettet. Men påvirkningen fra jitter - altså den skade jitter gør på lyden - vil imidlertid forblive intakt. Hvis nogen kan fylde mere på her (f.eks. xo, napsi), så gør det gerne  @Bumle: At jitter først skulle opstå ved up/oversampling er noget forchromet vås, sorry. Det opstår allerede ved aflæsningen af (lyd)data, stort set uanset mediet. Lyddata er netop mere følsomme pga. den uundgåelige tilførsel af jitter fra CD-drev, kabler, ATA ift. SCSI, RAM, ja, sågar visse bundkort tilfører i sig selv så meget jitter og/eller inteferens, at det nærmest er til at hulke over. Dernæst kommer vibrationerne fra såvel CD-drev som harddisk, og en ofte støjende SMPS hjælper heller ikke på problemet. Så imens data i den perfekte verden blot er data, så ser virkeligheden imidlertid en smule anderledes ud - og det er lissom det, vi gerne skulle beskæftige os med her  Nåhjah, så bruger "Accurate"Rip ganske som "E"AC en form for "gennemsnitsdatabase", hvorfor resultatet alt andet lige kun kan være netop et gennemsnit. Jeg forstår ikke helt, at folk falder for den slags marketingsbawl, men det er nok bare mig  Få i stedet fat på Adaptec's Easy CD Creator v. 3.1, eller en af de tidlige versioner af WinOnCD. De lyder begge kanon hamrende godt i forhold til alt det andet nyt=godt, der er på markedet i dag, puh-bad  Lad os nu for en gangs skyld slå fast at når en bit er indlæst i en buffer så kan den ikke have nogen jitter.. der ikke noget der hedder en 1'er bit med lidt jitter. Når den er i bufferen har den ikke nogen tidsmæssig udstrækning og kan så selvsagt ikke have nogen jitter da det relaterer sig til timing. Hvis der var jitter på signalet der blev indlæst i bufferen så kan der ske 2 ting: 1. jitteren var stor nok til 1 bit blev samplet 2 gange. Denne fejl vil i bufferen være umulig at skelne fra en bit-fejl i den bit som ikke blev samplet. Du har altså et bitmønster i din buffer UDEN jitter, men med bitfejl. 2. jitteren var ikke stor nok til at forstyre samplingen, der er ingen fejl. Du har altså et bitmønster i din buffer UDEN jitter og uden bitfejl. På det næste led i kæden (fra en buffer til en anden buffer) er der således ikke andet jitter end det der er på selve det led. Jitter akkumuleres altså ikke igennem ledene. Så skal man altså blot gå efter i hvert enkelt led ikke at køre med højere bushastighed end at den jitter der kan opstå ikke er for stor i forhold til en enkelt fase.

Fint nok.

Du glemmer blot, at jitter ikke kun er bestemt af tid. Det er også bestemt af domæne.

Altså har du udeladt en enkelt (men afgørende) faktor i den ovenstående ligning.

Sinus, ArneBjarne, Goddamn sinus! 

__________________
Denny Crane tilbage på TV, dammit!

Strøm FAQ - lavet af forummet

Stop klynkeriet - kvinden tilbage i kvindekroppen!

xo skrev: Den her debat om hvorvidt KS og ASIO fungerer fejlfrit i Windows Vista motiverede mig til at skrive til Larry Osterman, Microsoft udvikler på audio teamet for Windows Vista. Her er hans svar på hvorvidt audio data croppes til 15 bit nogle steder i stakken og hvorvidt KS eller ASIO er deaktiveret i Windows Vista. Larry Osterman & Elliot Omiya skrev: Yup, that makes sense, thanks for the clarification. -=<EHO>=- -----Original Message----- From: Larry Osterman Sent: Tuesday, January 02, 2007 11:09 AM To: Elliot H Omiya (EHO); 'XO' Subject: RE: (Larry Osterman's WebLog) : Windows Audio You're right (of course) about the float32 - I was confused because float32 can perform lossless functions with 24bits of accuracy (so I always think of there only being 24bits of "resolution" in the float32 value). -----Original Message----- From: Elliot H Omiya (EHO) Sent: Tuesday, January 02, 2007 11:05 AM To: Larry Osterman; 'XO' Subject: RE: (Larry Osterman's WebLog) : Windows Audio No, that is very complete and accurate, with the slight correction that our processing is float32, not 24-bit.  We do not crop the signal anywhere.  As with all modern audio systems that support float32 processing, doing a conversion to int16 involves a dither calculation, but this can in no way be described as "15 bit cropping". ASIO and KS should work once the audio driver works properly on Vista (several companies are working on this prior to consumer launch at the end of this month).  We purposefully did nothing to KS and all KS oriented applications (including ASIO driver written on top of KS) should work fine.  We have been working closely with the audio hardware industry and have seen no across the board problems. -=<EHO>=- -----Original Message----- From: Larry Osterman Sent: Tuesday, January 02, 2007 10:52 AM To: 'XO' Cc: Elliot H Omiya (EHO) Subject: RE: (Larry Osterman's WebLog) : Windows Audio First off, as far as I know, nothing has been done to either ASIO or KS - I'd love to hear where that person got their information. Secondly, as far as cropping goes, we convert all content to 24bit floating point and render it (with no loss of fidelity).  If the user's audio driver doesn't support rendering audio samples in floating point (rendering floating point samples is a Vista logo requirement, so the only devices that don't support this aren't Vista logo compliant), we convert back to fixed point (usually a 16bit format).  When converting from 24bit floating back into 16bit integer, there is a possibility of a data loss (due to the dithering that must be done during the conversion). However, as far as I know, there is no "intentional" cropping of a signal to 15bits. There are a couple of other things to keep in mind.  First off, because we're rendering all audio in floating point format, it means that the quality of our sample rate conversions is several orders of magnitude better than it was on XP - the SRC in XP was measurably poor.  In addition, we fix the output format at (by default) 44.1kHz, which means that CD audio renders through the audio pipeline without conversions (except the int->float->int conversion mentioned above). One other thing to consider - most current audio CDs are rendered so hot that their signals are clipped on the CD - so losing some fidelity isn't going to make a difference to that content. Elliot, anything I missed?

Som den opmærksomme læser sikkert allerede har bemærket, så henvises der alene til, at al audio bliver behandlet med "floating point".

Sagt på almindeligt dansk betyder dette "interpolering" Der afvises på INTET tidspukt, at MS API'en konverterer ned til 15 bit for derefter at opkonvertere til 16 bit. Hvorfor mon... ?

Bemærkningen "...most current audio CDs are rendered so hot that their signals are clipped on the CD - so losing some fidelity isn't going to make a difference to that content..." siger også en del om, hvor "seriøst" lydkvaliteten tages fra den side ... ak-ak...

Hvorfor i øvrigt et behov for ASIO drivers, når nu MS's API fungerer "fejlfrit"...? 

__________________
Denny Crane tilbage på TV, dammit!

Strøm FAQ - lavet af forummet

Stop klynkeriet - kvinden tilbage i kvindekroppen!

xo skrev: Mere korrespondence nedenfor. Larry Osterman skrev: Nobody on the audio team (myself included) is willing to guarantee end-to-end, bit-for-bit transparency even for the KS path.  What we WILL guarantee is that if you're using directKS, ASIO, or WASAPI in exclusive mode no audio processing is done by Windows - the bits are handed to the driver without modification. What happens after the bits are sent down to the driver is up to the driver.  Having said that, if the driver is an hdaudio device (and thus supports waveRT), then if you're rendering via WASAPI exclusive mode, the app's audio samples are copied directly into the driver's DMA buffer, so they are effectively handed directly to the render hardware with no audio device driver intervention.  I can't speak to ASIO or directKS, since I don't know how they work. Dermed er det sat på plads at det er muligt, også i Windows Vista, med de rette indstillinger og drivere, at få bit-perfekt levering af audio data til hardware enheden.

Jamen hallo-hallo, hr. cognac

Hvilken del af "...Nobody on the audio team (myself included) is willing to guarantee end-to-end, bit-for-bit transparency even for the KS path..." er det, du ikke forstår...? 

Læg venligst mærke til, at der defineres, at O/S'et ikke laver ændringer.

Nu ved jeg tilfældigvis, at benævnte O/S juridisk er defineret som værende en "shell" og intet andet.

Altså en skal undenpå nogen "andet". Herunder ligger så samtlige .dll filer og andet tværliterært filmaterialæe

Operativsystemet er juridisk blot kernen ("kernel") af Windows, og intet andet. Altså kun en brøkdel af den mega-installation, de fleste af os foretager.

Hvad der så foregår i direkte Kernel-afhængige biblioteker synes der at være bemærkelsesværdig lav bekymring (og meget stille) omkring

Lad mig fluks (igen) minde om, at beslutningen omkring "the 15-bit audio "bug" in Windows" blev taget af Microsoft for at undgå et evt. sagsanlæg fra pladebranchen - og IKKE af undertegnede.



__________________
Denny Crane tilbage på TV, dammit!

Strøm FAQ - lavet af forummet

Stop klynkeriet - kvinden tilbage i kvindekroppen!

G&S, du læser det Larry Osterman skriver alt for selektivt og fokuserer på hans indledende kommentar uden at se på at hans uddybende kommentar faktisk konkluderer at det kan lade sig gøre, men han vil dog ikke garantere det uden visse betingelser er opfyldt. Det er en lidt manipulerende stil du der ligger for dagen, G&S. Det gamle trick med at hive et stykke tekst ud af dets kontekst.

 Men lad det nu ligge.

Jeg har egentligt ikke lyst til at recitere Larry Osterman da hans kommentarer allerede er fyldestgørende og beskriver hvad der sker.

Han kan dog ikke garantere at der ikke findes defekt hardware, hvilket jeg har fuld forståelse for.

Ghammel & Suhr skrev: napsi skrev: Ghammel & Suhr skrev: Fil systemer benytter naturligvis også CRC så man kan være sikker på at data læses korrekt og ens programmer kan køre korrekt. Igen, hvis du kan læse det her, så har jeg ret :D Ja, men hvad så med audio data - dem forholder du dig ikke til... Audio-data er en delmængde af data. Så enkelt kan det siges. Audio-data er den venlige delmængde, mens program-data er meget utilgivende overfor fejl, men begge behandles med samme kærlige omtanke fra filsystemets side. :) Hey Napsi, Et både etisk og poetisk smukt og rent forsøg på udtryk Selvom data umiddelbart behandles ens af filsystemet, kan der sagtens være et progressivt - ja, endda regressivt - slutresultat af databehandlingen Prøv nu for dæwleren af få de dersens fysikere til at fortælle dig lidt om, hvordan en +/- bit ser ud på et højopløsnings-scope. Og om forholdene omkring opfyldelsen af en "absolut" bit. Og måske nok så navnlig hvorfor begrebet "en absolut bit" er ikke-eksisterende Du har på din uddannelsesinstitution alle muligheder for at grave helt ned i dybden, så hvad holder dig tilbage...?

Måske skulle du i stedet begynde med den helt basale undervisning på området. :) Der kun 1'er og 0'er på filsystem-niveau. Hvis det var anderledes ville du ikke sidde her og skrive - dit system ville aldrig klare et boot.

Meld dig dog for h* ind på datalogi eller lignende i stedet for at sidde og spytte meningsløs lommevidenskab ud, som intet har med virkeligheden at gøre. :)

Ghammel & Suhr skrev: Fint nok. Du glemmer blot, at jitter ikke kun er bestemt af tid. Det er også bestemt af domæne. Altså har du udeladt en enkelt (men afgørende) faktor i den ovenstående ligning. Sinus, ArneBjarne, Goddamn sinus!

Hvad mener du med det (domæne)?

Ghammel & Suhr skrev: xo skrev: Den her debat om hvorvidt KS og ASIO fungerer fejlfrit i Windows Vista motiverede mig til at skrive til Larry Osterman, Microsoft udvikler på audio teamet for Windows Vista. Her er hans svar på hvorvidt audio data croppes til 15 bit nogle steder i stakken og hvorvidt KS eller ASIO er deaktiveret i Windows Vista. Larry Osterman & Elliot Omiya skrev: Yup, that makes sense, thanks for the clarification. -=<EHO>=- -----Original Message----- From: Larry Osterman Sent: Tuesday, January 02, 2007 11:09 AM To: Elliot H Omiya (EHO); 'XO' Subject: RE: (Larry Osterman's WebLog) : Windows Audio You're right (of course) about the float32 - I was confused because float32 can perform lossless functions with 24bits of accuracy (so I always think of there only being 24bits of "resolution" in the float32 value). -----Original Message----- From: Elliot H Omiya (EHO) Sent: Tuesday, January 02, 2007 11:05 AM To: Larry Osterman; 'XO' Subject: RE: (Larry Osterman's WebLog) : Windows Audio No, that is very complete and accurate, with the slight correction that our processing is float32, not 24-bit.  We do not crop the signal anywhere.  As with all modern audio systems that support float32 processing, doing a conversion to int16 involves a dither calculation, but this can in no way be described as "15 bit cropping". ASIO and KS should work once the audio driver works properly on Vista (several companies are working on this prior to consumer launch at the end of this month).  We purposefully did nothing to KS and all KS oriented applications (including ASIO driver written on top of KS) should work fine.  We have been working closely with the audio hardware industry and have seen no across the board problems. -=<EHO>=- -----Original Message----- From: Larry Osterman Sent: Tuesday, January 02, 2007 10:52 AM To: 'XO' Cc: Elliot H Omiya (EHO) Subject: RE: (Larry Osterman's WebLog) : Windows Audio First off, as far as I know, nothing has been done to either ASIO or KS - I'd love to hear where that person got their information. Secondly, as far as cropping goes, we convert all content to 24bit floating point and render it (with no loss of fidelity).  If the user's audio driver doesn't support rendering audio samples in floating point (rendering floating point samples is a Vista logo requirement, so the only devices that don't support this aren't Vista logo compliant), we convert back to fixed point (usually a 16bit format).  When converting from 24bit floating back into 16bit integer, there is a possibility of a data loss (due to the dithering that must be done during the conversion). However, as far as I know, there is no "intentional" cropping of a signal to 15bits. There are a couple of other things to keep in mind.  First off, because we're rendering all audio in floating point format, it means that the quality of our sample rate conversions is several orders of magnitude better than it was on XP - the SRC in XP was measurably poor.  In addition, we fix the output format at (by default) 44.1kHz, which means that CD audio renders through the audio pipeline without conversions (except the int->float->int conversion mentioned above). One other thing to consider - most current audio CDs are rendered so hot that their signals are clipped on the CD - so losing some fidelity isn't going to make a difference to that content. Elliot, anything I missed? Som den opmærksomme læser sikkert allerede har bemærket, så henvises der alene til, at al audio bliver behandlet med "floating point". Sagt på almindeligt dansk betyder dette "interpolering"

Nej? Floating-point betyder decimaltal, med flydende komma. Floats (32 bit) består af 1 sign-bit, 23 fraction-bits og 8 exponent-bits. Du kan, som han også siger, bruge dem som 24bit integers uden tab.

Ghammel & Suhr skrev: Der afvises på INTET tidspukt, at MS API'en konverterer ned til 15 bit for derefter at opkonvertere til 16 bit. Hvorfor mon... ?

Fordi han ikke kender al koden? Måske kunne du finde nogen der faktisk siger at det sker? :)

Ghammel & Suhr skrev: Bemærkningen "...most current audio CDs are rendered so hot that their signals are clipped on the CD - so losing some fidelity isn't going to make a difference to that content..." siger også en del om, hvor "seriøst" lydkvaliteten tages fra den side ... ak-ak...

Det er da trist ja hvis det er et arh-vi-gider-ikke-stramme-op-så, men kunne også være for at gøre opmærksom på at evt. problemer man oplever med lyden, kunne være fra kilden?

Ghammel & Suhr skrev: Hvorfor i øvrigt et behov for ASIO drivers, når nu MS's API fungerer "fejlfrit"...?

"ASIO (Audio Stream Input Output) is a protocol for low-latency digital audio specified by Steinberg.

ASIO provides an interface between an application and the sound card. Whereas Microsoft's DirectSound is typically for stereo input and output for consumers, ASIO provides for the needs of musicians and sound engineers. ASIO offers a relatively simple way of accessing multiple audio inputs and outputs independently. It also provides for the synchronization of input with output in a way that is not possible with DirectSound, allowing recording studios to process their audio via software on the computer instead of using thousands of dollars worth of separate equipment. Its main strength lies in its method of bypassing the inherently high latency of operating system audio mixing kernels, allowing direct, high speed communication with audio hardware."

Har nogen skrevet på wikipedia. Skal ikke kunne sige om det er rigtigt. :)

For at skære et par ting ud i pap. Det bliver vel egentligt det sidste jeg skriver om det her aspekt af sagen, med mindre der kommer nye og sandfærdige ting frem.

Windows XP/Vista bruger en mixer. Mixeren i de to Windows versioner er forskellig, i Windows XP er det en 16 bit mixer, i Windows Vista er det en 32 bit mixer.

For at sige det på jævnt dansk så er en mixer noget der mixer ting sammen. Det den mixer sammen er to audio data strømme. Under Windows XP kan mixeren ikke mixe 16 bit data uden tab, det er en 16 bit mixer og for at få 16 bit data mixet uden tab skal det ske med 24 bit præcision eller mere. Windows Vista mixeren er 32 bit fp og kan derfor mixe med 24 bits heltals præcision, som beskrevet af Osterman.

Men fødes en mixer med kun én bit strøm (exclusive mode), kan den operere uden korruption af data. Og som Osterman beskriver kan Windows Vista operere under betingelser hvor den ikke ændrer audio data. Det samme kan ske i Windows XP, men her er det nødvendigt at data går udenom mixeren, for at det kan ske. Det er der en del herinde der allerede gør, mig selv inklusive. Den data sti kaldes Kernel Streaming (KS) og også den findes under Windows Vista, men den går Osterman dog ikke nærmere ind på, hvilket han da heller ikke behøver, da han allerede har beskrevet at transporten af bits kan forkomme, selv udenfor KS, uden transformation.

Den simple konklusionen, eller det simple resumé, er at under de korrekte betingelser kan Windows {XP,Vista} fødes med 16 bit audio data. Disse data kan under disse betingelser vandre hele vejen igennem Windows audio stakken og hele vejen til driveren uden modifikation. Hvad der sker derefter er op til driveren og hardwaren; læs den sætning igen. Dog peger Osterman på følgende (betingelserne):

Larry Osterman skrev: Having said that, if the driver is an hdaudio device (and thus supports waveRT), then if you're rendering via WASAPI exclusive mode, the app's audio samples are copied directly into the driver's DMA buffer, so they are effectively handed directly to the render hardware with no audio device driver intervention.  I can't speak to ASIO or directKS, since I don't know how they work.

Og således skete det at jeg brød mit eget forbud mod at recitere Larry Osterman, men jeg er simpelthen for doven til at oversætte det til dansk.

Med mindre der kommer nye ting frem om Windows audio stakken og noget konkret omkring defekte drivere og hardware eller defekter i fx foobar2000 eller winamp, så kan jeg ikke se hvordan jeg skal kunne debattere den her del af transporten af bits. Det bliver bare til gentagelser af mig selv og Osterman.

Men jeg kan da godt forstå din fascination af hvad der sker fysisk og hvordan en bit egentligt ser ud. Det er alt sammen fint og godt, men ændrer vel egentligt ikke på systemets samlede korrekthed under normale omstændigheder, da der somsagt er taget højde for fejl i protokoller og hardware.

Der sker fejl, og der sker vel også en bitfejl, af og til, men hvis systemet kompenserer korrekt for bitfejl 99,999999% af tiden, så kan jeg leve med det. Nej så hellere fokusere på hardware kæden efter driveren; så hellere finde et ideelt interface. TCP/IP for teh win, sammenlignet med SPDIF.

Hvis jeg skal være lidt ligefrem, og det syntes jeg at jeg skal, så mener jeg du gerne vil forsøge at finde et eller andet hul i Windows hvor tingene ikke sker som de bør ske. Men jeg syntes lidt du klamrer dig til sæbebobler, halmstrå, luftkasteller, rygter og spekulationer, G&S. Der skal lisom være noget mere konkret at forholde sig til, og det syntes jeg lidt mangler.

To be or not to be, a bit, that is the question - or not. Men lad os nu se hvad du finder på nu.

Det kan være vi skal ud i en (meta)fysisk diskussion om (ho)bittens væsen (de' gas).

Det er somom du mener, G&S, at den enkelte bit, som formation i et medie, giver anledning til jitter der vandrer hele vejen til konverteren.

Men jeg mener bare man skal se på asynkrone protokoller med fejlkorrektion og så ellers buffere, for at eliminere jitter ned til picosekund deltaer.

Ghammel & Suhr skrev: Imidlertid introducerer fjernplaceringen en række nye problemer. Ganske vist er TCP/IP proto'en samt diverse trådløse dittoer fejltolerante, vil nogle nok allerede nu oppunere. Men når det kommer til audio, er tingene (som altid) en smule anderledes. Fejltolerancen i TCP/IP er alene på datapakkkerne, hvis størrelse er bestemt af enten operativsystemet eller konfigurationen af netkortet, og ikke på de enkelte bits. Så allerede dér har vi en ganske wæmmerlig synder til datafejl (dette er i øvrigt en ganske wæmmelig forenkling af denne problemstilling). Som tommelfingerregel er det derfor (som altid) alene et spørgsmål om, hvor mange fejl man vil acceptere i sine data. Ethvert ekstra led i kæden introducerer en ny, plausibel fejlkilde, der igen skal opløftes i 2. potens for hver ekstra led, der introduceres. I den virkelige verden stiger antallet af fejl med andre ord eksponentielt med antallet af led i kæden. Et "led" er (også) i denne sammenhæng at betragte som enhver afbrydelse, mellemstation (f.eks. buffer lagring) eller konvertering af det oprindelige signal.

Jeg gik og undrede mig over hvem der i sin vildelste fantasi kunne springe på dette kabel...men nu har jeg forklaringen. Se kabel her.. http://www.hifiklubben.com/DK/Produkter/Kabel/Digitalkabel/D ENON_AK-DL1_DenonLink_kabel.htm

xo skrev: Det er somom du mener, G&S, at den enkelte bit, som formation i et medie, giver anledning til jitter der vandrer hele vejen til konverteren. Men jeg mener bare man skal se på asynkrone protokoller med fejlkorrektion og så ellers buffere, for at eliminere jitter ned til picosekund deltaer.

Enig....den matematiske verden er perfekt. Enten er der et 1-tal eller et 0 - og nej en bit kan ikke være i modfase. Alle andre forklaringer skal findes senere i kæden.

Til Ethernet transport, der har solid fejlkorrektion, er det kabel helt ude i den afghanske hamp efter min mening.

Hvis hvert ekstra led indfører fejl, og de fejl ikke kan håndteres, så ser det ikke godt ud for det gode Internet, for med de mange terabytes der dagligt overføres, gennem mange servere, vil der være nogle (mange, rigtig rigtig mange) mennesker der bliver godt sure over at deres e-mails, dokumenter, zip filer, billeder, osv. fremkommer i korrupt tilstand. Digitalitet og fejlkorrektion er en herlig ting.

Men hvis man mener der opstår hørbar jitter i en buffer, ja så kan jeg da godt se motivationen. Men hvordan er det lige det foregår i en CD afspiller?

Martin_Kbh skrev: Jeg gik og undrede mig over hvem der i sin vildelste fantasi kunne springe på dette kabel...men nu har jeg forklaringen. Se kabel her.. http://www.hifiklubben.com/DK/Produkter/Kabel/Digitalkabel/D ENON_AK-DL1_DenonLink_kabel.htm

Det er ikke en kabel for Ethernet uden for DenonLink.

Hvis det protkoll kræver extra gode kabler ved jeg ikke.

Johan N: OK, det er ikke alm Ethernet men en proprietær Denon standard. Den kan vi ikke rigtigt udtale os om så.

xo skrev: Johan N: OK, det er ikke alm Ethernet men en proprietær Denon standard. Den kan vi ikke rigtigt udtale os om så.

Ja OK...men en tier på at den kun indeholder nuller og et-taller.