Arta in Single Channel Mode

[MarcoSQ]

Beste iedereen,

Sorry, ik krijg dit niet compacter dat dit. Om vervuiling aldaar te voorkomen, verhuis ik dit onderwerp uit dit topic vandaan.

Discussiepunt
Heel vaak zie ik het volgende advies langskomen. Niet alleen hier, ook elders :

'Als je de individuele drivers voor een tweeweg wilt meten : zorg dat dat je de linker zijde van de gate, NIET verplaatst tussen die twee metingen. En de mic positie, noch de luidsprekerpositie wijzigt. Dan verschijnt de akoestische offset, automatisch in je fasegrafiekjes'.

Dit advies wordt OOK voor single channel metingen afgegeven.

Stelling
Ik denk dat dit geen goed advies is. Je schept ten onrechte de verwachting, dat je zo de relatieve fase tussen twee drivers ('delay') mee-meet.
Dat gebeurt (mijns inziens) in het geheel NIET. Je meet zelfs de excess phase agv de meetafstand niet.

De enige fase die je meet, is relatief aan de door ARTA gedefinieerde t=0. Dat zou geen probleem zijn, als dat een vast punt was. Dan kun je ervoor compenseren middels een offset. Maar dat punt verschuift, afhankelijk van de vorm van je impuls.

Bij deze benadrukt : ik pleit niet tegen single channel; daar is niets mis mee. Ik pleit tegen dat advies.
Bij deze benadrukt : dit heeft niets met Windows/drivers van doen. Puur de implementatie van single channel, in ARTA.

Korte uitweiding
Maak of pak een willekeurige single channel PIR, en controleer daarmee het volgende verhaal :

In single mode, begint(*) de impuls in ARTA altijd op dezelfde tijd.
Welk tijdstip dat is, hangt af van je sampling rate. Bij 44.1kHz is dat 6,083ms. Bij 48kHz is dat 6,25ms. Etc. In ELK geval, is dat het 300e sample. ARTA definieert dit als t=0, het tijdstip waarop de 'puls' op de output gezet werd. Je neemt dus geen enkele vorm van delay mee, elke poging daartoe is zinloos

Als je WEET dat je nog handmatig delay/offset toe moet voegen, is dit geen enkel probleem. Maar dat wist je niet, zie 'discussiepunt' en 'stelling'.

(*) = het begin beschouwt ARTA als 10% van het spanningsniveau, van de hoogste piek. Dat hoeft niet per se de eerste piek te zijn. Afrondingen worden binnen ARTA altijd gedaan, naar het hogere sample.

Uit die 10% moet je zelf kunnen herleiden, dat t=0 bij de meting van elke andere driver, op een andere plek zit. Zo niet, dan zal ik dat verduidelijken.

Eerste stap (c.q. : vragen aan jullie)
Begrijpt iemand de redenen achter voorgenoemd advies ? ('Laat linker marker' staan, etc.)
Indien ja : kun je deze uitleggen ?
Indien nee : is mijn redenatie logisch, kun je inderdaad de relatieve fase tussen 2 metingen, niet bepalen zo ?

Uiteindelijke doel van de discusie
- Mensen voorzien van beter advies. Je metingen niet snappen, is rot. Ik weet nog goed, hoe hard ik heb gevloekt op mijn eigen single-channelmetingen die ik niet kon begrijpen destijds...
- Zien waar ik fout redeneer
- Mensen informeren over de beperkingen van zo'n meting. Je tijdinfo wordt meer verziekt, dan je vermoedelijk beseft (volgt eventueel nog)
- Mensen enthousiasmeren voor (semi) dual channel meningen. Zeer kleine moeite, zeer groot plezier.

Ik ben heel benieuwd hoe dit onderwerp gaat verlopen.
Enerzijds kan ik me niet indenken dat ik een denkfout maak. Anderszijds kan ik me ook niet voorstellen, dat een dergelijke 'fout' zo lang onopgemerkt kan blijven...

Heb je wat te melden ? Niet twijfelen, gewoon doen !

[MarcoSQ]

Bijgaand 16 willekeurige PIR bestanden om mee te spelen. Sommigen van mezelf, sommigen van anderen hier op het forum. Ik hoop dat er geen copyright op rust .

pir.zip

[bert stoltenborg]

Ja, zoiets als MLSSA (dedicated hardware) meet absoluut in het tijddomijn.
ARTA doet dat alleen als je dat tweede kanaal gebruikt.
Heeft Ivo Mateljan bevestigd.

[Pjotr]

Ja, zoiets als MLSSA (dedicated hardware) meet absoluut in het tijddomijn.
ARTA doet dat alleen als je dat tweede kanaal gebruikt.
Heeft Ivo Mateljan bevestigd.

Met 1 kanaals mode gebruikt ARTA softwarematig het noise signaal direct voor de correlatie i.p.v. het 2e kanaal. Zit je nog steeds met het mic - speaker delay en de latency van de kaart. In die zin verschillen 1 kanaals metingen en 2 kanaals metingen niet en kun je voor beide type metingen voor het delay compenseren. In 1 kanaals metingen alleen als de latency van de kaart consistent is en dat is hij meestal wel.

[MarcoSQ]

Bedankt voor jullie reacties heren !

Een absolute fase ben ik ook niet direct op naar zoek. Ik weet ook dat dat single ch niet kan.
Twee relatieve fases, afgezet tegen dezelfde referentie moet al genoeg zijn.
Echter, in mijn optiek kán dat single ch niet. Tenzij ik een verkeerde gedachtenkronkel maak.

Peter,
Mits je een ASIO driver gebruikt, verrekent ARTA de latency daarvan automatisch. Althans, volgens de manual. Ik heb zelf niet de moeite gedaan om dat te bevestigen.

Zit je nog steeds met het mic - speaker delay en de latency van de kaart. In die zin verschillen 1 kanaals metingen en 2 kanaals metingen niet en kun je voor beide type metingen voor het delay compenseren.

Wélke delay compenseer je dan ? Voor zover ik overzie, starten alle PIRs uit mijn vorige post op exact hetzelfde tijdstip (of strikter : sample positie). Dus vrij van welke delay dan ook, zou ik zeggen. Misschien kan je er mijn gedachtenfout uit herleiden...
En het leukste is : wát er op de plek van die sample positie komt, MOET afhankelijk zijn van de vorm van jouw impuls. Die sample positie kan daarmee geen vaste referentie zijn, om de fase aan te relateren.

[Pjotr]

Peter,
Mits je een ASIO driver gebruikt, verrekent ARTA de latency daarvan automatisch. Althans, volgens de manual. Ik heb zelf niet de moeite gedaan om dat te bevestigen.

Alleen in 2 kanaal mode verrekent ARTA de latency van de kaart. In 1 kanaal mode niet. De driver maakt niet uit, of je nu ASIO gebruikt of Direct Sound, althans bij mij.

In 1 kanaal mode kun je nog steeds met de offset compensatie het totale delay van latency + mic/speaker delay compenseren. Probeer maar.

[MarcoSQ]

Ik weet niet helemaal zeker wat je bedoelt. Je bedoelt de functie : get -> predelay, toch ? Waarbij je de marker op het maximum van de impuls zet, en de cursor op een vaste positie zoals bijv. 0 ?

If so : het enige wat er bij mij gebeurt, is een predelay instellen, die enkele samples hoger is dan 300 samples. Hoeveel samples hoger, hangt af van de steilheid in de start van de impuls, maar niet van de meetafstand.
Waar ik eerst een fase had zonder noemenswaardige delay, heb ik nu een flinke bult delay/verschuiving. Dat was precies niet de bedoeling volgens mij...

Korter : de referentie voor de fase wordt nu sample 0, in plaats van sample 300. Same difference, but worse (zou ik zeggen).

If not : welke precieze functie bedoel je dan ?

Is het voor jou heel veel moeite om te demonstreren wat je bedoelt, a.d.h.v. deze PIR ?

nearfield woofer.zip

(Overigens, het is niet MIJN probleem, in dual ch werkt het voor mij prima. Ik ben gewoon benieuwd naar de werking van single ch, aangezien het vanuit mijn perspectief niet mogelijk lijkt te zijn om zo 2 drivers qua fase te relateren...)

[Pjotr]

Heb nu even niet de tijd (en de spullen bij de hand) om het te demonstreren.

Het gaat als volgt: Je zet de cursor (geel) een stukje voor de impuls of (of op 0, kan ook) Dan de marker (rood) op het maximum van de impuls. Als je op "Get" klikt pakt hij het pre-delay. Nu de cursor (geel) niet meer verplaatsen! De gate stel je nu in met de marker (rood). Probeer maar met een loop back meting.

[MarcoSQ]

Dat geeft helemaal niets, hoor . Ik vroeg om een gunst, en ik hoef niet te verwachten dat ik die ook krijg .

Even een tijdelijke meetsetup gemaakt; zit nu niet achter de meetcomputer.
Ik snap de predelay nu, bedankt daarvoor ! Fout was het nadien verplaatsten van mijn cursor, om een goede gate te maken.
Ik heb hem nu op de gebruikelijke plek gezet voor een gate, en daar gelaten.

Je verwijdert er idd alle vrijwel alle 'delay' in je fasegrafiek mee, dat is alvast iets. Dan kan je iig in je simulatie nog een (aannemelijke) offset invoeren, om alles weer in orde te krijgen.

Ook bij een controle-farfieldmeting, werkt dit vrij goed om alle delay te verwijderen.

Die verwijderde delay is overigens heel klein. Enkel de 'fout' in dat kleine stukje, doordat je voor een correcte FR, de gate helaas vóór het maximum van de impuls moet zetten. Hij zit bij lange na niet in de ordegrootte van de soundcard latency (die zit ook simpelweg niet in de impuls). En al helemáál niet in de ordegrootte van 1 meter reisafstand + latency...die er ook niet in verstopt zit.

Het enige wat je volgens mij (dus niet zeker) doet, is het verschuiven van je referentie t.o.v. positie 300. Waarvan ik vrijwel zeker weet, dat dat geen vaste referentie kan zijn. Over de implicaties daarvan moet ik even nadenken, daar wordt het nu te laat voor. Ik krijg het nog niet sluitend in mijn hoofd, maar daar lijkt niet te kunnen kloppen.

Het discussiepunt blijft overigens nog steeds staan : voorgenoemd advies (zie 'discussiepunt') heeft geen functie, en zorgt er niet voor dat je de (onderling) relatieve fase meeneemt. Akkoord, of niet akkoord ?

[Chris_T]

Het discussiepunt blijft overigens nog steeds staan : voorgenoemd advies (zie 'discussiepunt') heeft geen functie, en zorgt er niet voor dat je de (onderling) relatieve fase meeneemt. Akkoord, of niet akkoord ?

Ja, want bij een 1-kanaals meting is er geen (tijds)referentie.
In jip en janneke taal, er is geen stopwatch die de start registreert.
Daardoor kun je de 'looptijd' c.q. afstanden ook niet bepalen.
En dus ook geen relatieve verschillen.

Ik kan wel begrijpen waarom velen hier de mist ingaan, want als je de normale fase informatie bekijkt dan zie je deze wel veranderd a.d.v. de 1e marker.
Dat kan de illusie wekken dat er een referentie is, maar dat is dus niet zo!

Het is al genoemd in de beginpost, maar ik quote voor alle duidelijkheid toch even een stukje uit de Arta manual:

Arta_positie_referentieframe.png

M.a.w. bij een 1-kanaals meting is er geen vast referentiepunt en wordt het -20dB punt (10%) van de impulspiek op sample/frame 300 gezet.
Dat is ook goed te zien in de metingen hieronder:

Arta_referentiepunt_1-kanaalsmeting.png

Arta_referentiepunt_1-kanaalsmeting2.png

Het 1e plaatje is van een tweeter gemeten op 1m afstand, het 2e plaatje is van een woofer nearfield meting met de mic nagenoeg op de conus.
Je ziet dat sample/frame 300 op ca. 10% van de impulspiek zit.

Peter,
Mits je een ASIO driver gebruikt, verrekent ARTA de latency daarvan automatisch. Althans, volgens de manual. Ik heb zelf niet de moeite gedaan om dat te bevestigen.

Alleen in 2 kanaal mode verrekent ARTA de latency van de kaart. In 1 kanaal mode niet. De driver maakt niet uit, of je nu ASIO gebruikt of Direct Sound, althans bij mij.

In 1 kanaal mode kun je nog steeds met de offset compensatie het totale delay van latency + mic/speaker delay compenseren. Probeer maar.

Ik ben toch benieuwd hoe je daarop bent gekomen?
Wat je aan de metingen hierboven kunt zien, wordt de hoeveelheid delay alleen bepaalt door de samplerate.

1/96kHz *300 = 3.125ms

Edit
Ik hoop niet dat men door deze topic het idee krijgt dat een 1-kanaals meting alleen maar goed is om de frequentierepons op te meten.
De fase informatie is dan wel niet bruikbaar, maar indirect is toch wel de faserelatie tussen 2 drivers te bepalen.

[MarcoSQ]

Dank je Chris,
Je zit duidelijk op exact dezelfde lijn, als ik. Wat jij uitlegt, is 99% van wat ik bedoel.

Ik hoop niet dat men door deze topic het idee krijgt dat een 1-kanaals meting alleen maar goed is om de frequentierepons op te meten.De fase informatie is dan wel niet bruikbaar, maar indirect is toch wel de faserelatie tussen 2 drivers te bepalen.

Mee eens, maar wel met een grote toegevoegde MITS :
MITS je alle delay die je zelf veroorzaakt door de cursorpositie, verwijdert met 'methode Pjotr'. In beide metingen.
Dan heb je een vaste referentie, waartegen je kan compenseren met de verwachte offset.

Als je dat NIET doet, heb je geen flauw idee hoe groot die offset moet zijn. Je weet zelfs niet welke kant die op moet gaan : dat kan naar voren zijn of naar achteren; je kunt het niet weten.

(ik werk nu vanuit een andere browser, en zie dat er nogal wat opmaakfouten in de startpost staan. Ziet er nogal schreeuwerig uit met al die onderlijningen , dat was niet bedoeling. Corrigeer ik later wel)

[Jag]

Ja of je meet gewoon dual channel toch?

Nuttig topic wel dit

[Pjotr]

In single channel kun je i.d.d. niet het absolute delay tussen speaker en microfoon meten. Maar waarom zou je dat willen? Je wilt toch het onderlinge delay weten tussen 2 speaker units? Overigens is delay niet hetzelfde als fase!

Het delay wat er is kun je compenseren met het pre-delay. Wil je het delay tussen 2 speakers meten dan is dat toch geen probleem? Het verschil zie je aan de verschuiving van de impuls als je ze afzonderlijk meet. En compenseer je voor het delay voor 1 speaker dan krijg je ook het onderlinge faseverschil te zien mits je niets verandert aan de opstelling en het pre-delay wat je voor de andere speaker hebt ingesteld.

[Jag]

Dan snap ik het nog niet. Ik begreep uit het verhaal dat de start vd impuls altijd op 300 samples wordt gezet, dan kan je toch geen onderlingen delay meer meten?

[Pjotr]

Dat is een richtlijn. De cursor (gele lijn) zet je zover voor de impuls daar waar de lijn echt stil is en hij geen rimpels meer vertoont. Zie viewtopic.php?p=1700592#p1700592 Voor de berekening van de frequentieresponsie en de fase is de cursor het startpunt van de eigenlijke berekening. Met het pre delay nul je dan in feite ieder delay wat er verder nog is uit. Die pre-delay waarde wordt alleen maar gebruikt voor de berekening van de fase.

Waar je wel rekening mee moet houden met verschillende speakers meten, is dat je de cursor op die plaats voor impuls zet: Daar waar voor alle speakers de impluslijn echt nul is en hem bij de verschillende metingen niet meer verplaatst. Dit geldt overigens evengoed voor een 2-kanaals meting.

[MarcoSQ]

Met alle respect; volgens mij zie je iets over het hoofd, Pjotr.

Kijk eens aandachtig naar de twee plaatjes van Chris_T hierboven.
De ene is 1cm weg
De andere is 100 cm weg.
Beiden starten op hetzelfde definieerde tijdstip (!) (of sample positie, hoe je het ook wilt noemen.

Als je hierop de get-predelay uitvoert met de methode in je allerlaatste post, filter je alleen een onderlinge delay weg van (veel) kleiner dan 1 ms. Ik heb hier geen Arta, dus kan dat nu niet preciezer meten.

Dat is de delay die je zelf hebt veroorzaakt, omdat je cursor nou eenmaal VOOR de piek moet zetten voor de fouriertransformatie. En niet er OP.
(EN een klein stukje, die was opgestreden als gevolg van de vorm van de impuls. Niemand vraagt ernaar, dus nog geen uitleg. Is ook bijzaak in het grote geheel)
Die onderlinge delay benadert in de verste verte niet, wat het zou moeten zijn : grofweg 3ms, overeenkomend met 99cm.
(in dit voorbeeld is de verschuiving in de ruimte, toevallig de goede kant op. Maar, dat kan ook prima andersom gebeuren.).

Aannemend dat je je hier in kunt vinden (is dat zo ?), dan kan er m.i. maar 1 methode werken :

Jouw get->predelay, maar dan in beide drivers, ALLE delay verwijderen. Vervolgens de offset corrigeren in je simulatiepakket, OF deze handmatig toevoegen in 1 van de metingen.

[Pjotr]

Ah, ik zie al waar de crux zit: Wat je ook meet, ARTA zet het begin (of maximum?) van de impuls altijd op 300 samples. Maar dat doet het ook met een 2-kanaals meting! Dus ook daarmee kun je geen onderlinge vertraging tussen 2 speakerunits meten.

Ik herinner mij nu dat ik daar een paar jaar geleden ook al tegenaan liep en het onderlinge delay heb gemeten met een sinus burst en een oscilloscoop op de beoogde X-over frequentie.

[MarcoSQ]

Ah, ik zie al waar de crux zit: Wat je ook meet, ARTA zet het begin (of maximum?) van de impuls altijd op 300 samples.

Top ! Het was al een paar keer gezegd, steeds vanuit een andere benadering, maar ik kan goed begrijpen dat dat verdrinkt in de ruis die ikzelf veroorzaak.

Je bent nu begrijp ik akkoord met de stelling : 'in single channel, is het niet mogelijk om een onderlinge faserelatie tussen 2 drivers aan te tonen. Wat je ook doet'.

Maar dat doet het ook met een 2-kanaals meting! Dus ook daarmee kun je geen onderlinge vertraging tussen 2 speakerunits meten.

Ik ben er BIJNA volledig zeker van dat dat niet klopt. M.a.w., dat je wel degelijk de volledige absolute fase meet, inclusief mic-speaker delay, exclusief sound card latency.
De fase relateer je aan sample 300, die de vaste referentie voor de fase wordt.
Dat is mogelijk, doordat ARTA nu het werkelijke tijdstip t=0 kan meten, en dus kennen.

Eerst koken, dan eten, dan wat praktijkexperimenten doen die dit moeten bevestigen of ontkrachtigen.

Ik begin het al bijna leuk te vinden

[Pjotr]

Maar dat doet het ook met een 2-kanaals meting! Dus ook daarmee kun je geen onderlinge vertraging tussen 2 speakerunits meten.

Ik ben er BIJNA volledig zeker van dat dat niet klopt.

Waarop baseer je dat? Wishful thinking?

Misschien dat er wat aan ARTA gewijzigd is op dat vlak maar een paar jaar geleden was dat wel zo en moest ik een andere manier toepassen.

[MarcoSQ]

Waarop baseer je dat? Wishful thinking?

Nee, op ervaring. Maar let op : ik heb dat niet als feit neergezet, dat durfde ik niet aan. Mensen laten zich graag bedotten, en dat geldt óók voor mij. Wie weet heb ik me jaren lang laten foppen door ARTA.

Ik ga nú de spullen verzamelen voor een dual channel test, die dat moet bevestigen of ontkrachtigen.
Verwacht resultaat over een (ruim) uurtje ofzo. Ik wil niet over 1 nacht ijs gaan met zoiets .

[pappaleo]

Ik heb wel wat losgemaakt, geloof ik

[Pjotr]

Ik heb wel wat losgemaakt, geloof ik

Wil je dat dan onmiddellijk weer vastzetten dan

[MarcoSQ]

Op deze laptop (dat is niet de meetlaptop) draait een oudere versie van ARTA zie ik nu (1.8.0).
De meetsessie is af, en bevestigt absoluut wat ik zei over dual channel mode.

Toch post ik hem niet, omdat die een verwarrend beeld schept. Er zit een delay in, die vrijwel overeenkomt, met de latency van mijn soundcard. Het kan zijn dat deze eerdere ARTA versie, de latency nog niet automatisch verrekende. Dat wil ik eerst zeker weten, voordat het de wijde wereld in gaat.

Ik heb meer te doen vanavond, dus het kan zijn dat vanavond niet meer lukt. Maar vertrouw er maar op, dat dat spoedig goedkomt .

LET OP : EDIT ivm onjuiste conclusie !

[MarcoSQ]

Ook de nieuwe 1.8.2 verrekent/compenseert de ARTA de ASIO latency NIET. Niet in single, en niet in dual channel
Ik denk dat 'we' dit verkeerd begrepen hebben in de manual.

Het is ook niet relevant in dit verhaal: het wordt alleen wat lastiger uitleggen. Positieve kant : ik kan mijn bestaande meetsessie dus gewoon gebruiken.

Nu eerst naar de bouwmarkt gipsplaten halen, voordat ze dicht zijn .

LET OP : EDIT ivm onjuiste conclusie !

[Pjotr]

Ook de nieuwe 1.8.2 verrekent/compenseert de ARTA de ASIO latency NIET. Niet in single, en niet in dual channel
Ik denk dat 'we' dit verkeerd begrepen hebben in de manual.

Het is ook niet relevant in dit verhaal: het wordt alleen wat lastiger uitleggen. Positieve kant : ik kan mijn bestaande meetsessie dus gewoon gebruiken.

Nu eerst naar de bouwmarkt gipsplaten halen, voordat ze dicht zijn .

Hee, nu wil ik ook je meetplaatjes zien

En kun jij nu wel of kun jij nu niet de speaker offset meten?