Kedves Fórumtársak!
Érdeklődnék, hogy van-e olyan hangkártyakezelő eszköz/program (Linux), amely lehetőséget biztosít a hangkártya mikrofonbemenetének folyamatos olvasására, kb, mintha egy fájlt olvasnék. Mondjuk úgy, hogy 3-4 másodpercenként kiolvasom belőle az elmúlt 3-4 másodperc tartalmát.
Az ALSA-t néztem, mintaprogramokkal, kicsit egyszerűbben szeretném. Egy olyan működés lenne ideális, mint ahogy a /dev/null -t olvassuk: megnyitom, kiolvasok belőle N mintát, lezárom, oszt jónapot.
Minden tippet előre is megköszönök.
- 490 megtekintés
Hozzászólások
kiolvasom belőle az elmúlt 3-4 másodperc tartalmát
Olyan megoldást könnyű implementálni, ami valós időben olvassa a bemenetet, na de olyat, ami pufferel neked visszamenőleg X időre, az macerás lesz.
Mi a cél? Mit szeretnél pontosan csinálni?
- A hozzászóláshoz be kell jelentkezni
A pufferelest vagy tamogatja a hw vagy nem. Szoftveresen problemas, neked kell megoldani. Az egyszerubb ha mindig tudod olvasni a bemenetet es ha percenkent 22500-at olvasol, akkor 22.5kHz lesz a hanganyag felbontasa.
Gondolom szovegelessel inditanal valamit vagy lehallgatnal.
- A hozzászóláshoz be kell jelentkezni
ffmpeget rá lehet venni, hogy hangkártyáról olvasson és fájlba írjon tömörítetlenül. A fájl lehet pipe is. A pipe-ot szerintem be lehet konfolni, hogy jó nagy puffere legyen. Vagy ha nem akkor van ilyen command line amit sorba lehet kötni, vagy valami. És akkor ez a tákolmány tudni fogja amit leírtál.
- A hozzászóláshoz be kell jelentkezni
A cél az, hogy az utolsó 1-5 másodperc mikrofonbemenetének átlaghangereje egy 8 vagy 16 bites számként rendelkezésre álljon. A hangminőség kb mindegy, de nem baj, ha ez paraméterezhető. Tehát nem kell az egész stream.
Próbáltam arecord (ALSA) -val fájlon keresztül, ezzel az a bajom, hogy mindig újra és újra be kell állítanom a hangerőt és egyéb cuccokat az alsamixerrel.
(Az iddigi ötleteket ksözönöm.)
> Sol omnibus lucet.
- A hozzászóláshoz be kell jelentkezni
Hogy érted az átlaghangerőt? A mikrofon jelét ha mintavételezed, akkor lesz benne veszteség. Persze, ha sávkorlátolt a jel, akkor visszaállítható az eredeti folytonos jel a mintavételezett értékekből, és akkor tudsz integrálással átlagos értéket számolni.
Nam eg milyen mértékegységben kéred a hangerőt? A 8/16 bit csak a digitalizálás felbontása, de a 255/65535 az minek felel meg, mekkora hangnyomásnak? Vagy ez neked mindegy?
Mit szeretnél pontosan csinálni?
- A hozzászóláshoz be kell jelentkezni
Nem kell kalibrálni hangnyomásra. Volt-e hangtüske vagy nem és az alapjelhez - ez kb 4-5%-os kivezérlés - képest mekkora. Valójában egy véletlen háttérzaj kell az adatbázisba, ehhez ez tökéletes.
> Sol omnibus lucet.
- A hozzászóláshoz be kell jelentkezni
Háttérzajt bárhol le is tölthetsz, ha akarsz, legálisan.
- A hozzászóláshoz be kell jelentkezni
Nekem a háttérzajt egy konkrét pillanatban, más mérőjelekhez képest kell detektálnom ÉS egyetlen mérési adtframe-ben, a többi adattal együtt, időbélyeggel ellátva szükséges eltárolni. Később az adatelemzésnek ki kell ejtenie a véletlen inputokat. Először a háttérsugárzásra gondoltam - ezt mérem jelenleg is, mint környezeti állapotot -, de kiderült, hogy esőben megnövekszik, mert egyrészt felülről kimosódik némi sugárzó anyag, a vizes talaj pedig kicsit intenzívebben leheli a radont, vagyis nem teljesen véletlenszerű mondjuk a páratartalomhoz vagy az ég színéhez viszonyítva.
> Sol omnibus lucet.
- A hozzászóláshoz be kell jelentkezni
man pacat
- A hozzászóláshoz be kell jelentkezni
Hm, ez jó lehet egy fifon keresztül. Köszi, nézem.
> Sol omnibus lucet.
- A hozzászóláshoz be kell jelentkezni
Nagyjából működik...
A parec-kel csinálom, egy scripben fut, amit detektált, azt kiírja egy fájlba. 2 mp múlva kilövöm, összeszedem az adatokat, lesz egy átlaghangerő belőle és egy megosztott memórián keresztül feladom a mérőrendszernek.
Marha ronda így..., na mindegy működik. Hogy lehet olyat csinálni, hogy a parec X mennyiségű adat után leálljon? Mert most változik a fájlméret- többek közt ez is ronda.
Jó viszont, hogy a hangerőt (== érzékenységet) tudom paraméterezni.
(Ps.: Egy normális zajmérés-távadó 3000-4000 EUR!!)
> Sol omnibus lucet.
- A hozzászóláshoz be kell jelentkezni
"(Ps.: Egy normális zajmérés-távadó 3000-4000 EUR!!)"
- lidl-os hangnyomasmerot webkameraval figyeltetni, annak a streamjet idobelyeggel fajlba rogziteni. kb. 40EUR.
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
- A hozzászóláshoz be kell jelentkezni
Ha mar PulseAudio, akkor nem volna jobb inkabb vmi VU meter alkalmazassal elvegezni a hangeroszamitast es csak azt pollozni majd tovabbitani?
- A hozzászóláshoz be kell jelentkezni
[@zitev kollégának is]
Két lehetőség volt: vagy beemelek egy professzionális zajmérőt - kültér, 0-10 volt, katonai kivitel, kalibrált, madártüske stb. - vagy valami hótprimitív megoldást alkalmazok teszt célra, hogy a rendszert próbálgathassam az elvi megoldás helyességét illetően. Mivel a jelen helyzetben nem akartam 1millió+ HUF-ot egy elvi megoldás tesztelésére költeni ÉS mikrofonom, hangkártyám volt, úgy döntöttem ezt az utat választom, mert, ha a mikrofonbemenet pillanatnyi RELATÍV hangerejét elő tudom állítani, akkor az a project jelenlegi állásánál megfelelő megoldás.
> Sol omnibus lucet.
- A hozzászóláshoz be kell jelentkezni
Nekem az nem világos, hogy miért nem folyamatosan logolod a mért értékeket és miért nem a logból csinálsz moving average-t. Szerintem célszerűbb a mért értéket minél előbb (a méréshez legközelebb) rögzíteni (fájlba pakolni), és onnan dolgozni tovább, mint a mérőeszközt (mikrofon) rávenni arra, amit alapból nem nagyon tud (mért értékek pufferelése).
Persze simán lehet olyan aspektus, amit nem látok és ami miatt ez nem praktikus (pl túl sok adat jön ki a mérőeszközből), de ez itt nem ilyennek tűnik.
Csaba
- A hozzászóláshoz be kell jelentkezni
De, pont az a baj, hogy sok adatot dob a hangkártya. Az kell, hogy az elmúlt 3-4 másodpercben mekkora volt a relatív input-hangerő átlag. Egy darab szám, 0-32767 között. Ez, mint mérési adat bekerül a mérőrendszerbe. Az adat előállításának függetlennek kell lennie a mérőrendszertől, annak nem lehet része, úgy kell viselkednie, mint egy analóg mérőműszernek, még akkor is, ha ténylegesen digitális adatot ad fel.
> Sol omnibus lucet.
- A hozzászóláshoz be kell jelentkezni
Hogy érted, hogy sok adatot dob a hangkártya?
- A hozzászóláshoz be kell jelentkezni
Nem akarom a mérőrendszert 22 kHz-s adatok elemzésével terhelni. Nem azért mert nem képes rá, hanem mert ebben a projektben nem ez a dolga. Így áll össze most a folyamat:
1. a paraméterezett parec vesz egy kb 2 mp-es mintát, ezt lerakja egy raw-fájlba. Az egész egy scripben fut. A scrip háttérbe küldi a parec-et és cca. 2 sec múlva killall-la kilövi. Egy adatfájl marad utána.
2. egy memóriarezidens program menedzseli a scriptet: indítja a parec-scriptet, megvárja, amíg befejezi magát, összeszedi az adatokat, csinál belőle egy átlaghangerőt és egy megosztott memórián keresztül az adatot (1 db 16 bites szám) beírja a megfelelő regiszterbe.
3. a mérőrendszer úgy olvassa az adatot, mint egy bármilyen más mérőműszer adatát. Összecsomagolja az összes többi mérési adattal és eltárolja a háttértáron.
Két nagyon fontos tulajdonsága van ennek a megoldásnak: (1) olcsó+nem ráz; (2) működik. Hát így... Majd indítok egy szoftveres "Jól van az úgy" topikot és beteszem oda a "megoldást"
> Sol omnibus lucet.
- A hozzászóláshoz be kell jelentkezni