hifi.slovanet.sk

[dustin]

Playrec do octave http://www.playrec.co.uk/index.html funguje výborně. Musel jsem mu trochu pomoci s kompilací (fork s jedním commitem https://github.com/pavhofman/playrec ), ale šlape napoprvně.

Obzvláště efektní je spectrum_analyzer.m z https://github.com/PlayrecForMatlab/playrec-examples - musí se mu trochu zvednout pageSize a pageBufCount, aby to v jednom vlákně moje i5 stíhala bez přeskakování vzorků, ale pak krásně zobrazuje aktuální waveform i spektrum načítané ze vstupu zvukovky, CPU jedno vlákno do 50%, zpoždění úplně v pohodě.

S tímhle to půjde.

Miero, pokud bys souhlasil, navrhuji se už netrápit s vyčištěním polynomy i dynamickými filtry, ale pustit se do implementace průběžného opafitu Tam víme, že to bude fungovat, je to jen o správném určení fáze a levelu první harmonické v druhé smyčce playrecu po spuštění měření (první bychom pustili, aby se zvukovka ustálila) a pak už jen budeme odečítat vygenerované harmonické podle předchozí kalibrace.

[dustin]

miero: Díky za to FFT, budeme hodně potřebovat, bez spolehlivé detekce fází se nehneme. Ten flattop zmiňují v těchto tématech na diyaudio všude možně, tak to asi bude tak

[dustin]

Možná bychom se měli podívat na octave skripty https://audioroot.net/mataa-mats-audio-analyzer/ https://github.com/mbrennwa/mataa , řeší tam spoustu zajímavých věcí.

[miero]

diky, pozriem.

upravil som getHarmonics aby najprv zistil frekvenciu s max. amplitudu (flattop) a nasledne vypocital druhe fft bez okna a s optimalnou dlzkou pre tu zistenu frekvenciu (10 period)

EDIT: tak fail, nefunguje to dobre .. zatial si nemerguj :-(

[opa]

Pánové, malá hádanka, když jí rozluštíte, mohlo by vás to navést správným směrem. (Když ne, tak to potom vysvětlím).
Kde se vzal měřicí kmitočet 1437 Hz, který jsem použil pro testování ?
Nápověda: Fs 48 kHz, FFT 32768

[PMA]

[MaBat]

To je opravdu hádanka, proč zrovna tak blbý číslo. Proč ne třeba 1500 Hz. Inženýři.

[opa]

[opa]

[dustin]

My naštěstí nemusíme mít délku FFT v mocninách dvou.

[PMA]

Pro testování DAC by se měly použít kmitočty, které neomílají dokola pár kódů (příklad je třeba kmitočet 1200Hz při vzorkování 48kHz, který točí dokola jen 40 stejných čísel).

[MaBat]

Chceř říct, opa, že když se při 48 kHz a délce FFT 32768 vyhodnotí záznam 1125 nebo 1500 Hz (kde ten násobek vychází zcela přesně), je horší zkreslení, než pro 1437 Hz?

[opa]

ANO.

[MaBat]

To nedává smysl. 1125 není dělitelem 48000. Přitom mluvíš o vlastnosti převodníků. Já mluvím o zarovnání periody signálu na délku FFT, aby tam nevznikaly zbytečné artefakty metody při obdélníkovém okně, což je tady nutnost. (Tedy předpokládám, že na těch 1125 Hz jako nevhodných netrváš. Těm 1500 Hz jsem ještě ochotný věřit.)

[opa]

Jasně, pro Fs 48 kHz se jedná o kmitočty 12k, 6k, 3k, 1k5, 750 atd. Ale nejlepší je držet se zcela mimo nějakých okrouhlých hodnot. Když se vzorky rozhodí náhodně po celém rozsahu převodníku, funguje to nejlíp.

[MaBat]

To už by dávalo smysl, přecijen chyba tam je i kvantizační, atd.

[opa]

[MaBat]

Není to tak rychlý (aspoň tak to bývávalo), jinak je to úplně fuk.

[dustin]

miero: Možná bychom při kalibraci ani nemuseli v octave rozpojovat výstupní smyčku snd-aloop -> hw:X , ale stačilo by nechat hrát měřicí soft (arta, cokoliv) a jenom propojit fyzické výstupy na vstupy (automaticky, ručně). Rovnou by se tak kalibrovalo pro aktuální frekvenci i výstupní amplitudu, nemuseli bychom na výstupu nic průběžně měřit a pak při kalibraci generovat kopii signálu.

Při kalibraci by se daly rovnou nasnímat parametry harmonických pro různé hodnoty vstupu a při kompenzaci použít interpolované hodnoty mezi dvěma kalibračními body, dle aktuálního levelu měřeného signálu. Muselo by se vyzkoušet, jak moc to mezi levely tancuje, IMO to bude docela spojité.

IMO by šlo multilevel kalibrovat i pro uživatele, kteří by nechtěli automaticky ovládaný kalibrační dělič - stačil by potenciometr. Kalibrace by si hlídala změnu levelu a když by načetla pole s dostatečně stabilním levelem, zkalibrovala by pro něj, uložila parametry k levelu a dala uživateli vědět (třeba pípnutím), že může o kousíček přidat na potenciometru. Čím více kalibračních "zastávek" by si uživatel udělal, tím by se interpolovalo v kratším rozsahu a kompenzace by byla přesnější - blíž reálně naměřeným parametrům. Ten samý kód by se použil pro reléový dělič, jen místo pípnutí by byl pokyn pro další krok na děliči.

Na artě by mezitím viděl výsledky kalibrace jednotlivých kroků, protože by playrec mohl pořád provádět kompenzaci s aktuálními parametry a opravené vzorky posílat dál Artě do virtuální zvukovky.

Samozřejmě by to vyžadovalo přesnou detekci frekvence a fází. Ale frekvence bychom mohli zaokrouhlovat min. na jednotky Hz a pravidlo by bylo, že to umí jen celé hertze. Kalibrace jednoho levelu by pak trvala 1 sekundu (fs vzorků, tedy bin = 1Hz).

Šlo by i kalibraci ukončit, když se nebude pár sekund level měnit - uživatel spustí kalibraci, potenciometrem najede na požadovaný měřený level pořád zobrazovaný v Artě, přestane s ním hýbat, proběhne kalibrace, píp, vyprší čekání na změnu, dvakrát píp a měří se dál s hotovou kalibrací na tomto konkrétním in/out levelu.

[miero]

dustin, to je prace tak na mesiac :-)

mam rozpracovanu upravu getHarmonic() ... s nfft=Fs to fungovalo pekne, tak ako navrhujes

nejaky napad na rozdelenie prace, co by som mohol skusit?

[opa]

A že se tak ptám, světla svítí ? Stěrače stírají ?
Na co složitě detekovat frekvenci ? Když chci měřit kmitočtem 1234 Hz, tak to někam zadám a už to nemusím měřit.

Další věc. Když se má slušně měřit obyčejnou zvukovkou, tak jako tak je potřeba upravit vstupní a výstupní úroveň, aby pracovala v optimálním pásmu, které je poměrně úzké. Takže odpadá kalibrace pro různé úrovně.

Když se ukáže, že parametry zvukovky jsou dostatečně stabilní, stačí vygenerovat korigovaný signál jednou provždycky na věčné časy a nikdy jinak.

Já vím, že hlavním cílem bylo všechno zautomatizovat, aby to fungovalo samo "na zmáčknutí knoflíku".
Ale je potřeba zvážit, do jaké míry je to účelné.

[PMA]

kmitočet v analýze bude vždy nějaký násobek binwidth, šířky binu. V Tvém dnes uvedeném příkladu 48kHz/32768 vzorků FFT je to násobek 1,46484375Hz. Jinak to nejde.

[dustin]

Počítám, že s tím nějaký čas strávím A přiznávám se, že ve dvou se to podstatně lépe táhne, i kdyby pak jenom konzultace, abych nedělal nesmysly.

Jestli mohu poprosit - možná bys mohl zkusit vyzkoušet celou kalibraci/kompenzaci na reálném wavu - nejdříve nakalibrovat harmonické (úvodní offset pro ustálení, pak harmonické na Fs vzorcích), a poté na celém tom wavu zkusit vlastní kompenzaci - na začátku odečíst fázi, vygenerovat záporné harmonické, odečíst a na pár místech výsledku se podívat, co to udělá.

A možná pokud chceš, zkusit si nainstalovat ten playrec. Vytáhnout můj playrec s tím commitem, do playrec/lib/portaudio rozbalit na tom webu linkované zdrojáky portaudio19, nainstalovat liboctave-dev a libasound2-dev, spustit ten octáví build skript, vybrat alsu a pak to sám celé zbuilduje. V aktuálním adresáři vygeneruje soubor playrec.mex, který stačí nakopírovat do adresáře s playrec-examples a příklady lze rovnou spouštět.

Já bych se pustil do nějakého stavového automatu kalibrace/kompenzace vetknutého do té smyčky in -> virtuál. Ovládání zvenku asi přes nějaké soubory, na které by si to v každé smyčce sahalo (klasika arduinní loop ) Pause/unpause jsem myslel sledováním stavu otevření virtuální zvukovky v /proc: arta otevře playback zvukovku snd-aloop -> octave na výstupu spustí kopírování vzorků. To samé pro capture, tam akorát při spuštění musí naměřit fázi fundamentu.

Když nebude přesně sedět příchozí frekvence na generované harmonické, po chvíli se to úplně rozjede. Potřebovali bychom nějak hlídat, že se fáze nijak neposunula (samovolný drift + příp. xruny). Čistě teoreticky by si ji to mohlo každých pár smyček opakovaně nabírat a pořád tím dolaďovat harmonické. Tím bychom pořešili i ten maličký rozdíl frekvencí, ke kterému určitě bude po chvíli docházet.

Takže kdybychom měli metodu, která naměří fázi a amplitudu úvodních period vstupního pole, můžeme ji jenom jednoduše zavolat na začátku každé smyčky a pořád se to bude držet. Takovou metodu také potřebujeme

Playrec si sám ve vlastních vláknech řeší čtení/zápis do alsy (period, buffer) a my si můžeme zvolit libovolně velký buffer, nad kterým budeme pracovat. IMO by nám stačilo data kopírovat mezi zvukovkami jenom párkrát za sekundu. To by mělo vliv jen na celkovou latenci, ta nás při měření nijak nepálí, a zbytečně bychom nedělali FFT moc často.

Sepíšu ten proces někam na github a můžeme jej probrat, určitě to půjde zjednodušit.

[opa]

[dustin]

[opa]

Funguje to malinko jinak. Arta vůbec neumí přehrávat soubory. Takže je současně s Artou puštěný nějaký přehrávač. Do něj můžu mít připravené korigované soubory s různými frekvencemi a úrovněmi, jednoduchým dvojklikem pustím přehrávání zvoleného souboru a v Artě jenom analyzuju signál, který prošel DUT.

A stačí mi na to věci, které už fungují a dají se spustit i v prostředí Windows.
Ještě jednou moc děkuju za ten skript a návod, jak ho použít. Je to fakt skvělá věc !
Ono to možná vypadá primitivně, ale je to blbuvzdorné. Měřicí aparát musí být do jisté míry robustní, abych v případě problémů nemusel řešit, jestli to dělá měřené zařízení, nebo má problémy kalibrační algoritmus.

[MaBat]

[opa]

[opa]

[PMA]

No jistě, při loopbacku z jedněch hodin se taky úspěšně potlačuje jitter, SW neví, že mu courají hodiny.