wieder mal ein Problem mit audiolib.js in NodeJS

[xorg1990]

nee, dann hast du 2 16bit werte als 1 float interpretiert

was musste ich deiner mein nach tun um alle genannten Datentypen in float zu konvertieren?


16Bit nach float mache ich so:

var audioArray = new Float32array(16384)
for (var i = 0; i < audioArray .length; i++) {
audio[i] = (audioArray [i]>0)?audioArray [i]/32767:audioArray [i]/32768;
}

oder als 8 bit:
sample < 0 ? sample / 0x80 : sample / 0x7F;

Ich müsste ja für jeden erdenklichen Fall eine Schleife bauen. Und selbst dann müsste mir der "Zulieferer" den Datentyp miteilen und wenn nicht??
wie bekomme ich den Datentyp aus den buffer Objekt heraus?


Die meisten werden werden 16bit, (int)32Bit oder 24bit bringen, es gibt zwar Float ADC aber die sind selten.
So könnte man das eingänzen.

 

[tsseh]

var float1 = 45.54;
var float2 = 69.96;
var float3 = 88.88;
var floatArray = new Float32Array(3);
floatArray[0] = float1;
floatArray[1] = float2;
floatArray[2] = float3;

var byteArray  = new Uint8Array(floatArray.buffer); // der eigentliche Puffer
// jetzt teilen wir den in 3 Blöcke
//var block1 = new Uint8Array(5); // das macht schon Float32Array nicht mit
var block1 = new Uint8Array(4);
block1[0] = byteArray[0];
block1[1] = byteArray[1];
block1[2] = byteArray[2];
block1[3] = byteArray[3];
//block1[4] = byteArray[4];
//var block2 = new Uint8Array(5);
var block2 = new Uint8Array(4);
block2[0] = byteArray[5];
block2[1] = byteArray[6];
block2[2] = byteArray[7];
block2[3] = byteArray[8];
//block2[4] = byteArray[9];
var block3 = new Uint8Array(2);
block3[0] = byteArray[10];
block3[1] = byteArray[11];
// jetzt interpretieren wir das wieder als float
var floatArray1 = new Float32Array(block1.buffer);
alert(floatArray1[0])
var floatArray2 = new Float32Array(block2.buffer);
alert(floatArray2[0])
var floatArray3 = new Float32Array(block3.buffer); // hier kommt ein fehler

Naja wenn mir der stdout event 16Bit Samples bringt und ich die in base64 Encodiere
und daraus dann Float 32 mache, habe ich doch den Datentyp konvertiert oder??

du meinst, du hast was komplett neues, und kein float-buffer mehr als input?
ja, dann kannst du die 16Bit werte auch in float konvertieren. aber warum? ist zwar noch verlustfrei, aber bei dword (10 digits) glaube ich schon nicht mehr

- - - Aktualisiert - - -

was musste ich deiner mein nach tun um alle genannten Datentypen in float zu konvertieren?

ich weiss ehrlich gesagt immer noch nicht, was du (genau) machst
du kannst 16bit werte natürlich nach float konvertieren, aber wo kommen die her? bisher dachte ich, du hast floats in einem nodejs-bufferobjekt und willst die in ein js float32array bringen.

16Bit nach float mache ich so:

var audioArray = new Float32array(16384)
for (var i = 0; i < audioArray .length; i++) {
audio[i] = (audioArray [i]>0)?audioArray [i]/32767:audioArray [i]/32768;
}

konvertieren kann js automatisch. also ein uint16array in ein float32array
float32array = new Float32Array(uint16array)

Ich müsste ja für jeden erdenklichen Fall eine Schleife bauen. Und selbst dann müsste mir der "Zulieferer" den Datentyp miteilen und wenn nicht??
wie bekomme ich den Datentyp aus den buffer Objekt heraus?

nochmal, was willst du machen, was kommt als input woher und soll als was wohin? aber ohne zu wissen, was der input ist, wird das nie was

- - - Aktualisiert - - -

und nochwas, float kann 7 bzw. 8 digits verlustfrei konvertieren, das wird mit 24 bit schon knapp

 

[xorg1990]

du meinst, du hast was komplett neues, und kein float-buffer mehr als input?

ganau so ist es.

Das ziel des ganzen ist zu sangen: "Zulieferer" bringe mir ein Stream auf mein Server egal welcher Datentyp, der Server macht daraus ein FFT und schließlich ein Bild und ein paar ander sachen z.B CW(Morse) Decoding.


Der zweite punkt wäre den "Zulieferer" nicht mit einer Software einzuschränken, wenn er meint er müsse mit VLC Player oder FFmpeg streamen das soll er das machen.

Problem ist eben herzufinden welcher Datentyp bzw. welche bit deph auf meinen Server ankommt. Das macht zur Zeit Gstreamer.

 

[tsseh]

Problem ist eben herzufinden welcher Datentyp bzw. welche bit deph auf meinen Server ankommt. Das macht zur Zeit Gstreamer.

und der gibt dir immer als sein output -> dein input einen float-nodejs-buffer? oder mal uint16-buffer und ein anderes mal uint32-buffer? bei letzterem hättest du ja nichts gewonnen, da du den datentyp immer noch nicht kennst, du aber wissen musst, wie du den buffer interpretieren musst

 

[xorg1990]

oder mal uint16-buffer und ein anderes mal uint32-buffer?

Genau so ist es und ich brauch am ende immer float

Ist aber der Stream von Zulieferer zum Server einmal connected, dann ändert sich die Auflösung nicht mehr. Also die Auflösung ändert sich nicht in Realtime während des streamens .

..da du den datentyp immer noch nicht kennst, du aber wissen musst, wie du den buffer interpretieren musst

Genau das ist das Problem, Gstreamer erkennt den buffer und macht daraus einen float buffer, den ich für mein Filter brauche.

Gstreamer ist die einzige Software die ich kenne, die die bit depth automatisch erkennt. Wie das funzt ist die hohe schule


Habe den Quellcode vom audioparse gefunden.
vielleicht hilft's.

 

[tsseh]

Ist aber der Stream von Zulieferer zum Server einmal connected, dann ändert sich die Auflösung nicht mehr. Also die Auflösung ändert sich nicht in Realtime während des streamens .

was ist denn DER STREAM von Zulieferer? das ist doch kein normaler audio stream? sonst würde ja ein protokoll dahinterhängen?!

Habe den Quellcode vom audioparse gefunden.
vielleicht hilft's.

da wird nichts analysiert

 

[xorg1990]

was ist denn DER STREAM von Zulieferer?

Menno versteh mich doch mal

Der Stream = raw PCM von einer Soundkarte, die pcm Daten werden via TCP versendet
Je nach ADC hat der PCM Stream vom Zulieferer, 16bit, 32bit, 32bit float, 24bit, oder oder Auflösung.

Zulieferer = der Sender, die Soundkarte, der TCP Host am anderen Ende.

steht auch alles in dem pdf was in #6 verlinkt habe.
ausschnitt aus dem pdf:

2.3 Ethernet

Irgendwie müssen die Daten aus dem A/D-Wandler zum Rechner gefu¨ hrt werden. Der PCM1804
macht 192 000 Messungen pro Sekunde, zu je 24 Bit fu¨ r 2 Kana¨le; insgesammt sind das 9216000
Bit/Sekunde. Eine solche Datenmenge schaufelt man nicht mehr einfach u¨ ber die serielle RS232- 
Schnittstelle in den Rechner; auch fu¨ r die parallele (Drucker-) Schnittstelle ist das ziemlich 
viel. Viele andere PC-Schnittstellen, wie ISA-Bus, PCI-Bus, USB, und Firewire, sind entweder auch 
zu langsam, und/oder ziemlich kompliziert (wenigstens fu¨ r den Amateur).
Am Einfachsten erschien die Anbindung u¨ ber 10 Mbit/s Ethernet. Von der Geschwindigkeit her
reicht das ja (zwar gerade), und die Komplexita¨t kann ziemlich niedrig sein. Es brauchen keine 
kom- plizierende Sachen wie automatische Detektierung/Identifizierung/Konfiguration gemacht zu 
werden (wie z.B. bei PCI oder USB). Und wenn man das Selbstbaugera¨t auf eine separate 
Ethernetkarte im Rechner anschließt (die Karten sind ja ganz billig), ko¨ nnen keine Kollisionen 
mit Signalen von ande- ren Gera¨ten auftreten; so entfallen die Teilsysteme um Kollisionen zu 
vermeiden und evtl. kollidierte Daten zu wiederholen die normalerweise bei Ethernet no¨ tig sind.
Das Generieren der Ethernetframes wird von einem Atmel-Mikrokontroller (ATMega32) gemacht, zusammen 
mit einigem zusa¨tzlichem Logik. Im Mikrokontroller la¨uft ein Programm das in einer End- 
losschleife 762,9 mal pro Sekunde ein Ethernetframe generiert: zuna¨chst einen korrekten Framehea- 
der, dann 1536 Datenbytes (das sind 256 Samples von beiden Kana¨len des A/D-Wandlers), und dann
ein Frame-Ende. Weil der Mikrocontroller mit nur 12,5 MHz getaktet wird, kann er nicht 10 million
individuelle Bits pro Sekunde erzeugen; dafu¨ r wird ein Schieberegister gebraucht, das 1,25 
million Mal pro Sekunde 8 bits aus dem Mikrokontroller u¨ bernimmt; jeden 10. Takt muß der 
Mikrocontroller also ein Byte bereitstellen. Der Datenfluß vom A/D-Wandler zum Mikrokontroller 
erfolgt auch seri- ell, und zwar mit 12,5 Mbit/s (wobei jedes 4. Byte bedeutungslos ist); dieser 
Datenstrom wird in ein zweites Schieberegister geschoben, das vom Mikrokontroller genau zu jedem 8. 
Takt ausgelesen wird. Die Endlosschleife in der Software muß die Daten also auch puffern: die 
Datenbytes kommen in sehr regelma¨ßigen Absta¨nden an, werden aber in Gruppen von 1536 wieder 
ausgegeben. Leider hat der Mikrocontroller nicht ausreichend Rechenleistung um auch noch die 
32-Bit-CRC (die “Pru¨ fsumme”) fu¨ r das Ethernetframe zu berechnen: die gesendeten Frames haben 
deshalb eine falsche CRC, und der Rechner muß diese beim Empfang der Frames ignorieren.
Um das ganze mo¨ glichst einfach zu halten, sind die Takt des Ethernet-Senders und des A/D- 
Wandlers eng verknu¨ pft. Deshalb wird der A/D-Wandler nicht mit 24,576 MHz betrieben (wie vom 
Hersteller spezifiziert), sondern mit 25 MHz, und deshalb ist die Abtastrate (und demzufolge die
empfangene Bandbreite) 195,3125 kHz statt 192 kHz.

sonst würde ja ein protokoll dahinterhängen?!

Was verstehst du den unter Protokoll?? RTP, RTSP oder meidest du codec mp3 , ogg, letzteres kommt nicht in frage da mp3 wichtige Daten aus dem heraus filtert.
Bei RTP usw. kenne ich mich nicht so aus, am ende muss ja das Ethernet frame auf einen ATmaga erstellt/erzeugt werden.
Aber diese Version des Empfängers wird eher selten vorkommen. Die meisten werden mit einem rtl-sdr arbeiten oder mit der Soundkarte.
Wer Geld hat nimmt das.

da wird nichts analysiert

Hm, dann wird das wohl gst-launch selber machen.

 

[tsseh]

Der Stream = raw PCM von einer Soundkarte, die pcm Daten werden via TCP versendet

langsam wirds klarer, also deine soundkarte

Je nach ADC hat der PCM Stream vom Zulieferer, 16bit, 32bit, 32bit float, 24bit, oder oder Auflösung.

die auflösung ist ja egal, als was kommen die werte? also selbst, wenn ich eine 24bit auflösung habe, habe ich keine 24bit datentyp

steht auch alles in dem pdf was in #6 verlinkt habe.

das habe ich mir überhaupt nicht angesehen, weil ich dort den

Grund warum das nodejs auf einen tcp port lauscht

erwartet hätte, und der ist mir egal. ich sehe mir das bei gelegenheit mal an, aber für heute: TL;DR

Was verstehst du den unter Protokoll?? RTP

ja, soetwas hätte ich erwartet

Bei RTP usw. kenne ich mich nicht so aus, am ende muss ja das Ethernet frame auf einen ATmaga erstellt/erzeugt werden.

und wo steckt der ATmaga? hängt an dem die soundkarte? wie?

Hm, dann wird das wohl gst-lauch selber machen.

wie soll das gehen?

 

[xorg1990]

langsam wirds klarer, also deine soundkarte

Richtig.

die auflösung ist ja egal, als was kommen die werte? also selbst, wenn ich eine 24bit auflösung habe, habe ich keine 24bit datentyp

Integer, eben in den verschinden Auflösungen aber wen das nichts zu sagen hat...na bin ja mal gespannt.

und wo steckt der ATmaga? hängt an dem die soundkarte? wie?

Die Soundkarte == Empfänger, wers richtig drauf hat nimmt statt ein Mikrocontroller einen FPGA.


Andren wiederum ist das schon zu viel und die nehme die Soundkarte oder einen USB-SDR Empfänger. Wie die daten dann zu meine Server kommen ist mir egal.
Ich stelle ein Port bereit, und der macht daraus schöne QRSS Bildchen und andere Sachen. Die Daten werden im Browser via canvas gerendert

 

[tsseh]

wie soll das gehen?

es geht auch nicht, dort musst du auch das format angeben in dem die daten vorliegen

- - - Aktualisiert - - -

Richtig.

nee

Die Soundkarte == Empfänger, wers richtig drauf hat nimmt statt ein Mikrocontroller einen FPGA.

also keine Soundkarte, sondern ein stück selbst gebastelte hardware mit atmega über dessen adc du letztendlich die daten einliest. damit kennst du den datentyp, in dem du die werte speicherst.

Integer, eben in den verschinden Auflösungen aber wen das nichts zu sagen hat...na bin ja mal gespannt.

und interger auf dem atmega sind? 8, 16 oder 32 bit?
die willst du direkt als float speichern, oder erst noch umrechnen? willst du die erst umrechnen, hast du ja immer einen float wert, sonst einen definierten datentyp int

Wie die daten dann zu meine Server kommen ist mir egal.

mit server meinst du den atmega?

- - - Aktualisiert - - -

Anhang anzeigen 4416

alter, ist die von dir? ne doppelseitige platine kostet inkl. vias kaum mehr als ne einseitige, oder ätzt du die selber?

 

[xorg1990]

damit kennst du den datentyp, in dem du die werte speicherst.

Ja ich kenne den Datentyp meines Empfängers, aber ich kenne nicht den Datentyp und/oder die Auflösung von andren Empfängern

es geht auch nicht, dort musst du auch das format angeben in dem die daten vorliegenl

Hab ich mir doch gedacht, dann muss ich eine Client Software programmieren, die zumeidest im usb-sdr oder Soundkartenfall 16 bit liefert, baut derjenige dem Empfänger selber muss er es mir mitteilen.
Ich muss dann halt Servesseitig für jedes erdenkliche Format einen Konverter Programmieren.

mit server meinst du den atmega?

Ne der Atemga ist ein Teil der Hardware des Zulieferers. Mein Server ist auf einen Hoster (vServer) hochgeladen und verrichtet da seine arbeit.
Der Version mit den atmaga machen nur wenige Funkamateure, die meisten werden entweder via USB oder über Soundkarte gehen.

Das Ziele meines Nodejs Skriptes(liegt auf dem vserver)ist ein Bindeglied zwischen Hardware und internt zu schaffen. Das Problem ist das man für ein normal CW bild alle 30sec ein ftp Verbindung öffne muss,dann kappt das nicht immer jedes 2te bild wird übersprungen.
Zusätzlich werden via dropbox noch 12h an Bildern gepeichert als Archiv so zu sagen, ist auch wieder Bandbreite.

Das 2te Problem ist es gibt uneidlich viel Hardware und dann natürlich auch Treiber+Betriebssysteme, die Software für die für die fft verwendet wird ist reinweg Windows basierend, fällt also fürs Raspberry Pi schon mal flach.

Ein weiters Problem ist das ein Windows Rechner strom verbraucht und das 24h rund um die uhr, das Raspberry Pi nur rund 3 watt, ein weiters Thema ist das viel Funkamateure auf ihren Recher kein Webserver like Apache laufen lassen wollen (es könnte mich ja jemand hacken).

Ich habe mir halt gedacht, wie könnte man sich das oder die Problem(e) angehen und bin halt auf die Idee gekommen ein TCP to websocket Bridge zu programmieren, die auf ein hoster liegt, das Rendern der fft funktioniert in Browser. Für normal cw ganz gut aber für qrss 20 nicht, das Rendern geht so langsam das man den Browser 12h anlassen muss ehe der Wasserfall eine Millimeter weiter gerückt ist. Drauf hin ist die Tcp to websockt bridge um ein paar Funktionen erweitert worden. Auf den Server werden nicht nur dir Protokolle geändert sonder auch noch eine fft gemacht und die Bilder für die Langsameren modie vorgerendert.

alter, ist die von dir? ne doppelseitige platine kostet inkl. vias kaum mehr als ne einseitige, oder ätzt du die selber?

ne das ist nicht von mir, das ist ein Bild von einen Holländer aber unser Empfänger ist derselbe, ist aber noch nicht fertig.
Das ätzen lassen wir machen, dafür bin ich Funkamateur man kennt da mehr Leute als ein manch mal lieb ist. Den Schaltplan zeichne ich selber

Habe aber schon andere Sachen gemacht, z.b. habe ich ein Usb-stick DVB-T Hama NANO geöffnet und den Tuner überbrück, gelötet habe ich unter einem Mikroskop, das ist kein scheiß.
Den draht den ich dafür benötigt habe, habe ich von einer Hochfrequenz spule abgewickelt, ein einzelnes Litze von einem Kabel war zu dick.

 

[tsseh]

Ja ich kenne den Datentyp meines Empfängers, aber ich kenne nicht den Datentyp und/oder die Auflösung von andren Empfängern

ok, verstanden

Hab ich mir doch gedacht, dann muss ich eine Client Software programmieren, die zumeidest im usb-sdr oder Soundkartenfall 16 bit liefert, baut derjenige dem Empfänger selber muss er es mir mitteilen.

du kannst ja ein simples protokoll festlegen, im 1. paket kommt eine beschreibung der nachfolgenden daten

- - - Aktualisiert - - -

Habe aber schon andere Sachen gemacht, z.b. habe ich ein Usb-stick DVB-T Hama NANO geöffnet und den Tuner überbrück, gelötet habe ich unter einem Mikroskop, das ist kein scheiß.
Den draht den ich dafür benötigt habe, habe ich von einer Hochfrequenz spule abgewickelt, ein einzelnes Litze von einem Kabel war zu dick.

sowas bekomme ich nicht hin, ich hab vor jahren aufgehört platinen zu basteln, weil alles was interessant war kaum noch als dil mit 2,54 mm pinabstand zu bekommen war. als nächstes hätte ich ein 100-pin TQFP einlöten müssen, nachdem ich den chip bestellt und in der hand hatte, war mir klar, das das nichts wird.