Digitalfråga

av **norman** » 2003-08-13 13:51

Morello: jag tänkte alltså köra utan DSP och låta programmet/datorn göra jobbet i realtid... dock är jag inte särskilt insatt i själva programmeringen i C (har inte ingått i de kurser jag läst, men jag har en bok om digital signalbehandling i C++...)

jo, Matlab är väl smidigare att använda när man skall ta fram filtrena...

Är väl tveksam om det blir av att göra nåt filter... är nog lite för lat... men fundera kan man ju göra!

Alexi: intressant länk!

av **Morello** » 2003-08-13 14:01

Ok, var har du FIR-filtret då?
:wink:

av **norman** » 2003-08-13 14:19

Ok, var har du FIR-filtret då?

Vem har sagt att jag skall göra ett FIR-filter? :wink:

Naturligtvis så kommer ju beräkningarna att skötas av processorn, men jag menade att jag inte tänkt använda en separat DSP som är skräddarsydd för signaler.

Man borde ju kunna läsa av samples direkt från ljudkortet och in i minnet och sen summera ut dom multiplicerade med olika koefficienter till utgången på ljudkortet.

av **Morello** » 2003-08-13 14:28

Då är jag med.

Det blir minst 26 Megaflops per sekund

(med 300 tappar / kanal) om du implementerar ett FIR -filter i realtid.

Om du inte använder FIR, ska du använda ett IIR-filter då?

\Morello

av **Jesper** » 2003-08-13 14:35

Man kan räkna ut FIR-filter med drc (http://freshmeat.net/projects/drc/) som man sedan kör i BruteFIR (som Alexi redan tipsat om).

Mvh Jesper

av **norman** » 2003-08-13 14:42

Morello: Har inte tänkt nåt på hur beräkningskrävande det blir, och inte heller på om det blir FIR eller IIR (det senare är väl lite värre att programmera..)

BruteFIR verkar ju intressant, får se när man får tid att sätta sig in i det...

av **Jesper** » 2003-08-13 14:44

På BruteFIRs hemsida (http://www.ludd.luth.se/~torger/brutefir.html#howfast) kan man läsa:

How high throughput can I get?

With a massive convolution configuration file (note: the format is from an older version of BruteFIR and is not fully compatible with the current) setting up BruteFIR to run 26 filters, each 131072 taps long, each connected to its own input and output (that is 26 inputs and outputs), meaning a total of 3407872 filter taps, a 1 GHz AMD Athlon with 266 MHz DDR RAM gets about 90% processor load, and can successfully run it in real time. The sample rate was 44.1 kHz, BruteFIR was compiled with 32 bit floating point precision, and the I/O delay was set to 375 ms. The sound card used was an RME Audio Hammerfall.

Morello:
Räknar de filtertapparna på något annat sätt eller är den faktiskt väldigt snabb alltså?

Mvh Jesper

av **Morello** » 2003-08-13 15:11

Låter suspekt med 131072 tappar. Får det inte att gå ihop med fördröjningen som han påstår är 375 ms. Det torde snarast röra sig om 3000 ms

av **norman** » 2003-08-13 15:28

hmm jo det borde ju vara lite svårt att hinna läsa in 130000 samples på 375ms om samplehastigheten är 44khz... (fast han kanske har en HEMSKT snabb dator..

)
Har väl blivit nåt sifferfel nånstans?

av **Alexi** » 2003-08-13 15:48

Om jag minns rätt kan Athlon göra 7st flytalsberäkningar per klockcykel.
Så med 1Ghz blir det alltså 7 000 000 000 flytalsberäkningar per sekund. Räcker inte det?

av **norman** » 2003-08-13 15:52

det där med snabb dator var ett litet skämt..

Man måste hinna läsa in så många samples som man har tappar i ett FIR-filter innan nåt kan komma ut. Har man alltså 130000 tappar så tar det 130000/44100 = 2.97sekunder

Om jag inte har fel...

av **Morello** » 2003-08-13 15:53

Jo, men fördröjningen beror på antaler samples/sekund samt antalet tappar. Att processorn är tillräckligt snabb är ju en förutsättning föär att det skall fungera

av **Alexi** » 2003-08-13 15:57

Ah då förstår jag :idea:

Han kanske menar förutom denna tid?

av **Morello** » 2003-08-14 13:12

Kanske är något annat som avses.

av **Wolfie** » 2003-09-09 21:10

" each connected to its own input and output (that is 26 inputs and outputs)"

Så dela den tid ni räknade ut med 26 för att få delaytid per kanal... Iom att ni räknar på totaldelay för 26 kanaler...

Morello: Om du vill slippa använda en dator där du kör Matlab för att beräkna filterkoefficienterna så gör ett interupt i SHARCEN som via ett adaptivt RLS-filter beräknar dem åt dig

. Det blir med största sannolikhet iaf 90 % rätt, utan att man i princip lyfter ett finger (System Identification Toolbox i Matlab är till stor hjälp här).
Matlabkoden översätter man ju sedan bara till ASM-kod (om man inte använder de fiffiga översättarna i Matlab) innan man kompilerar och exekverar den.

Iof så finns det en stor fördel med att använda Matlab för beräkningarna av koefficienterna (dvs. om man har ett riktigt bra A/D-kort), vilken är att Matlab (iaf 5.1 och frammåt) räknar med en precision på 80-bitar (floating point)... Det är mer än de flesta DSP:s är byggda för...

Nackdelen blir sedan att just DSP:n inte har "lika stor" (Hmm 32-bitars floating-point?) upplösning, vilket leder till kvantiseringsfel (jämfört med Matlabs modell). :wink:

Men så kan man ju vara riktigt noga i Matlab och tvinga Matlab att räkna med exempelvis 32-bitars ord, fixed-point eller floating-point...

Råkar man få ont om minne i DSP:n.... Så behöver man ju bara spara hälften av koefficientvärdena för ett FIR-filter... De är ju symmetriska

av **norman** » 2003-09-09 21:26

Wolfie skrev:" each connected to its own input and output (that is 26 inputs and outputs)"

Så dela den tid ni räknade ut med 26 för att få delaytid per kanal... Iom att ni räknar på totaldelay för 26 kanaler...

nja...

det står ju:

"setting up BruteFIR to run 26 filters, each 131072 taps long, each connected to its own input and output"

Vilket borde betyda att varje enskilt filter har 131072 tappar vilket gör att våra beräkningar på delaytiden stämmer... :wink:

tycker dock att 130000 tappar verkar otroligt mycket.. är det inte vanligare med typ några hundra?

av **Bamsefar** » 2003-09-10 00:03

Okay...

IIR vs FIR, rent teoretiskt (och praktiskt), kan någon på sina fingrar rada upp för och nackdelar ???

(som info, TAG McLarens TMREQ använder IIR).

av **hevi** » 2003-10-26 22:50

norman skrev:Morello: Har inte tänkt nåt på hur beräkningskrävande det blir, och inte heller på om det blir FIR eller IIR (det senare är väl lite värre att programmera..)

IIR är klart enklare att implementera eftersom man oftast inte behöver oroa sig för cykeltorka. Däremot är det lite pill med att säkerställa stabiliteten i IIR.

Henrik

av **NNord** » 2004-01-17 18:18

Morello,

TacT:en har ett flertal digitala utgångar, SPDIF samt AES/EBU
faktiskt, så det är bara o koppla...

Om jag kör digitalt ut från TacT:en till delningsfiltret och sedan
ändrar volym, är det då delningsfiltret som kommer sätta
bergränsningen på bitdjupet eller är det TacT:en som gör det?

Alltså, jag tycker mig inte höra någon skillnad på ljudet när jag
lyssnar på svag resp. hög nivå, är detta verkligen sågon sådan
"big deal" igentligen..

Mycket snack om att digitala grejor förlorar bitdjup, men vadsjutton

... :roll:

hur jäkligt ÄR det IGENTLIGEN

??

av **Nagrania** » 2004-01-17 23:16

NNord skriver: Om jag kör digitalt ut från TacT:en till delningsfiltret och sedan
ändrar volym, är det då delningsfiltret som kommer sätta
bergränsningen på bitdjupet eller är det TacT:en som gör det?
Det är TacT:en som bestämmer bitljupet och samplingsfrekvensen i efterföljande steg(delningsfiltret) Du vet Niklas skit in i delningsfiltret betyder skit ut till dina slutsteg och vad dina JBL högtalare får in...ja det vågar jag inte änns tänka på. :lol:

Grattis Niklas det här var ju kul tycker jag.

av **NNord** » 2004-01-18 20:32

VA?
VAD är roligt?
har du tagit nått sorts knark eller