Re: Problem med DAC i bil
Morten Leikvoll
news:r6toq6t79bfh7uv13...@4ax.com...
> Kom nettopp hjem fra USA med en HRT iStreamer i kofferten. Dette er
> kort fortalt en DAC som kobles til en Apple iDings, som altså tapper
> digitalsignalet fra Apple-tingen og gjør det om til et analogt signal
> på en skikkelig måte. Har et par USB DAC's fra HRT fra før, topp
> kvalitet og resultat.
Hvor får denne strøm fra?
Harald Ljøen
> Det eneste jeg kan tenke meg er at bilens AUX-inngang av en eller
> annen årsak ikke liker signalet som kommer ut av iStreameren. Men er
> ikke det litt snodig?
Ut fra beskrivelsen virker det som det er dette som er tilfellet, ja.
Signalet fra DACen overstyrer AUX-inngangen på bilanlegget ditt.
Sjekk om det er mulig å justere ned utgangsssignalet på DACen. Hvis ikke
det går kan du legge inn en spenningdeler (to motstander på hver kanal)
mellom DACen og AUX-inngangen.
Thomas Lundquist
> - Når jeg reduserer volumet på min iPod (160GB classic) forsvinner
> støyen. Dessverre er det ikke mulig å redusere volumet på iPad/iPhone
> når den står i digial dock mode, så det hjelper ikkeno. Aner ikke
> hvorfor det går for seg på en iPod egentlig, og hvordan den reduserer
> volumet når den ikke bruker sin egen DAC...
>
> Det eneste jeg kan tenke meg er at bilens AUX-inngang av en eller
> annen årsak ikke liker signalet som kommer ut av iStreameren. Men er
> ikke det litt snodig?
Du svarer jo iofs selv; DACen har for høyt utgangssignal og du får vreng
på den enheten som tåler minst.
> Kan det være signalveien fra midtarmelenet til head unit som ikke
> tåler "trøkket", eller er det selve inngangen? Forslag til hva som kan
> gjøres mottas med stor takk, for dette var nedtur! :-/
Hva som kan gjøres er derimot verre, bytte DAC, gi beng i DACen eller
bruke noe som har volum"knapp" på digital ut.
Egentlig burde ikke slikt være nødvendig men når man kan skru volumet
digitalt skjer det.
ez
--
Med infrastruktur bygger vi landet.
Siteringsproblemer? : http://www.bersvendsen.com/usenet/quoting.html
Thomas Lundquist
> Sjekk om det er mulig å justere ned utgangsssignalet på DACen. Hvis
> ikke det går kan du legge inn en spenningdeler (to motstander på hver
> kanal) mellom DACen og AUX-inngangen.
Men husk at de må ha gullring!
ez
--
DoD#3098, DoDRT#02, DoDCT#012, 066, SUCKS#012, NIC#03, SDK#1528, AMO#209sjef
'97 Ducati ST2(Greven), '96 Honda GOOF3(Singer), '00 CBR900RR(Pfaff)
'99 Mercedes Vito 112CDi (Nimitz)
Siteringsutfordringer? : http://www.bersvendsen.com/usenet/quoting.html
KAS
> Hvor får denne strøm fra?
Den drives av USB, har en 12V USB adapter som leverer mer enn nok.
--
/KAS <-------- '09 RSV4 Factory -------->
Bamsemums MC #002 - DoD #4344 - DoDRT #007
"V-four ergo Vrooooooooooom"
KAS
> Du svarer jo iofs selv; DACen har for høyt utgangssignal og du får vreng
> på den enheten som tåler minst.
Den skal ha fast, og høyt utgangssignal sa bilstereo-frikene som solgte den.
> Hva som kan gjøres er derimot verre, bytte DAC, gi beng i DACen eller
> bruke noe som har volum"knapp" på digital ut.
iPod'en har tydeligvis volumknapp på digital ut, så det funker jo. Men
hvordan dette skjer skjønner jeg ikke helt. Degraderer den signalet på
noen måte?
Har ikke lyst å gi opp DACen, den gjør virkelig en solid jobb.
Et alternativ kan kanskje være å koble den via inngangen til
CD-skifteren, den trenger jeg jo uansett ikke.
KAS
> On 18.04.2011 19:29, KAS wrote:
>> Det eneste jeg kan tenke meg er at bilens AUX-inngang av en eller
>> annen årsak ikke liker signalet som kommer ut av iStreameren. Men er
>> ikke det litt snodig?
>
> Ut fra beskrivelsen virker det som det er dette som er tilfellet, ja.
> Signalet fra DACen overstyrer AUX-inngangen på bilanlegget ditt.
>
> Sjekk om det er mulig å justere ned utgangsssignalet på DACen.
Nope, det er fast.
> Hvis ikke
> det går kan du legge inn en spenningdeler (to motstander på hver kanal)
> mellom DACen og AUX-inngangen.
Anelse om hvilke motstander jeg bør bruke?
Finnes det phono-plugger eller kabel ferdig med motstand i tro?
Her er specs på saken:
http://www.highresolutiontechnologies.com/pdf/HRT-iStreamer.pdf
FullScaleOutput 2.25VoltsRMS
FrequencyResponse(20Hz/20kHz) 0dB/-.4dB
NoiseFloor(DC->30kHz) 28uV
S/NRatio(DC->30kHz) 98dB
Når jeg skrur ned volumet på iPoden til ca. 80% høres alt i
utgangspunktet fint ut.
Kan jo forsåvidt bare slå meg til ro med det også, dersom det ikke
medfører noen nedgradering av lydkvaliteten.
Bjørn Brox
>
> iPod'en har tydeligvis volumknapp på digital ut, så det funker jo. Men
> hvordan dette skjer skjønner jeg ikke helt. Degraderer den signalet på
> noen måte?
Det var det jeg stusset på også, - hvordan kan volumknappen påvirke det
digitale signalet?
Sikker på at det er digitalsignalet du bruker?
--
Bjørn Brox
Harald Ljøen
>> Hvis ikke
>> det går kan du legge inn en spenningdeler (to motstander på hver kanal)
>> mellom DACen og AUX-inngangen.
>
> Anelse om hvilke motstander jeg bør bruke?
100 ohm mellom jord og AUX-inngang, og 1 kOhm i serie på signallederen
mellom DAC og AUX-inngang vil dempe signalet ca 1:10 som burde gi greit
signalnivå og impedansforhold dersom AUX er en standard linjeinngang. Du
bør også sørge for at motstandene er skjermet for å unngå at det plukkes
opp støy.
> Finnes det phono-plugger eller kabel ferdig med motstand i tro?
Aner ikke. Har ikke sett noe sånt, men det betyr ikke at det ikke
finnes. Hvis du er hendig med loddebolten kan du jo lage dine egne
phonoplugger med et slikt dempeledd innebygd.
> Kan jo forsåvidt bare slå meg til ro med det også, dersom det ikke
> medfører noen nedgradering av lydkvaliteten.
Audiopurister vil helst ikke ha digital volumkontroll da det gir mer
støy enn om det digitale signalet har full range. Men jeg tviler vel
litt på at du vil høre forskjell, særlig ikke i en bil...
Morten Leikvoll
> On 19.04.2011 08:46, Morten Leikvoll wrote:
>
>> Hvor får denne strøm fra?
>
> Den drives av USB, har en 12V USB adapter som leverer mer enn nok.
Er ikke sikkert jordningsnivåene på 12v uttaket ditt er i takt med
jordingsnivået på forsterkeren. Kan du prøve med eget isolert batteri?
KAS
Godt tips, kan prøve med 220V adapteret i stedet.
Forsøkte forsåvidt å kjøre lyden inn i en Tivoli iPAL i bilen, DACen
fikk da strøm fra 12V. Hørte ingen feil da.
KAS
Nja, sikker og sikker...
DACen er koblet med USB til iPoden "i rompa" på iPoden, ikke på den
analoge mini-jacken. Jeg trodde den da automagisk hentet det digitale
signalet, men det er jo slett ikke helt sikkert. Spørsmålet er om den
vil godta et analogt signal fra iPoden, det høres litt rart ut.
Ja, iPoden, kan sende analogt ut på den porten også, det er det ingen
tvil om.
KAS
> On 19.04.2011 10:56, Bjørn Brox wrote:
>> Den 19.04.2011 09:40, skrev KAS:
>>>
>>> iPod'en har tydeligvis volumknapp på digital ut, så det funker jo. Men
>>> hvordan dette skjer skjønner jeg ikke helt. Degraderer den signalet på
>>> noen måte?
>>
>> Det var det jeg stusset på også, - hvordan kan volumknappen påvirke det
>> digitale signalet?
>> Sikker på at det er digitalsignalet du bruker?
>
> Nja, sikker og sikker...
>
> DACen er koblet med USB til iPoden "i rompa" på iPoden, ikke på den
> analoge mini-jacken. Jeg trodde den da automagisk hentet det digitale
> signalet, men det er jo slett ikke helt sikkert. Spørsmålet er om den
> vil godta et analogt signal fra iPoden, det høres litt rart ut.
>
> Ja, iPoden, kan sende analogt ut på den porten også, det er det ingen
> tvil om.
Denne tråden bekrefter jo at man kan styre volumet fra en "classic" iPod
på denne måten, men ikke på de nye:
Det er neppe analoge signaler iStreameren får fra iPoden, den senser
nemlig bitrate og viser det korrekt med en LED. Og ja, det skifter og
matcher med kildefilen, så det må nesten være digitalt.
Morten Leikvoll
> On 19.04.2011 11:53, Morten Leikvoll wrote:
>> "KAS"<mil...@dod.no> wrote in message
>> news:iojdlc$na2$1...@news.prioris.net...
>>> On 19.04.2011 08:46, Morten Leikvoll wrote:
>>>
>>>> Hvor får denne strøm fra?
>>>
>>> Den drives av USB, har en 12V USB adapter som leverer mer enn nok.
>>
>> Er ikke sikkert jordningsnivåene på 12v uttaket ditt er i takt med
>> jordingsnivået på forsterkeren. Kan du prøve med eget isolert batteri?
>
> Godt tips, kan prøve med 220V adapteret i stedet.
> Forsøkte forsåvidt å kjøre lyden inn i en Tivoli iPAL i bilen, DACen fikk
> da strøm fra 12V. Hørte ingen feil da.
Hvis du tenker på 12-220v adapter så ville jeg ikke prøvd det. Prøv heller
med helt isolert power, enten fra batteri eller batterieliminator fra
skjøteledning.
Men ideellt sett skulle dac'en stått nær forsterkeren og heller hatt usb
kabel frem til den, men da kan det jo oppstå andre problemer som
spenningstap på usb kabelen, men det går vel ikke så mye strøm så kanskje
det går dersom du finner en usb extender som passer.
KAS
> Hvis du tenker på 12-220v adapter så ville jeg ikke prøvd det. Prøv heller
> med helt isolert power, enten fra batteri eller batterieliminator fra
> skjøteledning.
Var det jeg mente, det følger jo med et 220V til USB adapter til DACen,
strøm utenfor huset har jeg jo.
> Men ideellt sett skulle dac'en stått nær forsterkeren og heller hatt usb
> kabel frem til den,
USB på analogsiden? Det går vel ikke?
Signalveien er jo koblet slik nå:
iPod -> USB -> DAC -> Phono -> Forsterker
DAC'en får strøm fra et USB strømadapter, som får strøm fra bilens 12V
_eller_ et 220V adapter, men det er vel underordnet i denne sammenheng.
Som sagt, lyden er fin gjennom en annen forsterker med nøyaktig samme
strøm og signalvei som når bilstereoen hikker.
Kombinert med det faktum at feilen forsvinner når jeg kan justere ned
volumet gjennom iPoden, så er jeg nå helt overbevist om at det er som
flere andre sier, utgangsnivået fra DAC'en er for høyt til at
bilstereoen liker det.
Merkelig, det er top-of-the-line systemet fra BMW. Sier vel egentlig
ikke så mye...
Thomas Lundquist
> On 19.04.2011 09:16, Thomas Lundquist wrote:
> Den skal ha fast, og høyt utgangssignal sa bilstereo-frikene som solgte den.
Høyt er jo åpenbart ikke bra og skaper problemet ditt.
> iPod'en har tydeligvis volumknapp på digital ut, så det funker jo. Men
> hvordan dette skjer skjønner jeg ikke helt. Degraderer den signalet på
> noen måte?
Jeg tror ikke s/pdif har eget "signal" for volum så det man evt må er jo
å endre nivåene på samplene og det vil nok noen anse som degradering.
> Har ikke lyst å gi opp DACen, den gjør virkelig en solid jobb.
Egentlig burde i*-greien ha mer enn bra nok DAC, spesiellt inni en bil
som uansett har bakgrunnsstøy men jeg har hørt uteolig mye drit om
lydkvaliteten i i* fra Apple så jeg tror deg til en forandring.
> Et alternativ kan kanskje være å koble den via inngangen til
> CD-skifteren, den trenger jeg jo uansett ikke.
Koble hva til? Hvis inngangen til CD-skifteren er digital trenger du jo
ikke engang DACen og jeg ville helt klart uansett testa ut den
løsningen.
KAS
> KAS<mil...@dod.no> writes:
>
>> On 19.04.2011 09:16, Thomas Lundquist wrote:
>
>> Den skal ha fast, og høyt utgangssignal sa bilstereo-frikene som solgte den.
>
> Høyt er jo åpenbart ikke bra og skaper problemet ditt.
Normalt er det jo bra da.
De jeg kjøpte den av er store bilstereo-guruer og ekstrem-byggere i
California, de har aldri hørt om problemet før. De bruker denne DAC'en
nærmest som default i sine installasjoner, siden de mener den gir
sinnsykt mye for penga. Dette er gutter som har bygd bilstereo i
generasjoner, har litt mer enn en smule cred i det miljøet og vet hva de
snakker om.
>> iPod'en har tydeligvis volumknapp på digital ut, så det funker jo. Men
>> hvordan dette skjer skjønner jeg ikke helt. Degraderer den signalet på
>> noen måte?
>
> Jeg tror ikke s/pdif har eget "signal" for volum så det man evt må er > jo å endre nivåene på samplene og det vil nok
noen anse som
> degradering.
Dette er ikke S/PDIF, det er en PCM strøm, sannsynligvis over I2S.
Jeg *tipper* det ipodden gjør er å konvertere voluminnstillingen til en
ReplayGain som "fast" metadata i overføringen til DAC'en. Det betyr at
DAC'en får beskjed om å endre utgangssignalet med X dB. Det bør ikke gå
ut over lydkvaliteten, da dataene ut fra ipodden vil være helt uendret.
>> Har ikke lyst å gi opp DACen, den gjør virkelig en solid jobb.
>
> Egentlig burde i*-greien ha mer enn bra nok DAC, spesiellt inni en bil
> som uansett har bakgrunnsstøy men jeg har hørt uteolig mye drit om
> lydkvaliteten i i* fra Apple
De bruker en helt "decent" kombnert Wolfson DAC/hodetelefon forsterker.
Tatt i betraktning at den koster $0,5 gjør den sikkert en god jobb...
Det er derimot hevet over noen som helst slags tvil at en ekstern DAC
til $200 gjør en dramatisk forskjell på ethvert fornuftig anlegg for
alle som har mer enn 60% av hørselen intakt. Når man måler og plotter
resulatet blir forskjellen grotesk rent visuelt.
> så jeg tror deg til en forandring.
Jeg håper inderlig det ikke var ment like utrolig arrogant som det
oppfattes...
>> Et alternativ kan kanskje være å koble den via inngangen til
>> CD-skifteren, den trenger jeg jo uansett ikke.
>
> Koble hva til? Hvis inngangen til CD-skifteren er digital trenger du jo
> ikke engang DACen og jeg ville helt klart uansett testa ut den
> løsningen.
Sant, CD-skifteren henger sikkert på fiber, jeg tenkte meg at den var
koblet på en analog inngang.
Thomas Lundquist
>> Høyt er jo åpenbart ikke bra og skaper problemet ditt.
>
> Normalt er det jo bra da.
For høyt er aldri bra. Overstyring er kjipt. At bilstereoen ikke tåler
like mye som det meste andre er dog teit.
Kanskje det er en mikrofoninngang? :=)
> Dette er ikke S/PDIF, det er en PCM strøm, sannsynligvis over I2S.
Fra iGreia? ok. Det finnes kanskje overganger/convertere?
> Jeg *tipper* det ipodden gjør er å konvertere voluminnstillingen til
> en ReplayGain som "fast" metadata i overføringen til DAC'en. Det betyr
> at DAC'en får beskjed om å endre utgangssignalet med X dB.
Hvis det sendes metadata så ja. Da burde det også være mulig å løse
med en firmwareoppgradering av DACen om den har sånt.
> Det bør
> ikke gå ut over lydkvaliteten, da dataene ut fra ipodden vil være helt
> uendret.
Om det gjøres på den måten så er jo samplingsdata intakt.
> De bruker en helt "decent" kombnert Wolfson DAC/hodetelefon
> forsterker. Tatt i betraktning at den koster $0,5 gjør den sikkert en
> god jobb...
Det gjør den nok. Er vel Shuffle som har fått mest tyn for lydkvalitet
og da når man sammenligner med tilsvarende greier, ikke med dyre saker.
>> så jeg tror deg til en forandring.
>
> Jeg håper inderlig det ikke var ment like utrolig arrogant som det
> oppfattes...
Hehe. Vi har jo hatt våre hi-fi/snake-fi - diskusjoner før uten å alltid
komme til noen konklusjon. og jeg venter jo fremdeles på en invitasjon
til testing av HDMI-kabel (eller var det HDMI vs s/pdif til receiver?)
>> Koble hva til? Hvis inngangen til CD-skifteren er digital trenger du jo
>> ikke engang DACen og jeg ville helt klart uansett testa ut den
>> løsningen.
>
> Sant, CD-skifteren henger sikkert på fiber, jeg tenkte meg at den var
> koblet på en analog inngang.
Fiber i bilen? ikke bankers, ei heller er vel s/pdif bankers heller, kan
jo hende de er like kjipe som Apple når det kommer til å bruke
standarder.
Den analoge inngangen, om den finnes, kan være bedre enn den du tester
med nå, av en eller anna grunn. Egentlig burde det jo vært motsatt, at
AUX inn var satt opp til å tåle vesentlig mer enn en anna inngang ment
for spesifikt utstyr. Man veit jo aldri hva folk stapper inn i AUXen.
KAS
>
> Fra iGreia? ok. Det finnes kanskje overganger/convertere?
Hva skulle det være godt for?
> Hvis det sendes metadata så ja. Da burde det også være mulig å løse
> med en firmwareoppgradering av DACen om den har sånt.
Kan være en mulighet, men spørs om de gjør det bare for meg. Skal prøve
i et par andre BMW'er og se om det er samme sak der.
> Hehe. Vi har jo hatt våre hi-fi/snake-fi - diskusjoner før uten å alltid
> komme til noen konklusjon. og jeg venter jo fremdeles på en invitasjon
> til testing av HDMI-kabel (eller var det HDMI vs s/pdif til receiver?)
Snake meg her og snake meg der, det er vel heller du som er ekstremist
av prinsipp eller noe, mens jeg er en smule mer nyansert.
Du påstår at en HDMI-kabel enten funker, eller ikke funker. Dette er
åpenbart helt feil i følge alle som har erfaring og vet hva de snakker
om, meg selv inklusive. Ved store lengder kan man få svært mye rart av
resultater mellom disse ytterpunktene, og det handler uten noen som
helst slags tvil om kabelens kvalitet. Dette er jo basis kunnskap for
enhver som vet noe om fysisk digitaloverføring, og ikke bare kan software.
Jeg har ved gjentatte ganger invitert deg til å se det med egne øyne
hjemme hos meg dersom du velger å være så arrogant at du nekter å tro
det du enkelt kan verifisere med et par google-søk. Så ennå en gang:
Bare fortell meg når det passer for deg, du er hjertelig velkommen til å
se det med egne øyne. Det er en åpen invitasjon, som du har fått før
uten å svare på. Men vær så snill å drit i å være så fordømt påståelig i
fremtiden før du enten har takket ja til invitasjonen, eller tatt til
vettet og innrømmet at du rent faktisk tar feil. Ok?
> Fiber i bilen?
Absolutt, helt vanlig. Selv min 1993 Audi S4 hadde det mellom
CD-skifteren og head unit.
ikke bankers, ei heller er vel s/pdif bankers heller,
Usikker på protokoll, men mener den var en smule proprietær.
> kan
> jo hende de er like kjipe som Apple når det kommer til å bruke
> standarder.
Bilbransjen er en smule sære der. De liker CAN-bus og K-line og sånt.
--
/KAS
'08 X5 35d M-Sport
'03 Boxster S - Selges
'09 RSV4 Factory
|------ xDrive ergo Zoooom! -----|
Thomas Lundquist
>> Hvis det sendes metadata så ja. Da burde det også være mulig å løse
>> med en firmwareoppgradering av DACen om den har sånt.
>
> Kan være en mulighet, men spørs om de gjør det bare for meg. Skal
> prøve i et par andre BMW'er og se om det er samme sak der.
Med samme anlegg da formoder jeg.
> Snake meg her og snake meg der, det er vel heller du som er ekstremist
> av prinsipp eller noe, mens jeg er en smule mer nyansert.
Nja, hvorfor kan man alltids diskutere men det er gjerne basert på
kunnskap.
> Du påstår at en HDMI-kabel enten funker, eller ikke funker. Dette er
> åpenbart helt feil i følge alle som har erfaring og vet hva de snakker
> om, meg selv inklusive. Ved store lengder kan man få svært mye rart av
> resultater mellom disse ytterpunktene, og det handler uten noen som
> helst slags tvil om kabelens kvalitet.
Altså; at kabelkvalitet har en del å si på lange strekk og høye bitrater
er rimelig åpenbart. Og ja, det er mye skit på den fronten. Jeg har 10m
"HDMI" som består av en 5m DVI og en 5m HDMI og en overgang og det bare
funker ikke fra HDMI-splitteren min. Rett fra receiveren funker.
Så jeg har bestilt en ny 10m HDMI fra Dealextreme, ca 160 spenn.
> Dette er jo basis kunnskap for
> enhver som vet noe om fysisk digitaloverføring, og ikke bare kan
> software.
Vel, jeg har da noe greier om både digital og analog teknikk på
vitnemålet mitt siden du insinuerer noe.
> Jeg har ved gjentatte ganger invitert deg til å se det med egne øyne
> hjemme hos meg dersom du velger å være så arrogant at du nekter å tro
> det du enkelt kan verifisere med et par google-søk.
Den ene diskusjonen var om å kjøre HDMI igjennom receiveren istedenfor
direkte og s/pdif til receiveren hadde noe å si lydmessig. Du påstod
hardnakket det.
> Så ennå en gang:
> Bare fortell meg når det passer for deg, du er hjertelig velkommen til
> å se det med egne øyne. Det er en åpen invitasjon, som du har fått før
> uten å svare på. Men vær så snill å drit i å være så fordømt påståelig
> i fremtiden før du enten har takket ja til invitasjonen, eller tatt
> til vettet og innrømmet at du rent faktisk tar feil. Ok?
Da har jeg ikke fått med meg det og jepp, lenge siden jeg har sett deg
så det må vi jaggu få ordna.
>> Fiber i bilen?
>
> Absolutt, helt vanlig. Selv min 1993 Audi S4 hadde det mellom
> CD-skifteren og head unit.
>
> ikke bankers, ei heller er vel s/pdif bankers heller,
>
> Usikker på protokoll, men mener den var en smule proprietær.
Teitingene.
>> kan
>> jo hende de er like kjipe som Apple når det kommer til å bruke
>> standarder.
>
> Bilbransjen er en smule sære der. De liker CAN-bus og K-line og sånt.
Men CAN-bus er en standard og relativt åpen. De har blitt tvunget til å
standardisere på diagnoseplugg, protokoll og et sett kommandoer så EU
har vært mye flinkere der enn mot Apple.
Men hadde bilbransjen hatt sjansen hadde de vært minst like proprietære
som Apple.
KAS
> KAS<mil...@dod.no> writes:
>
>>> Hvis det sendes metadata så ja. Da burde det også være mulig å løse
>>> med en firmwareoppgradering av DACen om den har sånt.
>>
>> Kan være en mulighet, men spørs om de gjør det bare for meg. Skal
>> prøve i et par andre BMW'er og se om det er samme sak der.
>
> Med samme anlegg da formoder jeg.
Tja, vet ikke helt om det er samme head-unit eller ikke, sannsynligvis
er det. Det finnes 4 varianter: Standard, Hifi Høyttalersystem, HiFi
Professional og HiFi Professional DSP (også kalt Logic7).
Jeg har sistnevnte, og har nå testet i biler som har "Standard" og "HiFi
Høytallersystem". Samme resultat som i min.
> Altså; at kabelkvalitet har en del å si på lange strekk og høye bitrater
> er rimelig åpenbart.
Ja, og det er jo nettopp det jeg har påpekt, og ikke noe annet. Mens du
temmelig kategorisk kalte det "snake oil" å kjøpe noe annet enn det
aller billigste.
> Så jeg har bestilt en ny 10m HDMI fra Dealextreme, ca 160 spenn.
Kjør Full HD på den, og så kobler du en kabel av aller billigste slag
mellom BluRay og receiver. KAN hende det går på 10M, men jeg tviler, og
jeg er rimelig sikker på at du vil få datatap (og dermed helt uungåelig
kvalitetstap). En slik kobling går ikke hos meg, men jeg har vel 15M på
det lange strekket nå.
> Den ene diskusjonen var om å kjøre HDMI igjennom receiveren istedenfor
> direkte og s/pdif til receiveren hadde noe å si lydmessig. Du påstod
> hardnakket det.
Aner ikke hva du snakker om her.
Morten Leikvoll
> Kjør Full HD på den, og så kobler du en kabel av aller billigste slag
> mellom BluRay og receiver. KAN hende det går på 10M, men jeg tviler, og
> jeg er rimelig sikker på at du vil få datatap (og dermed helt uungåelig
> kvalitetstap). En slik kobling går ikke hos meg, men jeg har vel 15M på
> det lange strekket nå.
For å stresse mottakeren kan du også prøve å kjøre fullskjerm
pixel-sjakkmønster fra kilden for å se om den kan leve med det. Det er
mottakere som sliter med dette mønsteret tilogmed på kort kabel. Det som
skjer er at det dekodete signalet lager ekstra bråk i elektronikken rundt
mottakeren og lager dermed høyere SNR. Kun bra designet elektronikk klarer
det og jo høyere pixelrate jo verre blir det.
Her er et slik bilde i 1920x1080
http://protie.sweb.cz/checkerboard_1920_1080.gif
Morten Leikvoll
"Morten Leikvoll" <mlei...@lyse.nospam.net> wrote in message
news:Js2dnRfdT6ZiNSDQ...@lyse.net...
> mottakeren og lager dermed høyere SNR. Kun bra designet elektronikk klarer
*flau*
Selvsagt lavere SNR (altså verre mottakerforhold)
Dag-Erling Smørgrav
> Ok, jeg skal gi EZ litt slækk, han rodde som et helvete og mente etter
> hvert i diskusjonen at "synlige bitfeil" falt innenfor definisjonen av
> "virker ikke". Hva han mener om "ikke fullt så åpenbare bitfeil", som
> av enkle årsaker er nødt til å forekomme og forårsake generell
> degradering av kvaliteten aner jeg ikke, jeg ga opp før den tid, da
> jeg fikk følelsen av å diskutere religion med en muslim.
> ;-)
>
> Nuvel, når du stikker innom EZ, kan du ikke ta med deg din 10M kabel
> til 160 spenn, så kobler vi den opp her og sammenligner med min (meget
> rimelige) 15 meter kabel til Kr. 2000 på pixel-sjakkmønster. Blir
> spennende!
EZ har faktisk *litt* peiling på det han snakker om.
Konsekvensene av forstyrrelser av et digitalt signal, uansett hva slags
signal det er snakk om, er veldig forskjellige fra konsekvensene av
forstyrrelser av et analogt signal. Man vil ikke få skurring, støy
eller snø på skjermen; man vil få kutt i lyden, manglende oppdatering av
deler av bildet, og lignende. Det ikke er snakk om noen gradvis
forringelse: enten vil man ikke få noen feil i det hele tatt, eller så
vil man få svært synlige og hørbare feil.
Hvordan bildet ser ut har forøvrig ingen betydning; digitale signaler
kodes av tekniske årsaker på en slik måte at man får hyppige
bit-transisjoner uansett hvordan dataene faktisk ser ut. HDMI overfører
bilde og lyd med TMDS, som bruker en avansert algoritme for å holde
antall bit-transisjoner per byte nesten konstant. Et sjakkmønster vil
ikke være mer (eller mindre) følsomt for støy enn en helt hvit skjerm.
Forresten: siden det er snakk om Blu-Ray må man også ta HDCP med i
beregningen. HDCP-protokollen har en kryptografisk handshake som tar
noen brøkdeler av et sekund; ikke fryktelig lenge, men lenge nok til at
du merker det. Siden HDCP bruker et flytchiffer vil skjermen og
spilleren måtte gjennomføre en ny handshake hver gang signalet faller
ut. I mellomtiden vil spilleren enten ikke sende bilde i det hele tatt,
eller sende et bilde med sterkt nedsatt oppløsning.
DES
--
Dag-Erling Smørgrav - d...@des.no
Dag-Erling Smørgrav
> Man vil ikke få skurring, støy eller snø på skjermen; man vil få kutt
> i lyden, manglende oppdatering av deler av bildet, og lignende.
Jeg burde ha skrevet "spraking" i stedet for "skurring", da "skurring"
er en ganske god beskrivelse av noen av artefaktene man kan få når
f.eks. et GSM-signal begynner å falle ut.
Dag-Erling Smørgrav
> Dette er ikke korrekt. Det finnes terskelverdier og toleransegrenser,
> og det finnes annen kvalitetsforringelse enn tap av data. Det finnes
> ingen feilkorrigering i ordets rette forstand, da det er litt ugreit å
> få tid når tid og sekvens er av helt avgjørende betydning.
Jeg kan ikke se at det skulle utelukke feilkorrigering. Såvidt meg
bekjent har f.eks. de fleste mobiltelefonprotokoller ganske sterk
feilkorrigering.
Harald Ljøen
Det er ganske avansert feilkorrigering på CD-plater, en standard som nå
er 30 år gammel, så det ville forundre meg om det ikke er
feilkorrigering over HDMI også. Men jeg kjenner ikke detaljene i den
protokollen.
Det å "få tid" til feilkorrigering er bare snakk om å legge inn nok
tidsforsinkelse, noe som er helt uproblematisk i avspillere
(enveissystemer). Jitter er noe som oppstår i senderen, og har null og
niks med kabelkvaliteten å gjøre. Og jitter er heller ikke vanskelig å
eliminere på mottakersiden, men trenger i prinsippet bare en buffer, noe
man allerede har om man har feilkorrigering.
Thomas Lundquist
>> Altså; at kabelkvalitet har en del å si på lange strekk og høye bitrater
>> er rimelig åpenbart.
>
> Ja, og det er jo nettopp det jeg har påpekt, og ikke noe annet. Mens
> du temmelig kategorisk kalte det "snake oil" å kjøpe noe annet enn det
> aller billigste.
Jeg har da ikke forfekta at prisen har ikkeno å si men det jeg sier er
at når de virker så virker de, det er ikke snakk om "klarere farger" men
"ingen artifakter".
>> Den ene diskusjonen var om å kjøre HDMI igjennom receiveren istedenfor
>> direkte og s/pdif til receiveren hadde noe å si lydmessig. Du påstod
>> hardnakket det.
>
> Aner ikke hva du snakker om her.
Sikkert like greit.
(Det var en diskusjon i et anna forum)
Thomas Lundquist
> Ok, jeg skal gi EZ litt slækk, han rodde som et helvete og mente etter
> hvert i diskusjonen at "synlige bitfeil" falt innenfor definisjonen av
> "virker ikke". Hva han mener om "ikke fullt så åpenbare bitfeil", som
> av enkle årsaker er nødt til å forekomme og forårsake generell
> degradering av kvaliteten aner jeg ikke, jeg ga opp før den tid, da
> jeg fikk følelsen av å diskutere religion med en muslim.
> ;-)
Det var ikke roing, det var å påpeke hva jeg mente med "ikke virker" da
jeg trodde det var åpenbart at artifakter betydde at ting ikke funka.
Ditto med lydkabler, der er det vel stort sett stillhet og bobling man
kan oppleve (personlig har jeg aldri opplev noe anna enn stillhet når
"ikke virker" slår inn på både lyd og bildekabel men det er jo åpenbart
at med dårlig digitalkabel kan gi artifakter om protokollen er designet
til å gi slikt og ikke blank skjerm ved bitfeil.
> Nuvel, når du stikker innom EZ, kan du ikke ta med deg din 10M kabel
> til 160 spenn, så kobler vi den opp her og sammenligner med min (meget
> rimelige) 15 meter kabel til Kr. 2000 på pixel-sjakkmønster. Blir
> spennende!
Det kan jeg teste hjemme også, og det er jo fremdeles enkelt; Enten
virker det eller så virker det ikke.
Og oddsa for at den billigste kabelen ikke virker er jo såklart høyest
men det er ikke automatisk gitt at den ikke gjør jobben sin.
Thomas Lundquist
> Det er litt sent å rette en feil etter at tonen er spilt, hva?
> Det eneste som kan rettes er det som ligger i buffer, og det er svært
> begrenset i tid. Protokollene for feilretting er også temmelig basic.
Definisjonsspørsmål, en CD-plate var laget for lyd men alikevel har den
en rimelig heftig feilkorrigering, så heftig at Philips demonstrerte den
ved å teipe over deler av CDen uten at det hadde effekt.
Dette var tidlig, da man overdrev hardt på all engineering rundt CDen,
etterhvert fikk man drivverk til 1/100 av prisen som ikke klarte et
støvkorn engang.
> "ganske sterk", i betydning hva da?
> Noen forsinkelse verdt å snakke om er ikke akseptabelt, dermed kan man
> heller ikke ha noen feilkorrigering som kan betegnes som "ganske
> sterk".
Det brukes omtrent ikkeno av en mobiltelefons prosessorkraft til å ha
"ganske sterk" feilkorrigering uten merkbar tidsforsinkelse. Latency har
man mer av i nettet.
Men det er jo bare å lese standarden, for de som gidder.
> Man kan jo kun rette det som ennå ikke er konvertert til
> analoge signaler, og det er nødvendigvis de digitale data som er
> mottatt og ligger i buffer. Lite buffer. Lite tid (nær sanntid).
> Begrenset resultat.
Såklart men når man egentlig har båndbredde og prosessorkraft til å ha
en viss feilkorrigering så kan det hende man velger det.
Uten at jeg er så sikker på om jeg hadde ønsket det eller sett poenget.
Dag-Erling Smørgrav
> Dag-Erling Smørgrav <d...@des.no> writes:
> > Såvidt meg bekjent har f.eks. de fleste mobiltelefonprotokoller
> > ganske sterk feilkorrigering.
> Noen forsinkelse verdt å snakke om er ikke akseptabelt, dermed kan man
> heller ikke ha noen feilkorrigering som kan betegnes som "ganske
> sterk".
Jo, det kan man. Man kan faktisk ha "ganske sterk" feilkorreksjon helt
uten forsinkelse ved å legge redundans inn i signalet, og det fungerer
som du sikkert vet glimrende (jeg regner med at du har mobiltelefon).
Jeg husker ikke hva GSM bruker, men hvis vi går tilbake til kobber så
bruker Ethernet 4b5b (25% redundans) for 100BASE-TX og 2b3b (50%
redundans) for 1000BASE-T. Jeg tror HDMI bruker 8b10b (25% redundans)
på linklaget.
Harald Ljøen
> Harald Ljøen's keyboard suddenly auto-typed:
>
>> Det å "få tid" til feilkorrigering er bare snakk om å legge inn nok
>> tidsforsinkelse, noe som er helt uproblematisk i avspillere
>> (enveissystemer). Jitter er noe som oppstår i senderen, og har null og
>> niks med kabelkvaliteten å gjøre. Og jitter er heller ikke vanskelig å
>> eliminere på mottakersiden, men trenger i prinsippet bare en buffer, noe
>> man allerede har om man har feilkorrigering.
>
> littegrann.
>
Hva mener du var feil i det jeg skrev over?
Morten Leikvoll
> Dag-Erling Smørgrav's keyboard suddenly auto-typed:
>
>>Konsekvensene av forstyrrelser av et digitalt signal, uansett hva slags
>>signal det er snakk om, er veldig forskjellige fra konsekvensene av
>>forstyrrelser av et analogt signal. Man vil ikke få skurring, støy
>>eller snø på skjermen; man vil få kutt i lyden, manglende oppdatering av
>>deler av bildet, og lignende.
>
> digitaleoverføringer: tid.
>
> Man vil kunne få overført for lite informasjon, og man kan meget vel
> få overført gal informasjon, jitter. Ofte på grunn av
> timingproblematikk.
>
>>Det ikke er snakk om noen gradvis
>>forringelse:
>
> av jitter, og i form av manglende eller gal informasjon. Det trenger
> slettes ikke å være spesialt synlig i form av bitfeil. Dette er en
> utbredt myte.
>
>>enten vil man ikke få noen feil i det hele tatt, eller så
>>vil man få svært synlige og hørbare feil.
>
> og det finnes annen kvalitetsforringelse enn tap av data. Det finnes
> ingen feilkorrigering i ordets rette forstand, da det er litt ugreit å
> få tid når tid og sekvens er av helt avgjørende betydning.
Det er riktig i denne sammenheng at digitalfeil på HDMI kan komme gradvis,
og tilogmed være så liten at den ikke merkes med det blotte øyet.
For andre digitale signaler som er pakket i pakker og lagt sammen med
korrigeringsbits (f.eks NICAM lyd eller div MPEG streams) så vil en feil
enten bli korrigert eller du får et fatalt resultat i form av pakketap, og
pakketap HØRER og SER du. HDMI er veldig lite robust mot digital støy, da
dette er et ganske rått signal. Det er ingen pakker involvert, faktisk ikke
sjekksum engang, i bildet ihvertfall. En og en pixel kan feile en gang i
blandt.
Morten Leikvoll
news:ipmud3$955$1...@dont-email.me...
> Det er ganske avansert feilkorrigering på CD-plater, en standard som nå er
> 30 år gammel, så det ville forundre meg om det ikke er feilkorrigering
> over HDMI også. Men jeg kjenner ikke detaljene i den protokollen.
CD plater hadde originalt ikke feilkorrigering. Dette skjedde med digitale
eller analoge filtre. Senere når CD platen ble tatt i bruk til lagring av
data så kom det nye rå-formater som hadde massevis med korreksjonsbits. De
blandet også bits slik at en skrape i CDen ikke skulle ødelegge
sammenhengende data, men heller litt her og der, slik at sannsynligheten for
at korrigering ble riktig ble større.
HDMI (8bits format) har en slagt 8/10 bits format omformer på senderen (og
motsatt på mottaker), men denne er ikke feilkorrigerende. Den kan oppdage
litt feil, men det er ingenting som sier hva som skal skje når en feil
oppdages. Denne 8-10 bit oppslaget er rett å slett en oppslagstabell for å
holde elektromagnetisk interferens nede (Se
http://en.wikipedia.org/wiki/Transition_Minimized_Differential_Signaling ).
Hadde de vært så lure å kjøre f.eks mpeg pakker over hdmi kabelen, så hadde
systemet vært mye mer robust, men da blir det straks et signal som ikke er
loss-less. For DVD'er burde de kanskje gjort dette og latt TV'en dekode
istede for.
Harald Ljøen
> CD plater hadde originalt ikke feilkorrigering. Dette skjedde med digitale
> eller analoge filtre.
Den originale Audio CD-standarden spesifiserer at det brukes CIRC
(cross-interleaved Reed-Solomon code) for feilkorrigering. Se f eks her:
http://www.usna.edu/Users/math/wdj/reed-sol.htm
At de fleste spillere (iallfall i begynnelsen) ikke utnyttet dette fullt
ut er en helt annen sak.
Dag-Erling Smørgrav
> Om feilkorrigering på lydsiden:
> "The behavior of the Sink after detecting an error is
> implementation-dependent. However, Sinks
> should be designed to prevent loud spurious noises from being
> generated due to errors. Sample
> repetition and interpolation are well known concealment techniques and
> are recommended. "
Sjekk linklaget.
Thomas Lundquist
> Dag-Erling Smørgrav's keyboard suddenly auto-typed:
>
>>Jeg tror HDMI bruker 8b10b (25% redundans)
>>på linklaget.
>
> Det tror jeg absolutt ikke.
Vel, jeg fant ikke 8b10b nevnt i standarddokumentet men
Wikipediaartikkelen har dette nevnt i båndbreddetabellen sin.
http://en.wikipedia.org/wiki/HDMI#Version_1.4
Så kan man stole på Wikipedia eller ei, jeg brukte en dårlig pdf-leser
uten søkefunksjon (teit unnskyldning, ja)
Men det hjelper jo ikke med ECC fra himmelen om mottager ikke bruker
dataene til å rette opp feilene. Mottager kan dog lett se at det *er*
overføringsfeil og dermed kan man greit teste kvaliteten på kabel.
Om man har utstyr som gidder å telle slikt.
> Du finner full spec her:
> http://www.hdmi.org/download/HDMI_Spec_1.3_GM1.pdf
> Det er riktignok både TERC4 og ECC i standarden generelt, men effekten
> avhenger selvfølgelig av bufferstørrelse og prosesseringskapasitet i
> kombinasjon med forsinkelse.
Og ingen av delene har noe med kabelen å gjøre men med eventuell
kvalitet på utstyret som tar imot signalene.
Tenkte jeg skulle klippe ut relevante avsnitt fra standarden men
diskusjonstråden her
http://arstechnica.com/civis/viewtopic.php?f=6&t=275120&p=6271817
har gjort det allrede.
Som DES sier, skal HDCP fungere kan det ikke være mye bitfeil heller, da
vil ikke mottager eller sender godkjenne hverandre.
> Seriøse digital-audio-ingeniører fnyser av minstekravene i
> HDMI-standarden, og hevder rimelig unisont at den er betydelig mer
> bedriten enn S/PDIF. Og når det gjelder sistnevnte er det svært mange
> som lever av å lage digital signalering som mener at konstruktørene
> burde vært pisket og hengt på torvet i nærmeste by, i full
> offentlighet.
Det at dette i det hele tatt diskuteres er grunnet en av to ting:
Kabelprodusenter som ønsker å spre FUD så godtroende kunder bruker
tusenvis av spenn på unødvendige kabler
eller
Idioter som lager standarden.
Leser man en del om standarden er svaret "Begge deler". Det å pøse
10Gbit igjennom en kabel på 15m er peanøtter for de som veit hva de
driver med, både coax og TP (Cat6) og kablene er bøttebillige.
Med Cat6a får man 10Gbit opptil 100m.
Og kom ikke å si at man godtar datatap i et slikt nettverk.
Det som ble diskutert før DVI ble en standard var å bruke SDI, det hadde
vært mye mye bedre.
Men alikevel er det som ble valgt bra nok men ikke godt nok til at
FUD kan spres.
> Samtidig er det mer enn nok folk som aldri har gjort
> annet enn digital-signalering som mener at audio-folk med analog
> bakgrunn skal holde seg laaangt unna alt som er digital, for det
> skjønner de ikke.
Det analogfolka ikke skjønner er at lyd og bilde er data som alt
anna. Ja, det er et høyt krav til latency men det forstår digitalfolk
seg på også.
Så hadde man brukt dem til transporten kunne analogfolka tatt for seg
lagene ovenfor.
> Og omvendt. Ikke godt å si, så jeg behandler enhver
> bastant ekstremist på begge sider med den aller største skepsis.
Det som er greit med disse diskusjonene er at det er mye vitenskap gjort
rundt dette allrede og det er lett å måle.
Harald Ljøen
> standarden er.
Står det noe om HDMI standarden der?
Det var en generell kommentar til dekoding av analoge signaler fra en
digital kilde, noe jeg oppfatter at du skjønt lite av etter å ha lest bl
a følgende fra dine fingre:
Dag-Erling Smørgrav
> Å si at det er 25% redundans er jo _fullstendig_ galt,
nei
> da du dermed
> sier at du kan miste 25% av dataene uten at det får noen som helst
> konsekvens.
nei
> Det kan du så absolutt ikke med den type koding!
stemmer
> Det du kanskje mente å si er at det er 25% overhead. Det ville ha vært
> korrekt.
nei
> Det ville ha vært
> korrekt.
nei
> Det er ikke det samme som redundans.
stemmer
Dag-Erling Smørgrav
> Bare så vi har det helt klart for oss: Koding av et 4-bits signal med
> 5 bits er IKKE sterk feilkorrigering, det er helt grunnleggende, og
> gir begrenset effekt.
Jeg glemte meg litt bort, 4b5b gir ingen feilkorreksjon, men 8b10b kan
korrigere 1 bit og oppdage 2. Hvis koden er lineær er sannsynligheten
for en uoppdaget feil 2.78e-17 og sannsynligheten for en ukorrigerbar
feil 1.04e-14.
Dag-Erling Smørgrav
> Jeg glemte meg litt bort, 4b5b gir ingen feilkorreksjon, men 8b10b kan
> korrigere 1 bit og oppdage 2. Hvis koden er lineær er sannsynligheten
> for en uoppdaget feil 2.78e-17 og sannsynligheten for en ukorrigerbar
> feil 1.04e-14.
...og nå ble jeg plutselig usikker på om feilkorreksjonskoder i det hele
tatt er lineære...
Morten Leikvoll
news:lxliynm...@castle.zelow.no...
> Som DES sier, skal HDCP fungere kan det ikke være mye bitfeil heller, da
> vil ikke mottager eller sender godkjenne hverandre.
HDCP har faktisk lite å si her. Den arbeider på relativt lav båndbredde over
i2c bussen og sender bare et sett keys som blir brukt til å blande bits
riktig. En feil i en pixel blir en feil på skjermen enten hdcp er koblet inn
eller ei.
Dersom noe går galt i HDCP handshaken vil bilde forsvinne helt. De 2 trådene
som i2c bussen går over er ikke de som feiler først.
Morten Leikvoll
"Dag-Erling Smørgrav" <d...@des.no> wrote in message
news:86ei4ft...@ds4.des.no...
>Jeg glemte meg litt bort, 4b5b gir ingen feilkorreksjon, men 8b10b kan
>korrigere 1 bit og oppdage 2. Hvis koden er lineær er sannsynligheten
>for en uoppdaget feil 2.78e-17 og sannsynligheten for en ukorrigerbar
>feil 1.04e-14.
Men merk at den 8b10b koden som brukes i HDMI har ingen korreksjonsmulighet.
Les om TDMI på wiki.
Thomas Lundquist
> JO, det kommer jeg og sier. Fordi man har feilkorrigering som kan
> håndtere det uten konsekvens for det bruksområdet. Det er ikke like
> enkelt når alle bitene må komme frem i riktig rekkefølge, til riktig
> tid.
Man godtar fremdeles ikke datatap, man sørge for at eventuelle tap
håndteres. Det er veldig uvanlig med tap på Ethernet i disse dager.
> Ikke kom er og si at du *virkelig* får 10Gbit med data overført på en
> 100M Cat6a, pent og pyntelig linet opp i riktig rekkefølge, og uten
> noen som helst forskjell i overføringstid.
Jeg har ikke gjort tester (har ikke utstyr for hverken 10Gbit eller
tester) men poenget mitt her er at det faktisk er en standard for dette,
det er ikke uvanlig å få oppimot 90% throughput på spesifisert
ethernet-hastighet og det er nærme nok for denne diskusjonen.
Thomas Lundquist
> HDCP har faktisk lite å si her. Den arbeider på relativt lav båndbredde over
> i2c bussen og sender bare et sett keys som blir brukt til å blande bits
> riktig. En feil i en pixel blir en feil på skjermen enten hdcp er koblet inn
> eller ei.
Så selve datastrømmen går "ukryptert" og kan i prinsippet tappes.
Det er jo iofs interessant i seg selv.
Thomas Lundquist
> For øvrig er det i dag ingen digitale medier for lyd og bilde som har
> mulighet for retransmisjon, og siden feilkorrigeringsalgoritmene som
> er implementert er heller begrensede er det *i praksis* slik jeg sier
> (noe spissformulert); man kan ikke rette en feil etter at tonen er
> spilt.
Men hadde man ønsket det kunne man enkelt ha laget en slik mulighet, som
man hadde på CDen i sin tid.
> At det finnes tekniske løsninger skjønner jeg utmerket godt, men det
> er helt på siden av poenget siden de ikke eksisterer i praksis.
> Sannsynligvis av svært gode grunner.
Ja, hadde det vært bombesikkert hadde ikke Monster & co tjent så fett.
Thomas Lundquist
> Men merk at den 8b10b koden som brukes i HDMI har ingen korreksjonsmulighet.
Imponerende, "Vi kan men vi vil ikke".
Dag-Erling Smørgrav
> "Morten Leikvoll" <mlei...@yahoo.nospam> writes:
> > HDCP har faktisk lite å si her. Den arbeider på relativt lav
> > båndbredde over i2c bussen og sender bare et sett keys som blir
> > brukt til å blande bits riktig. En feil i en pixel blir en feil på
> > skjermen enten hdcp er koblet inn eller ei.
> Så selve datastrømmen går "ukryptert" og kan i prinsippet tappes.
Nei, datastrømmen er kryptert med et flytchiffer. Det Morten sier er at
autentiseringen og nøkkelutvekslingen skjer over i2c.
Thomas Lundquist
> Djeezez...
>
> Ja, på et nettverk hvor retransmisjon er en opsjon kan man håndtere
> datatap. Audio/video er _ikke_ slike nett.
*bitfeil*, ikke reine tap. Jeg burde nok presisere hardt i denne
diskusjonen. Bitfeil kan fikses med god ECC.
Vi snakker tross alt om definisjonen av "ikke virker", med datatap er
det åpenbart at det vil være godt synlige feil på skjermbildet og
"ikke virker" er passende.
>>Det er veldig uvanlig med tap på Ethernet i disse dager.
>
> Seriøst: det er tøv og tull. Når du begynner å kjøre opp mot de
> virkelige grensene får du _mye_ retransmisjoner.
Det kan hende man kan få til det men hvor ofte er man oppe i disse
grensene? Sjeldent og enda mere sjeldent når lyd og bilde skal
overføres.
> Nå har du røyka noe som er fryktelig festlig. For du mener ikke i
> fullt alvor at du faktisk får dytta 900 Mb/s med data over et gigiabit
> nettverk? Eller 90 Mb/s på et 100 Mb/s nett?
Husk vi snakker punkt-til-punkt og ikke via switcher. En vesentlig
forskjell.
> Det må du i så fall vise meg for at jeg skal være i nærheten av å tro
> deg, siden all normal erfaring sier at du neppe klarer mer enn 60%.
For over ti år siden fikk jeg 80-88Mbit mellom to simple PCer. Det var
100Mbit nett.
Men jeg skal se om jeg får testa Gbit nett også.
Thomas Lundquist
>>Men hadde man ønsket det kunne man enkelt ha laget en slik mulighet, som
>>man hadde på CDen i sin tid.
>
> Man har da aldri hatt mulighet for retransmisjon på audio CD?
Retransmisjon er ikke hva man snakker om men reparasjon av bitfeil, aka
ECC. Ethernet har heller ikke retransmisjon, da må man lenger opp i
lagene.
(Ethernet har retransmisjon ved kollision men det er en helt anna sak,
da må jo flere enheter være koblet til og HDMI er ikke et nett alikevel)
> Jeg håper og tror at du for lenge siden har skjønt at jeg ler meg
> fillete av overprisede digitalkabler.
Ja, jeg tror ikke du går på jallaspeak.
> Derimot er jeg samtidig dypt uenig i at aller billigst er godt nok,
> særlig på lange strekk. All teori, og all erfaring sier nemlig at det
> ikke er særlig smart å gå den veien.
Og jeg sier at du kan ha rett men at det er enkelt å se om det funker
eller ei.
Thomas Lundquist
> Jeg garanterer deg at du kan kjøpe et par av CD-spiller og forsterker
> som garantert ikke mister en eneste bit i overføringen mellom CD og
> høyttalerutgang om du vil det. Men du vil sannsynligvis ikke akseptere
> prisen, og heller velge å kalle den "snake oil".
Å klare å la vær å miste bit er ikke å dra til månen, CD-lyd er ekstremt
lav bitrate og med god nok design trenger ikke prisen å være høy heller.
Dag-Erling Smørgrav
> Dag-Erling Smørgrav's keyboard suddenly auto-typed:> Neivel. Fordi?
Enkel prosentregning. 1 bit redundans per 4 informasjon = 25%.
> > > Det du kanskje mente å si er at det er 25% overhead. Det ville ha vært
> > > korrekt.
> > nei
> "Nei", hva da?
Enkel prosentregning. 1 bit overhead per 5 overførte bit = 20%
Dag-Erling Smørgrav
Nei. Dette er helt elementær kodeteori. En 4b5b-kode, eller hvilken
som helst annen kode med kun 1 redundant bit, kan oppdage 1-bit-feil,
men gir ingenting om *hvilket* bit som er feil.
> > men 8b10b kan korrigere 1 bit og oppdage 2.
> Det er totalt verdiløst å oppdage en bitfeil man ikke kan korrigere
> (retransmisjon). Å korrigere én bit pr. pakke er heller ikke særlig
> nyttig.
Motsier du ikke det du nettopp skrev om 4b5b?
> > Hvis koden er lineær er sannsynligheten for en uoppdaget feil
> > 2.78e-17 og sannsynligheten for en ukorrigerbar feil 1.04e-14.
> Jasså? Foreslår at du setter opp det matematiske uttsrykket som
> beviser den påstanden.
"textbook material", som det heter. Man summerer vektfordelingen til
koden for alle Hamming-avstander fra 2 til 10 og setter inn feilraten
til overføringsmediet, som jeg glemte å spesifisere - jeg regnet med
10e-3, som er svært pessimistisk.
Referanser:
MacWilliams, F. J. “A theorem on the distribution of weights in a
systematic code.” Bell Systems Technical Journal 42, no. 1 (January
1963): 79-94.
Chang, S. C., and K. J. Wolf. “A Simple Derivation of the MacWilliams’
Identity for Linear Codes.” IEEE Transactions on Information Theory
IT-26, no. 4 (July 1980): 476-477.
Wolf, J. K., A. M. Michelson, and A. H. Levesque. “On the Probability of
Undetected Error for Linear Block Codes.” IEEE Transactions on
Communications COM-30, no. 2 (February 1982): 317-324.
Dag-Erling Smørgrav
> Du mener ikke seriøst at GSM er et eksempel på god lydkvalitet, og bra
> feilkorrigering?
Det er et eksempel på fungerende feilkorrigering. Lydkvaliteten har
ingenting med saken å gjøre, den er en funksjon av lydkodeken som
brukes, som har lavt dynamikkomfang og lav bitrate. Skulle man
redesignet GSM fra bunnen med dagens radioteknologi hadde man nok valgt
en kodek med bedre lydkvalitet.
> > men hvis vi går tilbake til kobber så bruker Ethernet 4b5b (25%
> > redundans)
> I praksis vil den type basic CRC gi noen få prosent feilkorrigering,
Nå er det tilfeldigvis slik at 1-bit paritet - hvis jeg husker riktig -
tilsvarer en 1-bit CRC-kode med generatorpolynom x + 1, men det omtales
normalt ikke som en CRC-kode, og CRC-koder er ikke feilkorreksjonskoder.
Dag-Erling Smørgrav
> Ethernet har retransmisjon ved kollision
Kollisjoner eksisterer ikke i svitsjet Ethernet, siden det ikke er et
delt medium. Er det noen som fortsatt bruker huber?
Morten Leikvoll
> "Morten Leikvoll" <mlei...@yahoo.nospam> writes:
>
>> HDCP har faktisk lite å si her. Den arbeider på relativt lav båndbredde
>> over
>> i2c bussen og sender bare et sett keys som blir brukt til å blande bits
>> riktig. En feil i en pixel blir en feil på skjermen enten hdcp er koblet
>> inn
>> eller ei.
>
> Så selve datastrømmen går "ukryptert" og kan i prinsippet tappes.
>
> Det er jo iofs interessant i seg selv.
Den er kryptert, men på en måte som gjør at en feil i EN kryptert pixel (og
faktisk farge innenfor pixelen) forblir feil i den ene og samme pixel etter
dekryptering.
Morten Leikvoll
> "Morten Leikvoll" <mlei...@yahoo.nospam> writes:
>
>> Men merk at den 8b10b koden som brukes i HDMI har ingen
>> korreksjonsmulighet.
>
> Imponerende, "Vi kan men vi vil ikke".
De kan, men da mister de den opprinnelige funksjonen med dagens 8-10bit
konvertering.
Merk også at det er definert to spesielle 10bit mønster som sier at dette er
ikke en pixel, men et spesial/kontrollsignal. Disse kontrollsignalet
inneholder H og V synk på en av trådparene, og noe annet på de to andre
fargene (les om CTL signalene på HDMI spec om du er interessert), så
effektivt får du en smule mer enn 8bit overføring.
Morten Leikvoll
> Man har da aldri hatt mulighet for retransmisjon på audio CD?
*pirke*
Det er da lett å lese et spor omigjen på en CD/DVD..:p Men man trenger lang
buffer og/eller rask søketid. Det var dyrt på 80 tallet, nå er det nesten
gratis. Men for å kunne lese om igjen må man først kunne se at lesing gikk
galt.
Thomas Lundquist
> Thomas Lundquist <er...@zelow.no> writes:
>> Ethernet har retransmisjon ved kollision
>
> Kollisjoner eksisterer ikke i svitsjet Ethernet, siden det ikke er et
> delt medium. Er det noen som fortsatt bruker huber?
Det er jo i praksis, kollisjoner kan jo i teorien skje fremdeles.
ez
--
Med infrastruktur bygger vi landet.
Siteringsproblemer? : http://www.bersvendsen.com/usenet/quoting.html
Thomas Lundquist
> Den er kryptert, men på en måte som gjør at en feil i EN kryptert pixel (og
> faktisk farge innenfor pixelen) forblir feil i den ene og samme pixel etter
> dekryptering.
KAS er jo så redd for latency, kryptering og dekryptering må da legge
til latency så det holder?
Terje Kvernes
> Kollisjoner eksisterer ikke i svitsjet Ethernet, siden det ikke er
> et delt medium. Er det noen som fortsatt bruker huber?
Du vil ikke tro hva du kan finne i gamle kott på gamle bygg. Det
vanskeligste er ofte å finne de -- rent fysisk. Det å måtte gjette på
rom basert på antatt avstand på kablene er ganske latterlig, men gir
mange morsomme skattejakter.
Vel, i den graden man kan kalle det man finner en "skatt".
--
Terje
Dag-Erling Smørgrav
> Dag-Erling Smørgrav <d...@des.no> writes:
> > Kollisjoner eksisterer ikke i svitsjet Ethernet, siden det ikke er
> > et delt medium. Er det noen som fortsatt bruker huber?
> Det er jo i praksis, kollisjoner kan jo i teorien skje fremdeles.
Nei. Kollisjoner er ikke mulig i svitsjet Ethernet. 10BASE-T og
100BASE-TX bruker et trådpar for hver retning, mens 1000BASE-T kjører
full dupleks på alle fire trådpar (dvs. at begge parter sender samtidig
på samme trådpar).
Dag-Erling Smørgrav
> > > Du mener ikke seriøst at GSM er et eksempel på god lydkvalitet, og
> > > bra feilkorrigering?
> > Det er et eksempel på fungerende feilkorrigering.
*sukk*
Du er tydeligvis ikke interessert i en saklig diskusjon.
> > Lydkvaliteten har ingenting med saken å gjøre
> Jo, når du våger å sammenligne med noe som ikke er sammenlignbart. Du
> viste til et eksempel (mobiltelefoni), som et bevis på at det lar seg
> gjøre. Ja, men med helt andre forutsetninger. Ikke relevant.
Se over.
Thomas Lundquist
>>Å klare å la vær å miste bit er ikke å dra til månen, CD-lyd er ekstremt
>>lav bitrate og med god nok design trenger ikke prisen å være høy heller.
>
> Neida, men hvem vil vel lage et nytt CD-format nå? Det er jo dømt til
> å mislykkes.
Jeg tenkte ikke på nytt CD-format, jeg tenkte på det eksisterende.
> Man har forsøkt med SACD (bedre feilkorrigering der?),
> DVD-A og nå BluRay. Ingen av dem har vell akkurat klart å erstatte den
> gamle CD'en...
Kan man trygt si.
Thomas Lundquist
> Thomas Lundquist <er...@zelow.no> writes:
>> Det er jo i praksis, kollisjoner kan jo i teorien skje fremdeles.
>
> Nei. Kollisjoner er ikke mulig i svitsjet Ethernet. 10BASE-T og
> 100BASE-TX bruker et trådpar for hver retning, mens 1000BASE-T kjører
> full dupleks på alle fire trådpar (dvs. at begge parter sender samtidig
> på samme trådpar).
Sorry, burde hatt med en "om man skulle klare å finne en HUB".
Derav teorien.
På den andre siden, switchen kan vel settes opp til å speile alle eller
noen porter og da kan man vel, også i teorien kunne oppleve kollisjoner?
Typisk; "Jeg VIL være dust og ha kollisjoner".
Thomas Lundquist
>>Retransmisjon er ikke hva man snakker om men reparasjon av bitfeil,
>
> Jeg vet det, poenget er at når man ikke kan reparere med ECC type
> feilkorrigering må man ty til retransmisjon, eller la data gå tapt.
Det er jo innlysende.
Hvilke data som går tapt er rimelig tilfeldig, hver sjette pakke for
eksempel, er praktisk talt umulig og skal det skje er det ikke i kabel
men i enhetene. Så teorien din om at man kun kan ha "skade" på
luminansen er tvilsom.
Hadde det vært en leder per fargekanal som i gamle dager ville det
såklart vært ei anna sak.
> Spiller ingen rolle i denne sammenheng hvilket lag som gjør det, men
> hva som er mulig og hva resultatet er.
At retransmisjon er lite hensiktsmessig er vi enige om, at
feilkorreksjon kan fungere er vi uenige om. Jeg mener det er fullt mulgi
å få til all den tid man allrede tillater latency på kryptering og fjas.
Det er tross alt snakk om å sende både lyd og bilde samtidig, iallefall
i en del av strekket. Da er ikke sync noe problem og om seer opplever å
se filmen en liten stund etter at den ble sendt fra skiva betyr null og
niks. "En liten stund" måles i millisekunder uansett.
Så har man det at lyden gjerne stopper i receiveren mens bildet blir
dytta videre til projektor/TV. Selv med dagens HDMI har man også
latency-issues på grunn av at videosignalet bruker god tid igjennom
alle de forskjellige prosesseringene i TV eller projektoren. Tiden
feilkorreksjon ville lagt til er neglisjerbar.
HDMI av idag har, såvidt jeg veit, ingen protokoll for at receiver kan
spørre videofremviseren hvor lang tid den bruker på å få igjennom
signalet, både kabel, dekoding, de-interlacing om man har slikt og andre
bildeprosesseringsgreier.
Det kunne man kanskje løst med at mikrofonen som vanlivis følger med
utstyret også kunne inneholdt et kamera eller noe lysfølsomt så man
kunne måle og kalibrere på samme måte som man gjør med lyd idag.
Og da er vi tilbake til at man ikke trenger å bekymre seg for
tidsaspektet i samme grad som du er opptatt av. Retransmisjon kan til og
med bakes inn om man vil, uten at jeg er sikker på at det er no vits
overhodet og da må vi snakke om ett til to sekunder latency for å være
på den bombesikre siden.
Så jeg holder på at HDMI er dårlig designet og at påstandene om at
digitalfolk ikke vil kunne designe et slikt overføringssystem er bambus.
Men ikke hvemsomhelst.
Nå fikk jeg lyst til å rante om XML-baserte "protokoller" i
dataverdenen, der finnes det nærmest ingen unntak fra regelen at det er
idioter som lager dem.
Morten Leikvoll
"Dag-Erling Smørgrav" <d...@des.no> wrote in message
news:867ha5s...@ds4.des.no...
>Kollisjoner eksisterer ikke i svitsjet Ethernet, siden det ikke er et
>delt medium. Er det noen som fortsatt bruker huber?
Bare for å dra denne tråden ut enda lenger.. ;)
Kollisjonene skjer nok mer på digitalt nivå i form av overflow i switchene,
der pakker må kastes.
Også siden dette er et medium der det er retransmisjon, så går en del av
effek bort der
Thomas Bjørseth
wrote:
>På den andre siden, switchen kan vel settes opp til å speile alle eller
>noen porter og da kan man vel, også i teorien kunne oppleve kollisjoner?
Speiling av switcheporter er noe man som regel gjør for å
sniffe/analysere trafikk, og ikke noe man vil gjøre for å "emulere" en
hub og dermed utvide kollisjonsdomenet. I praksis vil speiling av en
port eller to ikke medføre kollisjoner av nevneverdig omfang, fordi
den nye speilporten ofte kun lytter uten å sende særlig trafikk
tilbake til den speilede porten.
Thomas B
Thomas Lundquist
> Speiling av switcheporter er noe man som regel gjør for å
> sniffe/analysere trafikk, og ikke noe man vil gjøre for å "emulere" en
> hub og dermed utvide kollisjonsdomenet. I praksis vil speiling av en
> port eller to ikke medføre kollisjoner av nevneverdig omfang, fordi
> den nye speilporten ofte kun lytter uten å sende særlig trafikk
> tilbake til den speilede porten.
Jeg vil være dust! Jeg vil leke gamledager!
:P
(Ja, jeg er såpass bevandra i nettverk til at jeg visste dette.)
ez
--
DoD#3098, DoDRT#02, DoDCT#012, 066, SUCKS#012, NIC#03, SDK#1528, AMO#209sjef
'97 Ducati ST2(Greven), '96 Honda GOOF3(Singer), '00 CBR900RR(Pfaff)
'99 Mercedes Vito 112CDi (Nimitz)
Siteringsutfordringer? : http://www.bersvendsen.com/usenet/quoting.html
Dag-Erling Smørgrav
> > 100BASE-TX bruker et trådpar for hver retning, mens 1000BASE-T kjører
> > full dupleks på alle fire trådpar (dvs. at begge parter sender samtidig
> > på samme trådpar).
> Sorry, burde hatt med en "om man skulle klare å finne en HUB".
Du la kanskje ikke merke til at jeg skrev "svitsjet"? :)
> På den andre siden, switchen kan vel settes opp til å speile alle
> eller noen porter og da kan man vel, også i teorien kunne oppleve
> kollisjoner?
Nei, det er ingen kollisjoner ved bridging heller. Det er fortsatt bare
en node i hver ende av kabelen.
Dag-Erling Smørgrav
> Kollisjonene skjer nok mer på digitalt nivå i form av overflow i switchene,
> der pakker må kastes.
Det er ikke kollisjoner, det er congestion (finnes det noe godt norsk
ord for dette?)
> Også siden dette er et medium der det er retransmisjon, så går en del av
> effek bort der
Det finnes ikke retransmisjoner i Ethernet-protokollen. Enten så kommer
pakken frem, eller så blir den borte. Om retransmisjon er ønskelig,
implementeres det i høyere protokollag.
Harald Ljøen
> congestion (finnes det noe godt norsk ord for dette?)
Trengsel.