Xmos DSP

[lilltroll]

Åhhh vad livet blev enklare nu.

Dessa j*vla OS-drivare och sen Windows dll:er till 87 olika versioner.

Ethernet, stöds av typ alla plattformar direkt i OSet. Har sockets i nästan alla programspråk, och om man kopplar direkt eller genom en switch så har man inte längre latency än över USB.
Dessutom har man nu standardiserat IEEE protokoll med tids sykronisering. (Funkar i alla fall över sladdburet)

Till min förvåning kunde jag skriva ett program med GUI i Windows som pratade med XMOS som jag ville på bara någon timme, och den kastade tillbaka data med över 25 Mbit/s, så det var min laptop som storknade som skulle FFTa resultatet.

Min gamle CS kompis skrev några rader i JAVA, och det funkade oxå.

En 100Mbit Ethernet Switch med 1Gbit backbone kan fås för 100kr numera, vilket är samma pris som en USB2.0 hub.

Att spela upp (streama) ljud är enkelt. Däremot så stödjer ju få prog. att man har ett Ethernet ljudkort än så länge.
Att TP kabeln dessutom slutar i en "äkta" signaltransformator gör också livet enklare när jord kan vara som den vill hos ljudkorts delen. USB-sladd kan annars kräva psuedo-diff ingångar på CODECen om man vill slippa jordloopar som hörs i ljudet.

Finns ett färdigt kit, men man får två huvudkort på köpet. Får väl skicka ett som kaffefilter till kaffekoppen. Om han får igång det så kan alla
Just Ethernet tror jag han är delvis bekant med.

[Piotr]

frågan kring bit-tapp vid volymreglering är ju också en fråga.

Precisionen på beräkningen av nya värden för PCM-samples är ju ordentligt hög med 32-64 bitar.

Kvantiseringsfelen bör ligga långt under hörtröskeln.

Adderas dither till signalen när den tas ner från säg 64 bit till 24 bit så elimineras den extremt låga kvantiseringsdistortionen.

Kvar är då frågan: Hör man ett adderat brus som ligger runt -140dBFS?

Jag gör det inte och hävdar att digital volymreglering är utan hörbara fel.

Faktum är att det mesta i musikväg har genomgått samma process en eller ett antal gånger redan vid mixning och/eller mastring.

Ett experiment man kan göra är att ta ett spår från en CD in i en audioeditor för att där addera 16 bit dither och sedan trunkera. Lyssna och jämför mot originalet.

Hör du inte detta brus är det inte sannolikt att du hör ett adderat brus som ligger 50dB under.


/Peter

[lilltroll]

Jo jag labbade lite med den bästa A/D jag hade kopplad till CODECen på XMOS kortet. Dvs när börjar beräkningsfelen bli detekterbara över allt annat skräp. De bästa CODECen som finns ligger väl runt 120-123 dB SNR, och då är man nere med motstånd under 250 ohm för att hålla det termiska bruset nere. Dessutom medelvärdes-bildar man de digitala från flera A/D för att minska brusnivåerna.

Dessutom körde jag över allt det XMOS beräknade till MATLAB för att analysera.

Däremot finns det många produkter som "räknar fel". Digitala IIR filter drabbas av kaosteorin, pga att differansekvationen som filtret beskriver är ickelinjär (pga trunkeringen), och uppfyller de andra villkoren för att bli kaotisk.

Så om det har funnit digitala EQ och annat ute på marknaden som man har tyckt låtit illa, och det faktiskt var så, så finns det matematiska bakgrunder till det.

TI införde ganska nyligen en DSP med högre flyttals-prec. för att just kunna skapa parametriska filter i basen med höga Q-värden.

Just i ett sådant exempel falierar flyttalen, nämligen vid subtraktion.

A-B som heltal blir exakt utan minsta fel. Om A bara är lite större än B, så blir flytals-beräkningen ofta oexakt, då färre bitar används till att beskriva "decimalerna".
Ett extremt exempel vore: (Tänk att du bara får använda 4 siffror i basen 10 för att spara talet)

1225-1224=1
minnet skulle alltså se ut som {1 2 2 5} - {1 2 2 4}

men 1.23*10^3 - 1.22*10^3 = 0.01 * 1000 = 10
minnet skulle alltså se ut som {3 1 2 3} - {3 1 2 2 }


Ett filter som ackumulerar ett sådant procentuellt stort fel spårar ur ögonblickligen.

Dvs flyttal är inte alltid bäst.

Detta fenomen kan enkelt skapas med single float och en bas EQ om fs är tillräckligt hög.

[lilltroll]

Verkar som diverse företag runt klotet håller på och filar, och det coola är att även om de AES krypterar sin kod så att man inte kan läsa den, så kan man programmera om den själv.

Det finns dock ett OTP minne (Där kodnyckeln lagras), så vill de förhindra egna mod, så måste man byta chippet , men vissa verkar sälja OEM lösningar som inte är låsta alls.


Ni som kan marknaden.

http://www.dsp4you.com/services/avb-streame

Den stora blaffan ser precis ut som ett XMOS G4 chip, och specen stämmer med den, och det verkar vara en 512BGA.
(Quad core 4x400 MHz)
Det tycks vara samma stöd för UTMI/ULPI USB2.0 (det icke monterade chippet och mini USB porten) och jag förmodar att det är samma MII Ethernet interface men det är svårt att läsa texten på chippen i bilden)

Dessutom har just XMOS ett öppet AVB bibliotek som jag satte och lekte med igår.

(AVB är så att man ska kunna skicka ljud genom ett Ethernet nätverk och inte behöva ett speciellt nät för ljudet)
Använder man gigabit portar istället verkar man kunna komma ner i latency på 300 us, vilket slår ASIO med hästlängder.
Ethernet får vara lastat med max x% för att man ska kunna garantera små fördröjningar, men med gigabitportar på datorn så kan man nog även titta på flera kanaler full-HD film utan problem parallellt.

[Piotr]

Dvs flyttal är inte alltid bäst.

Som jag förstått bör man upp på 64 bit flyttal för praktiskt bruk. Den DAW jag använder kör på 64 bit flyttal.

TI-chipet du nämner, vilken precision har det?


/Peter

[lilltroll]

Ja om jag inte missminner mig så hade den gamla matteprocessorn som kom till 386:an 80 bitars flyttal, dvs 16 bitar till exponenten och 64 bitar till decimalerna, och den delen lever sedan dess kvar i x86.
Men de snabbräknande vektor extension (som kom för några veckor sedan i nya Intel) och alla generationer med SSE instruktioner använder 64-bitar, även NVIDA använder 64 bitar i sina feta grafikkort.

Dessutom finns önskemålet om MAC med 3 operander, dvs man gör
A*B+C och därefter avrundar, inte round(A*B)+round(C), vilket också ska finnas i nya Intel.

Delar man upp filtret i andragradslänkar så kan man göra nästan allt med 64-bitars float om man ser till att använda de 64-bitarna rakt igenom.
EQ problemet kunde typiskt vara om man körde 64-bitar ljud * 32 bitars parametrar. (Man hinner åtminstone räkna dubbelt så mycket då, det är det som lockar), men det påverkar den ackumulerade precisionen.

Numera kan man välja bland många alternativ i TI's instruktionslista (på bekostnad av antalet operationer). OMAP familjen har en variant utan 3D men istället float DSP. DVS man får en liten ARM på köpet i samma chip, vilket kan vara trevligt om man vill ha t. ex ett web-gränssnitt att styra mot. Och priset är detsamma? som samma chip utan ARM9.

Någon här på faktiskt har lånat ut ett kort med OMAP innehållande C674x + CodeComposer, så det är den instruktionslistan jag svettats med.
Finns som öppen lågprisplattform http://www.hawkboard.org/
och även en lågpris JTAG som ska snurrar under "gratis" ver. av Code-Composer 4.x. Dessutom har TI släppt
http://hawkboard.wordpress.com/2010/10/ ... hawkboard/

Nu har jag ju labbat med nätverk under XMOS. Det funkar bra om man har ett begränsat antal samtidiga accesser, dvs kan kör inte en Apache webbserver med www.dn.se.
Med XMOS är mer tankesättet att man allokerar resurser på förhand för att garanterat hinna med uppgiften på utsatt tid. Ett OS däremot ligger alltid "efter", men kan iofs forsätta göra det ända tills det möjligtvis crashar. XMOS har sina 8 hårdvarutrådar per kärna, medan ett OS trådar av sig tills resurserna tagit slut eller någonting säger ifrån.

Att styra en magisk ljudlåda innebär ju typiskt att bara 1 klient ska vara inne och pilla samtidigt, så det är tämligen enkelt.

[lilltroll]

http://www.dsp4you.com/services/avb-streame

är baserad på XMOS. AVB lösningen är skyddad i OTP, men det är inte omöjligt att de kan tänka sig att även sälja öppna tomma kort.

Jag misstänker att det bygger på att man inte ska konkurrera inom samma område om marknaden, vilket innebär att de knappast kommer sälja de tomma korten på Ebay hur som helst.

[/url]

[lilltroll]

Fasen det kliar i fingrarna. Ca 1000 kr för ett kort som klarar upp till 16 mono-kanaler, (man får själv välja riktning) tex 8 duplex, eller 4 in och 12 ut. Styrt över 100 Mbit Ethernet, vilket är enkelt från MATLAB eller nästan alla andra språk.

Just nu har jag ingen Bootloader över Ethernet färdig, men det är på G, färdigt finns för SD kort.
Dvs hur gör man när man vill flasha koden på XMOS sidan. Ladda ner den över Ethernet är ju lättast, med ett SD kort med FAT16 klarar alla att hantera, och blir det strömavbrott mitt i så är det bara börja om.

Undrar om man ska skicka ett kaffefilter och se vad som händer.

[Crumboo]

Hur går det med det här?

[lilltroll]

Jag är uppe i 6 sidor schema nu (A4 skala 1:1)

Men nu har jag fått fnatt och fått för mig att SNR och T(H)D+N ska vara bättre och mångfaldigare än en MOTU Traveller MKIII låda*. (Ej inkluderat GUI:et) Där är jag än så länge otroligt självisk och tycker att va fan om du inte kan kompilera kodskelletet själv med de inställningar du önskar så ska du inte ens försöka)

Smartphones ger iofs en möjlighet att ändra på det. Din smartphone kan bli din avancerade fjärrkontroll och din ända kontroll mha av en "app".
Räkna dock att jag under frivilliga förhållanden kommer totalt skita i ixxx produkter, där man måste köpa en mac för att kunna kompilera till en App, och sedan lägga upp det till Appstore typ för att någon annan ska kunna ta del av det.

*Ungeför att THD<=110 dB @ 1kHz och DNR>120 dB [2-25kHz] vid 2V RMS.

[Morgan]

En liten bump på den här, i all välmenande nyfikenhet. Har det börjat växa fram en prototyp ännu?

[MagnusÖstberg]

Lilltroll kommer aldrig komma längre än till koden, ett GUI kommer aldrig han att skapa. Har funderingar på vem som kan fixa det...

[Crumboo]

Känns som det är läge för en BUMP nu igen väl? Hur går det?

[lilltroll]

Lilltroll kommer aldrig komma längre än till koden, ett GUI kommer aldrig han att skapa. Har funderingar på vem som kan fixa det...

Jag kan nog numera bevisa att du har fel på den punkten.

[PappaBas]

Tycker detta projekt ser mycket intressant ut

Hade det gått att ta fram ett grafiskt ramverk som gjorde det lätt att implementera olika filterfunktioner själv?
Tänker mig ett program med någon slags moduler så kan det ju fler användara samarbeta? Höjer man upp abstraktionsnivån så kommer fler att kunna deltaga för att man inte behöver uppfinna hjulet varje gång så att säga.

[petersteindl]

Intressant tråd

[MagnusÖstberg]

Mest intressant kanske den är eftersom Bremen knutit Lilltroll till sig