Audiosignal von Line-Out zu Line-In

Status
Nicht offen für weitere Antworten.

mharbach

Mitglied
Servus,

ich versuche grade eine Art Modem zu schreiben und dazu von dem Line-Out einer Soundkarte zum Line-In einer anderen Soundkarte "Töne" zu übertragen. Nun habe ich ein seltsames Problem. Ich schicke Samples in meine SourceDataLine (AudioFormat af = new AudioFormat(AudioFormat.Encoding.PCM_SIGNED, 8000, 16, 1, 2, 8000, false)).
Die Samples sind shorts und werden dann in je zwei bytes konvertiert (Zweierkomplement weil PCM_SIGNED). Das sieht auf der Quellseite dann so aus und erzeugt ein paar Sekunden lang einen Ton:

Java:
short[] signal = new short[]{-300, -300, -300, -300, -300, -300, -300, -300, 300, 300, 300, 300, 300, 300, 300, 300};

byte[] buf = AudioUtils.shortToByte(signal);
	
for (int i = 0; i < 2000; i++) {
	sourceLine.write(buf, 0, buf.length);
}

Das ganze open(), start(), close() usw. Gedöns mach ich an anderer Stelle.

Auf dem Zielrechner hol ich mir dann ein AudioInputStream des gleichen Formats und bekomme folgendes Ergebnis (zurück nach Short konvertiert, skaliert):

Code:
[-300, -300, -300, -300, 27, 300, 300, 300, 300, 300, 300, 300, -50, -300, -300, -300]

Phasenverschoben und mit nem leichten Jitter an der Flanke, aber das wäre auch kein Problem. Allerdings sieht das Ergebnis nach ein paar hundert Samples plötzlich so aus:

Code:
[-300, -300, -190, 300, 300, 300, 300, 300, 300, 300, 300, 170, -300, -300, -300, -300]

und das geht natürlich so weiter. Das bedeutet dass mit jedem sample-set meine flanke ein stück nach "links" wandert. Kann mir das jemand erklären?

Vielen Dank im Voraus!
Grüße
Marian
 
Zuletzt bearbeitet:
S

Spacerat

Gast
Hmm... Bin mir nicht sicher und meine Annahme hat im Prinzip auch nichts mit Java zu tun aber möglicherweise könnte die DA-Wandlung (ggf. mit Interpolation) am Ausgang der einen Karte und die anschliessende AD-Wandlung am Eingang der anderen das Signal derartig verfälschen. Vllt. mal per Digitaler IO verbinden.
 

mharbach

Mitglied
Das hilft mir ja leider nicht, da meine Applikation über ne Analoge Verbindung wird kommunizieren müssen...
 
S

Spacerat

Gast
Nun ja... Wenns nun an den Wandlungen liegt, dann bringts vllt. was, wenn man mit halber Samplingrate sendet. Also z.B. Sender sendet auf 22050Hz und Empfänger empfängt mit 44100Hz. Zur Not kann man ja auch noch ein Syncsignal (ausgehandelte Frequenz ausserhalb des Daten-Spektrums) senden.
 
Zuletzt bearbeitet von einem Moderator:

mharbach

Mitglied
Letztendlich soll das ganze über nen Handy-Sprachkanal laufen und der hat nicht mehr als 8kHz bzw. benötigt als Input 8kHz PCM
 
T

tuxedo

Gast
Auch wenn die Senderseite nur mit 8kHz sendet, abtasten kannst du doch immernoch mit 16kHz auch wenn nur 8kHz ankommen, oder?

[update]

Das Nyquist-Shannen-Abtasttheorem kennst du?

http://de.wikipedia.org/wiki/Nyquist-Shannon-Abtasttheorem hat gesagt.:
Das Abtasttheorem besagt, dass ein kontinuierliches, bandbegrenztes Signal, mit einer Minimalfrequenz von 0 Hz und einer Maximalfrequenz fmax, mit einer Frequenz größer als 2 · fmax abgetastet werden muss, damit man aus dem so erhaltenen zeitdiskreten Signal das Ursprungssignal ohne Informationsverlust (aber mit unendlich großem Aufwand) exakt rekonstruieren und (mit endlichem Aufwand) beliebig genau approximieren kann.
 

mharbach

Mitglied
Jep das kenn ich. Ich müsste mal überprüfen inwiefern die Hardware mehr als 8kHz kann. Aber ich vermute ja dass die oben beschriebene Verschiebung der Abtastpunkte unabhängig von der Samplingrate auftritt. Ich bin mittlerweile zur Vermutung gelangt das die Quartze der Sender und Empfängerseite nicht gleich schnell schwingen können. Soll heissen 8kHz auf der einen Seite sind evtl. nur 7995 Hz auf der anderen....
 
T

tuxedo

Gast
Bist du an dein "Verfahren" zur Übertragung der bytes gebunden oder bist du da frei in der Wahl?

Ich meine: Ist ja nicht neu dass man via Audio Daten überträgt. Das gute alte AFSK hat sich da denke ich bewährt (vor allem beim Packet Radio mit 1k2 und 2k4 Baud). Und wenn das nicht reicht gibts ja noch zahlreiche weitere Verfahren.

- Alex
 

mharbach

Mitglied
Ich bin leider an das Verfahren gebunden, da ich meine Daten so verpacken muss dass sie nahezu verlustfrei eine oder sogar mehrere GSM Encode/Decode Schritte überleben müssen. Die Applikation soll auf dem GSM Sprachkanal zuverlässig Daten übertragen können.

Das funktioniert auch alles toll, abgesehn von dem Teil wo ich nicht mehr nur PCM in files schreibe sondern tatsächlich über nen Kabel und A/D Wandler gehe...
 
S

Spacerat

Gast
Jep das kenn ich. Ich müsste mal überprüfen inwiefern die Hardware mehr als 8kHz kann. Aber ich vermute ja dass die oben beschriebene Verschiebung der Abtastpunkte unabhängig von der Samplingrate auftritt. Ich bin mittlerweile zur Vermutung gelangt das die Quartze der Sender und Empfängerseite nicht gleich schnell schwingen können. Soll heissen 8kHz auf der einen Seite sind evtl. nur 7995 Hz auf der anderen....
Die Genauigkeit der Abtastrate ist bei Frequenzen unterhalb ihrer Höhe erstmal "zweitrangig". Die Phasenlagen ändern sich ja innerhalb des Kabels nicht. Hast du schon mal etwas längere Amplitudenverläufe miteinander verglichen? Eine andere mögliche Ursache könnte dieses hier sein: Digital-Analog-Umsetzer ? Wikipedia
Im übrigen: Was für ein anderes Verfahren kann es denn werden bzw. welches liegt denn da fest? Mit Sicherheit doch auch ein FSK (verallgemeinert M-FSK).
 

mharbach

Mitglied
Es werden unmittelbar PCM Sample Werte (Symbole), die aus einem Codebook stammen, erzeugt und ausgegeben. Diese werden dann auf der Empfängerseite wieder zurück-gematcht. Das Codebook wurde vorher so erzeugt dass die Symbole Übertragung durch den GSM Sprachkanal überleben.

Die Genauigkeit der Abtastrate ist bei Frequenzen unterhalb ihrer Höhe erstmal "zweitrangig".

Hmm soweit ich das verstehe ja nicht. Was das Nyquist-Theorem sagt ist, das kein Inofrmationsverlust stattfindet falls die Samplingrate > 2*max_freq ist. Der "Informationsverlust" beschränkt sich dabei nur auf den Kurvenverlauf bzw. die involvierten Frequenzen (also der Ergebnis nach FFT).

Bei meiner Applikation gehts dann aber darum möglichst ähnliche Samplewerte auszulesen.

Hast du schon mal etwas längere Amplitudenverläufe miteinander verglichen?

Ja habe ich. Es dauert ~1380 Samples bis sich die Flanke um eine weitere Stelle verschiebt. Ich könnte mir acuh vorstellen die Verschiebung auszugleichen wenn die Periodizität konstant wäre. Leider wächst sie und springt auch ab und an unkontrolliert. Starte ich den Rechner neu liegt sie wieder bei ~1380. Ich befürchte ja dass dies ohne spezielle Hardware nicht zu machen ist. Habe von DACs gelesen die sich gegenseitig synchonisieren. Das würde das Problem lösen.
 
Status
Nicht offen für weitere Antworten.

Ähnliche Java Themen


Oben