Xmos DSP

[lilltroll]

Jag skriver ju inte så ofta här längre, är moderator på ett engelskt forum gällande HW+SW av inbyggda system.

Min nyfikenhet gäller hur hardcore folk är numera här:

Är mini-DSP produkten med sitt GUI svår så ni svimmar ? Eller skulle ni vilja ha mer kraft, fler kanaler och kunna styra saker och modifiera koden själva.
Om vi kallar mini-DSP:n en Windows produkt - hur många skulle då våga sig på open source Linux ??

För några år sedan var det här fortfarande hokus-pokus hur i hel*ete man kunde bygga en egen produkt som man kunde koppla till PC:n och som dök upp i Windows. Men det gick o lära sig det med.

Det ni får, förutom några buggar som fortfarande är kvar är:

6 channel analog input, 8 channel analog output @ Supports sample rates - 44.1kHz, 48kHz, 88.2kHz, 96kHz, 176.4kHz, 192kHz 16-24 bitar med ASIO2.2 stöd under Windows, Mac och Linux över USB2.0
S/PDIF output and input via RCA or TOSLINK with high quality local PLL for clock recovery
MIDI I/O, Musical instrument/MIC compatible input, House clock input, I/O expansion

Det där är då som ljudkort när USB sladden är i. Sen kan den oxå fungera som valfri standalone moj, som t.ex kan konfigureras via ett Windows GUI. Det sista ordet vägrar jag dock att trolla fram.

Det finns 1000 MIPS @ 64bitars överskrivande MAC, vilket räcker till många filterlänkar med över 100 dB filterdynamik.

Allt är open hardware, dvs inte bara hela kretscheman finns och gerber-files utan även ECAD filerna är öppna.
Så det går att sätta dit vilken tokig CODEC man nu önskar och sätta undre gränsfrekvensen så lågt man vill.

Så om den nu ska vara USB-ljudkort, gitarreffekt eller digitala delningsfilter eller digital ACE eller alltihopa - det är förmodlingen din kunskap som sätter begränsningen. Du kan även packetera allt i en egen produkt och sälja den under eget varumärke.

Vill man beräkna stora FFTer (embedded mode) så får man nog slänga dit ett SDRAM chip oxå, för långa FIR baserade EQ's.
MIPSEN kan skals uppåt i steg om 500 MIPS då det inte används någon single-bus arkitektur som bottnar.

Men frågan är väl egentligen - hur snygga rattar måste en produkt ha innan den går att sälja till en ½ HIFI nörd ?
Hur långt hade mini-DSP produkten kommit när den lanserades?

[Ragnwald]

Intressant. Kan du ge oss en schematisk bild på upplägget, modul för modul, med lite pilar emellan, så kanske vi begriper det du just sagt.

[lilltroll]

Intressant. Kan du ge oss en schematisk bild på upplägget, modul för modul, med lite pilar emellan, så kanske vi begriper det du just sagt.

Mjukvara i USB Audio + MIDI mode



Å va lat jag är, länkar till HW blockschema:

Schema HW: Se sida 4
https://www.xmos.com/download/public/XM-000279-HM-2.pdf

Om man vill kan man redan köpa det i färdig låda från Digi-Key
Tanken med en ref. design är ju dock att man ska göra en egen bättre design - typ - och priset på ref. designen kan inte ses som konkurrenskraftigt - men det är inte poängen.




Gött o blandat;
http://www.xmos.com/products/development-kits/usbaudio2mc
Och så en YouTube film:
Dock filmen är för minstingen som "bara är" stereo
http://www.youtube.com/user/MyXMOS#p/u/1/UzGUE5A2nwE

[Ragnwald]

Tack. Hm.. hur kommer de analoga blocken in?
Det här ligger lite utanför min kompetens, men skam den som ger sig.

[lilltroll]

Tack. Hm.. hur kommer de analoga blocken in?
Det här ligger lite utanför min kompetens, men skam den som ger sig.

På sida 4: Det som ligger till höger om blocket CODEC är analogt, ja sen är ca ½ av CODECen analog.

Vill du ha ännu fler pilar så kommer det här:

https://www.xmos.com/download/public/XM-000344-SC-1.pdf

[Ragnwald]

Kan du säga något om de analoga linjeingångarna och utgångarna?
Impedans, känslighet, output etc.

[lilltroll]

Kan du säga något om de analoga linjeingångarna och utgångarna?
Impedans, känslighet, output etc.

http://www.cirrus.com/en/products/cs42448.html vars analogdel matas med 4.1 V

[Ragnwald]

Har jag fattat fel, om det ska till externa anpassade buffersteg på både in och utgångar? Det kan ju knappast gå att ansluta förförstärkare/slutsteg direkt till de externa filtren?

[pgmj]

Kanske bryta ut detta till en egen topic?

[UrSv]

Jag skriver ju inte så ofta här längre, är moderator på ett engelskt forum gällande HW+SW av inbyggda system.

Min nyfikenhet gäller hur hardcore folk är numera här:

Är mini-DSP produkten med sitt GUI svår så ni svimmar ?
-- snip --
Hur långt hade mini-DSP produkten kommit när den lanserades?

Jag tror att Mini-DSP är lagom svårt för att vara användbar för tillräckligt många. XMOS är överväldigande för de flesta skule jag tro.

Mini-DSP hade kommit tillräckligt långt när den lanserades och var fullt stabil och användbar. Mjukvara har sedan tillkommit för fler varianter på filter.

XMOS borde flyttas till en egen tråd.

[lilltroll]

Det jag länkar till får nog beskrivas som en linux kärna men utan t.ex. Ubuntu 10.10 skalet/förpackning för att hålla mig till liknelsen.

99.99% kommer inte att tycka att YES, jag gör en egen Ubuntu.

Jag är mer intr. av vad ska jag säga en marknadsundersökning - vad kunden skulle vilja ha om han själv fick välja.

Så var det "apparna" som gjorde den till en attraktiv produkt ?
Tillräckligt lätt att använda ?

(Jag håller mig från att svara på fler tekniska frågor - tills moderator lägger det tekniska i en egen tråd)

[Rundberg]

Mycket intressant frågeställning Lilltroll, den förtjänar helt klart sin egen tråd! Jag ska göra ett försök att splitt i eftermiddag, jag har inte tid just nu. Jag ska också försöka svara på dina frågor.

Håll ut!

[lilltroll]

Någongång 1985 så kunde man köpa svindyra DSP kort och sätta i sin 286/386. Redan då var det en population som började bygga digitala delningsfilter mm. Det rasade in artiklar till JAES, och jag känner till svenska utvecklingsbolag som släpade hem sina specialdatorer på helgen för att pröva att leka med digitala filter hemma till sin stereoanläggning.

När Pentium kom på sent 90 tal, så kunde man göra det hemma på PC:n om man hade tillräcklig kunskap - vilket jag började pilla med.
Hur många ville ha en +10 000 kr höfläkt igång i vardagsrummet för att kunna lyssna på musik ? Ett fåtal.

Numera finns det både singel-chip, dvs microDSP+CODEC i samma krets, men fortfarande vanligast är ett CODEC chip + en annan krets som är en blandning ac en DSP+MCU.
Nu förpackat så det går att styra från ett PC-GUI och säljandes för 100-200 dollar så har det blivit en intressant leksak för en större skara.

Det tog ca 25 år CD spelaren gick väl lite snabbare.

Den största skaran kör Windows eller Mac, sen finns det en grupp som av någon anledning tycker att open-source är häftigt även om det skulle vara sämre, sen finns det några få dårar som mig vilken blev irriterad på att ljudkorten på tidigt 90 lät skit - läste det mesta på KTH i kursväg som kunde vara till hjälp för att lära sig mer i ämnet, och som knappt 20 år senare sitter och bygger egna - för han vill veta om han nu kan

Mico-DSP är säkert en perfekt "Mac"-produkt, med sina appar ... fniss
Men hur stor grupp sitter och väntar på "Ubuntu" releasen ?

[Glebster]

Jag skriver ju inte så ofta här längre, är moderator på ett engelskt forum gällande HW+SW av inbyggda system.

Min nyfikenhet gäller hur hardcore folk är numera här:

Är mini-DSP produkten med sitt GUI svår så ni svimmar ?
-- snip --
Hur långt hade mini-DSP produkten kommit när den lanserades?

Jag tror att Mini-DSP är lagom svårt för att vara användbar för tillräckligt många. XMOS är överväldigande för de flesta skule jag tro.

Mini-DSP hade kommit tillräckligt långt när den lanserades och var fullt stabil och användbar. Mjukvara har sedan tillkommit för fler varianter på filter.

XMOS borde flyttas till en egen tråd.

Klockren sammanfattning om du frågar mig...

[Kraniet]

tycker xmos verkar vara en intressant produkt. men helt intressant för den stora massan blir den nog inte fören den förpackas på ett liknande sätt som miniDSP och med lika användbara färdiga apps att använda. Sen att ha full programerbarhet om man vill är ju ett plus.

En sak jag funderade på var hur minidsp står sig mot behringers dcx2496

[BAMBAM]

XMOS verkar ju verkligen häftigt, men jag vet att jag brukar bli lite
väl entusiastisk innan jag har köpt prylen och har den hemma.

Sedan blir det ofta en grej som ligger och samlar damm,
splittrad är väl det rätta ordet för det.

Vad jag skulle vilja bygga med är en standalone Ambisonic decoder.

Det kräver 4 kanaler in och 6, 8 eller flera utkanaler.

Det finns en implementation för linux här http://www.kokkinizita.net/linuxaudio/

Jag skulle helst vilja ha minst 10 analoga utgångar .

Men så länge ingen idealist erbjuder en billigare lösning än $350 så klarar
jag mig genom min inbyggda snålhet

- B

[rikkitikkitavi]

rent prestandamässigt map a/d-d/a omvandlareå vinner dcx. beräkningsnogrannhet i dsp är kanske svårare att uttala sig om. analogdelen i dcx är bra men pga den är anpassad till en annan signalnivå kan den lida av brus vid fel implementering. dcsr har ju flera kanaler. kanske något mera bökig att programmera men har ett snyggt. grafisk gränssnitt, minidsp käns som att den är mera flexibel.
lite mera android, dcx är lite mera symbian eller Apple

Edit :mitt svar.gäller kraniets fråga angående minidsp, inte xmos.

[lilltroll]

Har jag fattat fel, om det ska till externa anpassade buffersteg på både in och utgångar? Det kan ju knappast gå att ansluta förförstärkare/slutsteg direkt till de externa filtren?

I en konsument-produkt skulle jag nog sätta dit buffrar:

1) För att skydda CODECen mot för höga spänningar/strömmar och anpassa till 2V RMS standarden (om man nu vill det)
(Både jag och Mike34 har lyckats ha ihjäl varsin CODEC)

2) Det säljer bra

3) I de fall de faktiskt kan gör nytta som när man använder längre signalkablar

Databladet anger safe-region, vilket inte är samma som utimpedans.
För att utgångarna inte ska försämra THD så ska man inte lasta dem hårdare än 2.5 kOhm. Men en ingång har och andra sidan oftast minst 10 kOhm in-impedans.
Kretsen börjar väl strömbegränsa vilket distar när man närmar sig 10 mA.
Och andra sidan så genererar inte kabeln 10 mA brus sedd som en antenn.

PS. Jag inst. MSVS 2010 Express igår - men risken finns att jag kommer snubbla på avinst. knappen - men jag ska ge det ett försök att prata med dll:er DS:

[Michael]

Min nyfikenhet gäller hur hardcore folk är numera här:

Jag räknas väl som "folk", så här kommer mitt svar på det jag tror du undrar över. Nu skrev du "numera", jag bortser nog lite från det för det blir en kort historia över mina 'digitala filter' projekt/ideer:

Måste varit mot slutet av 90 talet som jag började fundera på digitala filter och DSPer, Mmmm va gott. Men det behövdes ju mycket kraft för att räkna FIR filter. Här kan jag tillägga att signalbehandling och mattematiken har jag inte bra koll på (men en kompis har). Det blev en hel del schemaritning med Analog Devices SHARC, Motorola 563xxx. Datablad lästes mycket!! Efter att svängt fram och tillbaka under lång tid så tänkte jag lite klokt ta fram något lite snabbare och strunta i att det blir värsting, skippa lite delar. Så då blev det ett kort utan processor kraft, tänkte utnyttja PCn som räknare. USB till PC (eget protokoll). Altera för huvudkomponent. Mot slutet smög det sig in en nya SHARC DSP som inte var BGA, för framtida expriment. DA-kort blev ett eget som dockades tre styck till huvudkortet. Dessa två olika kort caddade jag faktiskt kretskort till, 6-lagers om jag minns rätt. Sedan stannade det av. Några år senare köpte jag en DEQX PDC, som nu är såld.

XMOS nämndes i någon tråd för länge sedan, jag kollade dock aldrig in denna så mycket då. Nu har jag tittat lite mera... verkar ju verkligen vara något som hade passat mig. Det är alltså en väldigt speciell typ av DSP. Hinner med en hel del FIR räknande och det utan kärnkraftverk.

Den är tydligen 32 bitars. Jag hittar dock ingen uppgift (så här snabbt) på om den jobbar med heltal eller flyttal. Liltroll kanske kan svara enkelt på det?

PS. Ett krav som jag har om jag skulle bygga något (vilket jag nog inte kommer att göra) är: Att jag vill ha full koll på mjukvaran. Det skall inte krävas ett stort OS (i DSPn) med tusen buggar. Utan lite kod som man kan läsa och se om den 'funkar', eller helt egenskriven kod.

//Michael

[Allram]

Visst är man hardcore! Jag skulle vara intresserad av den beskrivna produkten om den fanns till försäljning.
Jag har idag 2 st DCX i setupen som står och blinkar, lyser och tar plats. Att få ner deras funktionalitet i en liten diskret låda hade varit mumma.

[Kraniet]

den stora nackdelen med minidsp som jag ser är dels problemet med ingång och utgångskänslighet. frågan kring bit-tapp vid volymreglering är ju också en fråga. Sen för mina behöv så skulle jag hellre se 3-4 ingångar och cirka 8 utgångar i en och samma låda.

men det det står och faller med (precis som med linux) är mjukvaran. den måste vara greppbar på ett sådant sätt att det relativt fort (en halv dag?) går att använda i en tänkt applikation. I fallet med linux är det inte så för det mesta..

[Kraniet]

hur hög inkörningströskel pratar vi om egentligen då? hur mycket arbete behövs för att få till säg ett tvåvägs filter med separat sub delning med H/V summering. Till detta lite lagom parametrisk EQ i basområdet.

och var ligger prisnivån?

[bomellberg]

Jag har ju själv labbat lite med att bygga något kring TAS3108-kretsen. Höll på i våras och har väl inte helt släppt det, men känner inget sug efter att färdigställa, tyvärr.

Tanken var att bygga ett digitalt filter, 4 stereopar in och 4 ut, USB till PC så att man kunde tanka ner biquads.

Hit kom jag:

http://www.mellberg.org/digifilt/ADC%20+%20DSP.png

http://www.mellberg.org/digifilt/CPU%20+%20clock.png

(buffertar och spänningsreggar syns ej)

Xmos verkar vara ett fint alternativ, men $269 för XAI + ett XDK utvecklingskit blir för dyrt.

[rikkitikkitavi]

Jag tror för att lyckas måste det vara användarvänligt. Hifiintresserade lägger inte tid på att kompilera kod.

Så ja, minidsp eller DCX2496 är den modell som bör användas.

med möjligheten för de intresserade att göra mera avancerad egen kod för att utnyttja hårdvaran.

så modellen med "appar" eller alternativt ett grafiskt gränssnitt där parameters som branthet,delay, Q-värde, signalmapping mm är det som krävs.

Worst case kan jag tänka mig att man editerar en ascii fil som sedan programmeras in i ett configureringsminne, ungefär som TASXXXX kretsarna. Det kräver lite mera databladsläsning och även
djupare kunskaper men kanske överkomligt.

[bomellberg]

Jo, det var ju det som var tanken.

[UrSv]

hur hög inkörningströskel pratar vi om egentligen då? hur mycket arbete behövs för att få till säg ett tvåvägs filter med separat sub delning med H/V summering. Till detta lite lagom parametrisk EQ i basområdet.

och var ligger prisnivån?

För mig med hygglig teknikvana skulle jag tro 100-200 timmar. Till det kommer sen tid för utveckling av filter. Som jag fattat det. Jämför med Mini-DSP ca 15 minuter tätt följt av skojigt laborerande.

[Somnabula]

Brutefir har jag kört med en del i linux, http://www.ludd.ltu.se/~torger/brutefir.html

vet inte exakt vad minimum cpu är för att köra ett 2.1 system tex., kör man linux som htpc så borde man vara hemma iaf.[/s]

[lilltroll]

MAC:en, dvs instruktionen Multiply & Accumulate

x= a*b + x

har 6 32-bitars operander, dvs x ovan har 64 bitars upplösning.

Det gör att man tex kan ha en volymkontroll med jäkligt små steg som inte tappar bitar. Dessutom gör det att ett (rimligt) FIR-filter inte får overflow. Även räcker det för de flesta IIR filter med 120 dB filter-dynamik.

För högre upplösning kan man använda instruktioner för variabel längd

Det finns färdiga instruktioner för Long Mult & Add & Sub & Div

Long Add har 5 operander med carry out/ carry in, som kan kedjas i godtycklig längd - säg 128 bitar.

Multiplikation kräver 2 Carry in samt 2 Carry ut:
Låt mig visa med ett färgglatt exempel:

Antag att vill räkna ut 67*89=5963, men vi kan bara upp till 9:ans tabell
(Typ som i mellanstadiet)
Dessutom kan vi bara komma ihåg en siffra i en minnesplats


  67
  89
------
 603
546
-------
5963

Vad jag egentligen gjorde var:

(10*A+B) * (10*C+D) = 100*A*C+10*(A*D+B*C)+B*D
A=6, B=7, C=8,D=9

Antag att vi nu har en operation Long Mult med 6 operander
samt en vektor svar med 4 minnesplatser svar[4]

LMULT
{Hi , Lo} = X,Y,V,W [ X*Y+V+W ]

1) {6,3}=7,9,0,0
2) svar[3] = 3
3) {6,0}=6,9,0,6
4) {5,6}=7,8,0,0
5) svar[2] =6
6) {5,9}=6,8,5,6
7) svar[1]=9
8 ) svar[0]=5

Om vi nu läser siffrorna i vektorn svar: 5,9,6,3

Mha 4 Long Mult operationer har vi nu räknat ut ett 4 siffrigt tal
(Sedan behövde vi 4 operation för att spara det till minnet/vektorn (SRAM)

Det här funkar även i andra talystem. På en 32 bitars maskin kan vi ersätta basen 10 - 1 siffra med basen-2 32-bitar
=> 4 LongMult och vi kan räkna ut uint64*uint64=uint128

XMOS har just denna instruktionsuppsättning.

Den intrsserade faktiskt läsaren kan nu upprepa exemplet och räkna ut vad 5963 / 67 samt 5963/ 68 är
Liggande stolen eller polynom div. kan vara en bra start.

LDIVU d, e, x, y, v
Operation:
d <- (v : x) / y
e <- (v : x) mod y

När ni gjort det kan ni skriva ASM koden som räknar ut 1024 decimaler i pi mha FFT.
Någon kanske märker att multiplikation på det här sättet har likhet med faltning, dvs polynom-multiplikation kan utföras mha faltning. Faltning av stora vektorer utföres dock snabbast med FFT.
>> conv([6 7],[8 9]) = 48 ,110 , 63 => 4+1 , 8+1 , 6+0 , 3= 5,9,6,3

[Michael]

Dessutom gör det att ett (rimligt) FIR-filter inte får overflow.

Det har väl ingen betydelse om det blir overflow vid FIR, eller?
Man räknar ju liksom upp&ner och slutresultatet räcker väl att ha i upplösning så som indata. Vad som händer med de eventuella övre bitarna kvittar väl.

//Michael

[lilltroll]

Dessutom gör det att ett (rimligt) FIR-filter inte får overflow.

Det har väl ingen betydelse om det blir overflow vid FIR, eller?
Man räknar ju liksom upp&ner och slutresultatet räcker väl att ha i upplösning så som indata. Vad som händer med de eventuella övre bitarna kvittar väl.

//Michael

Ett vettigt FIR filters medelvärde ligger inte allt för långt ifrån 0 för AC kopplade system. Dessutom kan man hoppas på att källsignalen är DC-fri.
Men det betyder inte att det accumulerade värdet i FIR filtret inte driver iväg innan man når slutet av svansen. Ett impulsvar kan tex ha många positiva tappar i början som sedan övergår i en lång matta med negativa tappar. Det gäller då att accumulatorn inte får overflow under den positiva delen. Ett wraparound overflow skulle höras, förmodligen väldigt tydligt.

Ekvivalent torde vara att säga att absolutbeloppet för stegsvaret för ett normerat system kan lokalt vara större än 1, även om slutvärdet =1; som i fallet med ett LP filter med förstärkningen 1 i basen.

[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