Das deutsche Python-Forum

hallo!

ich weis, ich habe schonmal eine frage gestellt, die etwas hiermit zu tun hatte, doch haben mir die daraufgefolgten antworten nicht wirklich bei meinem jetzigen problem weitergeholfen.

mein ziel ist folgendes:
1. aufnahme von sprache ueber ein mikrofon
2. senden der daten zu einem server
3. server mischt daten mit denen anderer gespraechsteilnehmer
4. server verteilt gemischte tonspuhren an alle anderen clients
5. alle clients spielen unterbrechungsfrei den stream vom server ab

meine probleme sind nun:
- punkt 1 und 2, da ich nicht weis, wie ich einen ununterbrochenen stream der aufgenommenen daten zum server senden kann.
- punkt 3, weil ich nicht weis, wie ich mehrere tonspuhren mischen kann.
- punkt 5, da ich nicht weis, wie ich einen solchen stream unterbrechungsfrei spielen kann.
- ausserdem: welchen codec sollte ich verwenden? oder sollte ich in wave aufnehmen und dann die daten irgendwie komprimieren?

mir fehlt hier im moment einfach der anfang...

traumhaft waere natuerlich eine plattformunabhaengige loesung, aber da das mit sehr großer wahrscheinlichkeit sowieso nicht gehen wird, ist es auch okay, wenn es nur unter windows laeuft.

es waere sehr schoen, wenn ihr mir hinweise und codeschnipsel geben koenntet!

vielen dank schonmal im vorraus!

lg
roschi

@roschi: Für's "unterbrechungsfreie" Senden der Daten zum und vom Server würde ich UDP verwenden. Wenn da Pakete nicht ankommen, oder aus der Reihe tanzen, kann man die einfach verwerfen.

Muss unbedingt auf dem Server gemischt werden? Das würde bei komprimiertem Audio ja bedeuten, das dort alles dekomprimiert, gemischt und neu komprimiert werden muss. Dauert dort extra Zeit und die Qualität sinkt bei erneutem komprimieren. Es ist eventuell günstiger einfach die komprimierten Daten von allen an die Clients zu verteilen und die dort dekomprimieren und mischen zu lassen. Das Mischen kann dann eventuell sogar in Hardware geschehen, wenn die Soundkarte beim Empfänger das unterstützt.

Passendes, freies Komprimierungsformat für Sprache wäre beispielsweise `speex`.

Letztlich die Frage: Musst Du das wirklich selber implementieren? Kannst Du nicht einfach einen Asterisk aufsetzen, oder Teamspeak verwenden!?

BlackJack hat geschrieben:@roschi: Für's "unterbrechungsfreie" Senden der Daten zum und vom Server würde ich UDP verwenden. Wenn da Pakete nicht ankommen, oder aus der Reihe tanzen, kann man die einfach verwerfen.

ja, das werde ich machen... aber dann brauch ich ja noch einen extra verbindung, zum steuern?!

BlackJack hat geschrieben:Muss unbedingt auf dem Server gemischt werden? Das würde bei komprimiertem Audio ja bedeuten, das dort alles dekomprimiert, gemischt und neu komprimiert werden muss. Dauert dort extra Zeit und die Qualität sinkt bei erneutem komprimieren. Es ist eventuell günstiger einfach die komprimierten Daten von allen an die Clients zu verteilen und die dort dekomprimieren und mischen zu lassen. Das Mischen kann dann eventuell sogar in Hardware geschehen, wenn die Soundkarte beim Empfänger das unterstützt.

der server sollte schon mischen, damit die clients (haben nur geringe bandbreite) nicht soviel traffic haben. der server hat aber eine bessere anbindung ans netz.

BlackJack hat geschrieben:Passendes, freies Komprimierungsformat für Sprache wäre beispielsweise `speex`.

ja, das habe ich mir auch schon angeschaut. aber die letzte kompilierte version ist fuer python 2.2, und das wollte ich eigendlich nicht nutzen.

BlackJack hat geschrieben:Letztlich die Frage: Musst Du das wirklich selber implementieren? Kannst Du nicht einfach einen Asterisk aufsetzen, oder Teamspeak verwenden!?

Teamspeak ist nicht frei, und darauf kommt es mir an. Asterix... sieht auf den ersten blick interessant aus, aber nach dem wikipedia-artikel scheint es mir so, als waere ein telefon noetig? ich will keine telefonanlage bauen, sondern einfach nur eine sprachkonferenz machen, mit eniem zentralen server, auf den sich dann 3 bis 4 leute verbinden und miteinander reden.

vielen dank schonmal!

lg
roschi

Für Asterisk ist kein Telefon nötig. Es gibt Telefone, die das SIP-Protokoll beherrschen, und die kann man mit Asterisk verwenden, aber ansonsten gibt's auch Software-"Telefone" wie zum Beispiel Ekiga oder QuteCom.

Als Teamspeak-Ersatz taugt vielleicht auch das freie Mumble-Projekt!?

hallo BlackJack!

BlackJack hat geschrieben:Für Asterisk ist kein Telefon nötig. Es gibt Telefone, die das SIP-Protokoll beherrschen, und die kann man mit Asterisk verwenden, aber ansonsten gibt's auch Software-"Telefone" wie zum Beispiel Ekiga oder QuteCom.

ah okay, also setzt der einfach nur einen SIP-server auf.

BlackJack hat geschrieben:Als Teamspeak-Ersatz taugt vielleicht auch das freie Mumble-Projekt!?

mumble habe ich schon getestet. es ist aber leider mit QT4 gemacht, und da die meisten der gespraechsteilnehmer screenreader nutzen, und ich keinen screenreader kenne, der mit QT4-anwendungen zurecht kommt, kann ich das auch vergessen. ansonsten hat mir mumble recht gut gefallen. nur eine seltsame sache ist dabei passiert: ich habe das mit 2 gespraechsteilnehmern getestet. der andere konnte mich hoeren, aber ich den anderen nicht, obwohl bei ihm sein eigenes sendesymbol geleuchtet hat... aber wie gesagt: ansonsten ist mumble ganz gut.

ich werde mir wahrscheinlich mal asterisk anschauen, denn da gibts ja auch windows-portierungen.

lg
roschi

oh je!
asterisk ist mir einfach zu kompliziert.

ich glaube, ich werde wohl doch irgendwas nehmen muessen, das nicht frei ist... obwohl ich das eigendlich gar nicht will, aber was solls.

trotzdem vielen dank!

lg
roschi

Du kannst ja einen CLI oder GTK+ Client für Mumble machen. Das ist vermutlich einfacher als es selbst zu implementieren, da man quasi nur beim Qt-Client die GUI austauscht.

Btw: Qt (das Produkt von Qt Software) != QT (QuickTime)

hallo!

Leonidas hat geschrieben:Du kannst ja einen CLI oder GTK+ Client für Mumble machen. Das ist vermutlich einfacher als es selbst zu implementieren, da man quasi nur beim Qt-Client die GUI austauscht.

na ich weis ja nicht. mumble hat ein recht kompliziertes rechte- und kanalsystem. ich moechte ja auch nicht mehrere kanaele in meinem projekt haben, oder besser "ich brauche es nicht." - sondern einfach nur eine einzige konferenz... mag sein, dass ich mich irre, aber ich denke, einen mumble-client zu implementieren, ist nicht so einfach.

Leonidas hat geschrieben:Btw: Qt (das Produkt von Qt Software) != QT (QuickTime)

lg
roschi

edit: peinlicher zitat-fehler gefixt

Deswegen sage ich ja, dass du den Client forken kannst und nur die GUI auswechselst.

Übrigens ist das zweite Zitat falsch.

aber mumble ist nicht in python gehackt.

lg
roschi

roschi hat geschrieben:aber mumble ist nicht in python gehackt.

Was nicht unbedingt ein Hinderungsgrund sein muss. Ich weiß nicht was so deine Fähigkeiten sind.

Leonidas hat geschrieben:

roschi hat geschrieben:aber mumble ist nicht in python gehackt.

Was nicht unbedingt ein Hinderungsgrund sein muss. Ich weiß nicht was so deine Fähigkeiten sind.

Python, und ein ganz klein wenig C-grundlagen.