( asch | 2020. 12. 18., p – 10:54 )

Márpedig én is úgy indulnék el, ahogy locsemege. Az, hogy "nálad okosabbak" csinálták nem jelent semmit, mert lehet, hogy nekik más volt a céljuk, más volt a mintájuk, stb.

Plusz amit csinálnék az az, hogy:

 * Alapból programmal dolgoznám fel

 * A programot paraméterezhetővé tenném (akár mintánként), hogy újrafeldolgozható legyen az egész gombnyomásra

 * A paramétereket verziókezelném

 * És az eredményt többféle beállítással kipróbálnám

Simán el tudom képzelni, hogy az eredményben végül más szempontok lesznek fontosak, mint amit most gondolsz - amikor majd kipróbálod az egészet egyben, akkor jössz rá, hogy mi nem jó. Ezért ha megvan a lehetőség a feldolgozást újrafuttatni, akkor ezt meg is fogod tenni.

A program nem volna nagyon bonyolult  ahogy elképzelem, a mintákkal nem kell feldolgozást csinálni, maximum tényleg annyit, hogy az elején valahogy 0-ból induljanak a minták, ehhez kell valami trükköt csinálni, mert a 0 ugye nem egész mintapontnál lesz. Na, de az is lehet, hogy ez nem is számít... Ki kell ezeket a dolgokat próbálgatni.

A PC feldolgozásból adódó késleltetést egyébként lehet csökkenteni, ha a hangkártya puffer méretét csökkented. Ugye úgy működik, hogy 1 pufferrel mindig előre kell dolgozni a PC-nek, de ha kicsi a puffer, akkor az kevesebb latency-t ad. Persze annyival több interrupt jön, de egy mai PC-n a hang feldolgozása nem lehet gond. (Ha gond, akkor az driver issue lesz, vannak driverek, amik sokáig blokkolják a kernelt, és így nem tud a rendszer real-time működni. Olyan vasat kell venni, amivel ilyen nincsen. Régebben próbálkoztam ilyesmivel, az volt a tapasztalatom, hogy volt olyan driver, ami miatt nem tudott rendesen real-time lenni a kernelem. Ezért én ha ilyet akarnék építeni, akkor most úgy csinálnám, hogy egy célgépre tenném a hangprocesszálást valami nagyon kikönnyített Linuxszal, amire például GUI-t sem tennék, így real time tudna maradni a kernel.)