# Audiosignal von Line-Out zu Line-In



## mharbach (22. Sep 2009)

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:


```
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):


```
[-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:


```
[-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


----------



## Spacerat (28. Sep 2009)

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 (28. Sep 2009)

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


----------



## Spacerat (28. Sep 2009)

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.


----------



## mharbach (28. Sep 2009)

wird auch nicht gehn, hab auf beiden Seiten 8kHz


----------



## Spacerat (28. Sep 2009)

Wodurch sind die 8kHz denn festgelegt?


----------



## mharbach (28. Sep 2009)

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


----------



## tuxedo (28. Sep 2009)

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 (28. Sep 2009)

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....


----------



## tuxedo (28. Sep 2009)

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 (28. Sep 2009)

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...


----------



## Spacerat (28. Sep 2009)

mharbach hat gesagt.:


> 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 (28. Sep 2009)

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.


----------

