WO2006084747A2 - Verfahren zum abspielen und bearbeiten von audiodaten von mindestens zwei rechnereinheiten - Google Patents

Verfahren zum abspielen und bearbeiten von audiodaten von mindestens zwei rechnereinheiten Download PDF

Info

Publication number
WO2006084747A2
WO2006084747A2 PCT/EP2006/001252 EP2006001252W WO2006084747A2 WO 2006084747 A2 WO2006084747 A2 WO 2006084747A2 EP 2006001252 W EP2006001252 W EP 2006001252W WO 2006084747 A2 WO2006084747 A2 WO 2006084747A2
Authority
WO
WIPO (PCT)
Prior art keywords
audio data
data
computer unit
computer
playing
Prior art date
Application number
PCT/EP2006/001252
Other languages
English (en)
French (fr)
Other versions
WO2006084747A3 (de
Inventor
Manfred RÜRUP
Original Assignee
Sp4 Sound Project Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sp4 Sound Project Gmbh filed Critical Sp4 Sound Project Gmbh
Priority to US11/815,999 priority Critical patent/US20080140238A1/en
Priority to EP06706872A priority patent/EP1847047A2/de
Publication of WO2006084747A2 publication Critical patent/WO2006084747A2/de
Publication of WO2006084747A3 publication Critical patent/WO2006084747A3/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/02—Arrangements for generating broadcast information; Arrangements for generating broadcast-related information with a direct linking to broadcast information or to broadcast space-time; Arrangements for simultaneous generation of broadcast information and broadcast-related information
    • H04H60/04—Studio equipment; Interconnection of studios
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10H—ELECTROPHONIC MUSICAL INSTRUMENTS; INSTRUMENTS IN WHICH THE TONES ARE GENERATED BY ELECTROMECHANICAL MEANS OR ELECTRONIC GENERATORS, OR IN WHICH THE TONES ARE SYNTHESISED FROM A DATA STORE
    • G10H1/00—Details of electrophonic musical instruments
    • G10H1/0033—Recording/reproducing or transmission of music for electrophonic musical instruments
    • G10H1/0041—Recording/reproducing or transmission of music for electrophonic musical instruments in coded form
    • G10H1/0058—Transmission between separate instruments or between individual components of a musical system
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10H—ELECTROPHONIC MUSICAL INSTRUMENTS; INSTRUMENTS IN WHICH THE TONES ARE GENERATED BY ELECTROMECHANICAL MEANS OR ELECTRONIC GENERATORS, OR IN WHICH THE TONES ARE SYNTHESISED FROM A DATA STORE
    • G10H2230/00—General physical, ergonomic or hardware implementation of electrophonic musical tools or instruments, e.g. shape or architecture
    • G10H2230/025—Computing or signal processing architecture features
    • G10H2230/031—Use of cache memory for electrophonic musical instrument processes, e.g. for improving processing capabilities or solving interfacing problems
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10H—ELECTROPHONIC MUSICAL INSTRUMENTS; INSTRUMENTS IN WHICH THE TONES ARE GENERATED BY ELECTROMECHANICAL MEANS OR ELECTRONIC GENERATORS, OR IN WHICH THE TONES ARE SYNTHESISED FROM A DATA STORE
    • G10H2240/00—Data organisation or data communication aspects, specifically adapted for electrophonic musical tools or instruments
    • G10H2240/171—Transmission of musical instrument data, control or status information; Transmission, remote access or control of music data for electrophonic musical instruments
    • G10H2240/175—Transmission of musical instrument data, control or status information; Transmission, remote access or control of music data for electrophonic musical instruments for jam sessions or musical collaboration through a network, e.g. for composition, ensemble playing or repeating; Compensation of network or internet delays therefor
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10H—ELECTROPHONIC MUSICAL INSTRUMENTS; INSTRUMENTS IN WHICH THE TONES ARE GENERATED BY ELECTROMECHANICAL MEANS OR ELECTRONIC GENERATORS, OR IN WHICH THE TONES ARE SYNTHESISED FROM A DATA STORE
    • G10H2240/00—Data organisation or data communication aspects, specifically adapted for electrophonic musical tools or instruments
    • G10H2240/171—Transmission of musical instrument data, control or status information; Transmission, remote access or control of music data for electrophonic musical instruments
    • G10H2240/281—Protocol or standard connector for transmission of analog or digital data to or from an electrophonic musical instrument
    • G10H2240/295—Packet switched network, e.g. token ring
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10H—ELECTROPHONIC MUSICAL INSTRUMENTS; INSTRUMENTS IN WHICH THE TONES ARE GENERATED BY ELECTROMECHANICAL MEANS OR ELECTRONIC GENERATORS, OR IN WHICH THE TONES ARE SYNTHESISED FROM A DATA STORE
    • G10H2240/00—Data organisation or data communication aspects, specifically adapted for electrophonic musical tools or instruments
    • G10H2240/171—Transmission of musical instrument data, control or status information; Transmission, remote access or control of music data for electrophonic musical instruments
    • G10H2240/281—Protocol or standard connector for transmission of analog or digital data to or from an electrophonic musical instrument
    • G10H2240/295—Packet switched network, e.g. token ring
    • G10H2240/305—Internet or TCP/IP protocol use for any electrophonic musical instrument data or musical parameter transmission purposes
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10H—ELECTROPHONIC MUSICAL INSTRUMENTS; INSTRUMENTS IN WHICH THE TONES ARE GENERATED BY ELECTROMECHANICAL MEANS OR ELECTRONIC GENERATORS, OR IN WHICH THE TONES ARE SYNTHESISED FROM A DATA STORE
    • G10H2240/00—Data organisation or data communication aspects, specifically adapted for electrophonic musical tools or instruments
    • G10H2240/171—Transmission of musical instrument data, control or status information; Transmission, remote access or control of music data for electrophonic musical instruments
    • G10H2240/281—Protocol or standard connector for transmission of analog or digital data to or from an electrophonic musical instrument
    • G10H2240/311—MIDI transmission
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10H—ELECTROPHONIC MUSICAL INSTRUMENTS; INSTRUMENTS IN WHICH THE TONES ARE GENERATED BY ELECTROMECHANICAL MEANS OR ELECTRONIC GENERATORS, OR IN WHICH THE TONES ARE SYNTHESISED FROM A DATA STORE
    • G10H2240/00—Data organisation or data communication aspects, specifically adapted for electrophonic musical tools or instruments
    • G10H2240/325—Synchronizing two or more audio tracks or files according to musical features or musical timings

Definitions

  • the present invention relates to a method for playing and editing audio data from at least two computer units via a packet-switched data network.
  • DE 697 10 569 T2 discloses a method for reproducing music in real time in a Glient server structure (multiple-node structure).
  • the method proposes, for so-called MIDI data, to provide control data for the generation of a musical tone, to break it up into data blocks, to generate a recovery data block for the recovery of the control data, to transmit the data block over a communication network and also to transmit the recovery data block over the communication network.
  • the driving data for a musical instrument is distributed through a server, which allows an audience with multiple listeners to follow a concert by producing music from the MIDI data from the control data at each listener.
  • MIDI data a sequential sequence number for the individual packets, which records the order of the packets and allows them to be rearranged after transmission.
  • This MIDI data also contains in its header time data indicating the music playing time of the subsequent MIDI data. The music playing time, together with the information about the size of the MIDI data, allows them to be played back at the intended speed.
  • DE 101 46 887 Al a method for the synchronization of digital data streams with audio data on two or more data processing devices is known. For this purpose, one of the data processing devices generates a control signal which describes an absolute time position in a data stream. In the known method, the data processing devices are connected directly to one another via an ASIO interface.
  • US 6,067,566 relates to a method of playing MIDI data streams while they are still being received.
  • Parser 207 reads event messages 117 and event data, each containing elapsed time descriptor 119.
  • the elapsed time refers in each case to the beginning of a track (see column 5, lines 40-43).
  • When playing n-tracks n-1 tracks are initially completely received and stored. The stored tracks, together with the not yet completely received If the track being played has reached the current position (SongPos 217) in the already stored tracks.
  • the invention has the technical object of providing a method with which audio data from remote computer units can be assembled in a timely manner. According to the invention the object is achieved by a method having the features of claim 1. Advantageous embodiments form the subject of the dependent claims.
  • the method relates to the playing and editing of audio data from at least two computer units via a packet-switched data network.
  • a peer-2-peer connection is established between the computer units.
  • a first computer unit receives audio data from, for example, an instrument or a microphone via an audio input.
  • the audio data of the first computer unit are assigned time marks.
  • a second computer unit which is connected to the first computer unit only via the data network, is initialized for playing back further audio data.
  • the other audio data is also provided with time stamps.
  • the audio data of the at least two computer units are buffered and assigned to each other based on their time stamps, so that a synchronous playback of the audio data is possible.
  • the inventive method allows a singer or musician to send audio data over a packet-switched data network and to play this synchronized with other audio data.
  • the participants can be located in separate locations.
  • delay over the data network the audio data is played synchronously with each other.
  • Timestamps are continuous sample numbers that refer to an initial time.
  • the sample accurate synchronization in the audio data provides a match in the range of 10 to 20 microseconds, depending on the sampling rate in the audio data.
  • the start time is set by the first computer unit. For this purpose, the start time of the audio data received by the computer unit is defined relative to the start time in the further audio data.
  • the further audio data are occupied on the second computer unit, where they are then combined with the reception of the audio data.
  • the inventive method is not limited to an additional data stream, but also several audio data, for example, the instruments of a band or an orchestra can be brought together according to the inventive method.
  • the microphone or the associated instruments are connected to the first computer unit and the received audio data recorded there after they have been provided with time stamps.
  • the other audio data in the first computer unit are played while at the same time the new audio data is recorded.
  • the audio data transmitted in the process may be present as audio, video and / or MIDI data.
  • Fig. 1 shows the synchronization of two time-shifted audio data.
  • FIG. 2 shows a basic structure of an instance used in the method.
  • Fig. 3 shows the communication path established in a connection.
  • Fig. 4 shows a schematic view of the data exchange in the synchronization.
  • the present invention relates to a method for the synchronization of audio data, so that musicians use the method via the Internet to contact each other and communicate via a direct data connection. who can make music. The cooperation takes place via a peer-2-peer connection with which several musicians can collaborate on time.
  • Fig. 1 shows a time series 10 corresponding to the data of the system A.
  • the system is switched by subscriber B to start.
  • the system B remains in the idle state and is only started with a start signal 14 at a later time 14. After the start signal 14, the individual samples are consecutively associated with each other within a packet.
  • the audio data is converted and output in synchronism with the timeline of B according to its time information.
  • the accuracy of the output corresponds approximately to a temporal resolution of a sample, ie approximately 10 to 20 microseconds.
  • the correspondence of the data enables, for example, musician and producer, although spatially separate, to work together within an authoring system, for example on a Digital Audio Workstation (DAW). With a corresponding transmission speed, recordings can also be made specifically in which a person comments on the received data. While the data is summarized in real time with existing audio data, the transmission delay of a few seconds, which still allow an interactive work.
  • the receiver B can also generate a control signal from the received data which it sends to a sequencer of the system A in order to start it automatically. Then system B is automatically started after A has been started and the two additional idle time steps 16 in FIG. 1 can be omitted.
  • DML Digital Musician Link
  • an audio input 18 and a video input 20 are provided.
  • Audio input 18 and video input 20 contain data from another subscriber 22 (peer).
  • the received input data are forwarded to two plug-in instances, as in the embodiment shown in FIG. For example, each instance can stand for one track during the recording.
  • the instances 24 and 26 use existing technology, for example for peer-2-peer communication.
  • the audio data and the video data of the inputs are applied to the instances 24 and 26, respectively.
  • video signals of a camera 26, which are likewise transmitted to the peer 22, are still present at the instances.
  • audio data is transmitted with a higher priority than video data.
  • the audio output 30 is forwarded to a peer 22, where it is then synchronized as described above.
  • additional periodic information can be exchanged between the parties in order to be able to adjust any differences in their systems.
  • the audio plug-in instances 24 and 26 are generally looped into the channels by a higher-level application, for example a sequencer or a DAW, the example shown in FIG. 2 is designed such that several instances of the DML plug-in application of FIG Users can be generated for each channel from which audio data is to be sent or received from the audio data.
  • a higher-level application for example a sequencer or a DAW
  • Fig. 3 shows an example of a user interface with such a plugin instance. Shown in FIG. 3 are the input data of a subscriber A at the input 32.
  • the incoming data including, for example, video data is displayed and played back in FIG. If it is determined via a selection 36 that the incoming data 32 should also be sent, they are processed in step 38 for transmission.
  • the processed data is sent to the second party where this data is displayed as audio data or as audio and video data in the output unit 40.
  • the audio data recorded by the second subscriber is sent as data 42 to the first subscriber and received via a unit 44.
  • the data of the receiving unit 44 are with the recorded end data 32 merged and forwarded as output data 46. To synchronize both data, the input data 32 is latched until the associated data 42 is received.
  • the above procedure offers the possibility of suppressing the transmission of the data (Mute On Play) by a corresponding setting in FIG.
  • This allows a kind of "talkback" functionality to be achieved so that the producer will not be audible to the singer or musician during recording, which may be annoying due to the time lag, and the user can also select whether to use the selection 48 (THRU) Alternatively, the input samples of the channel should be replaced by the received samples of the connected partner.
  • FIG. 2 provides that all plug-in instances 24 and 26 use a common object (DML network in FIG. 2).
  • the shared object holds all the streams of the sending plug-in instances together and send in these as a common stream. Likewise, received data streams are forwarded to all received instances.
  • the shared object also performs a similar function with respect to the video data that is not merged but is sent as a data stream from the camera. The user's own video data is also forwarded to the respective plug-in instances.
  • the video data is essentially synchronized like the audio data. That is, when both subscribers have started the transport system (see Fig. 3), the last-started user not only hears the audio data of the other subscriber (s) in sync with his timeline, but also sees the partner's camera synchronously with his or her time base is important for dance and ballet, for example.
  • Computer A is used by a producer and Computer B by a singer. Both have an instance of the plug-in looped into their microphone input channel. Both send and receive (talkback), the producer has activated "Mute On Play" 36. While idle, A and B can talk, and they both already have the same or a similar playback in their timeline project of the parent application.
  • Audio and video data is saved with the received timestamps.
  • His microphone samples continue to be suppressed, as the singer has progressed further. For example, if the producer cancels "Mute On Play,” he may ask to stop the recording, the producer will hear the singer in sync with the playback stored on his computer, and the video data will be played in sync with the playback stored at the producer.
  • the inventive method provides that, for example, a VMNAudioPacket is defined.
  • the samplePosition is defined as counter.
  • the samplePosition if the procedure is not running, indicates the current position on the time scale.
  • samplePosition specifies the position of the packet relative to a continuous (perpetual) counter. This continuous counter is defined by a specific start signal, the counter being set to 0 when the packet counter is set to 0.
  • the position of the packet is calculated.
  • FIG. 4 shows a computer 32 on which the synchronized audio data are output, for example, to a loudspeaker 34.
  • the audio data to be output is assembled sample-accurate in a memory 36.
  • the assembled data comes from further computer units 38, 40 and 42.
  • Each of the computers shown is connected via an audio input to a microphone 44 or a musical instrument.
  • the recorded audio data is provided with sample numbers and sent via a network 46 to the computer unit 32.
  • a data record which is referred to as further audio data, is sent from the computer 32 to the computers 38, 40, 42 at the beginning.
  • the other audio data 44 which may also be sent only with the beginning of the audio data to the other computer units, are located on the computer units, on the other Audio data is leaked before.
  • the beginning of this data defines the time origin from which the sample number is counted.
  • the further data 44 may be, for example, playback data. These are played on the computer units 38, 40 and 42, the recorded vocals or the instrument voices are then sent via the data network 46. In the computer 32, the received vocals sample is then reassembled with the playback data. This method achieves a very accurate match when playing the data.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Acoustics & Sound (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Electrophonic Musical Instruments (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Indexing, Searching, Synchronizing, And The Amount Of Synchronization Travel Of Record Carriers (AREA)

Abstract

Verfahren zum Abspielen und Bearbeiten von Audiodaten von mindestens zwei Rechnereinheiten über ein paketvermitteltes Datennetz, wobei mindestens eine erste Rechnereinheit über einen Audioeingang Audiodaten empfängt und an die zweite Rechnereinheit weiterleitet, das Verfahren weist folgende Schritte auf: die Audiodaten der ersten Rechnereinheit werden mit fortlaufenden Sample-Nummern versehen, die sich auf einen Anfangszeitpunkt beziehen, wobei der Anfangszeitpunkt durch die erste Rechnereinheit gesetzt wird, indem eine Kopie vom Anfang der weiteren Audiodaten an die erste Rechnereinheit übertragen und der Anfangszeitpunkt der Audiodaten der ersten Rechnereinheit bezogen auf den Anfangszeitpunkt der weiteren Audiodaten definiert wird; eine zweite Rechnereinheit wird zum Abspielen der weiteren Audiodaten initialisiert, die ebenfalls mit fortlaufenden Sample-Nummern versehen sind; in einem Speicher werden die Audiodaten der mindestens zwei Rechnereinheiten zwischengespeichert und über die Sample-Nummern einander zugeordnet.

Description

Verfahren zum Abspielen und Bearbeiten von Audiodaten von mindestens zwei Rechnereinheiten
Die vorliegende Erfindung betrifft ein Verfahren zum Abspielen und Bearbeiten von Audiodaten von mindestens zwei Rechnereinheiten über ein paketvermitteltes Datennetz.
Aus DE 697 10 569 T2 ist ein Verfahren zur Wiedergabe von Musik in Echtzeit bei einer Glient- Serverstruktur (Mehrfachknoten- Struktur) bekannt. Das Verfahren schlägt für sogenannte MIDI-Daten vor, Steuerdaten für die Erzeugung eines Musiktons vorzusehen, diese in Datenblöcke zu zerlegen, einen Rückgewinnungsdatenblock zur Rückgewinnung der Steuerdaten zu generieren, den Datenblock über ein Kommunikationsnetzwerk zu übertragen und den Rückgewinnungsdatenblock ebenfalls über das Kommunikationsnetzwerk zu übertragen. Bei dieser Client-Serverstruktur werden also die Ansteuerdaten für ein Musikinstrument über einen Server verteilt, der es einem Publikum mit mehreren Zuhörern ermöglicht einem Konzert zu folgen, indem aus den Steuerdaten bei jedem Zuhörer eine Musik aus den MIDI-Daten erzeugt wird. Ferner wird vorgeschlagen, den MIDI-Daten eine fortlaufende Sequenznummer für die einzelnen Pakete zuzuordnen, die die Reihenfolge der Pakete festhält und die erlaubt diese nach der Übertragung neu zu ordnen. Diese MIDI-Daten enthalten in ihrem Header auch Zeitdaten, die die Musikspielzeit der nachfolgenden MIDI-Daten angibt. Die Musikspielzeit erlaubt es, zusammen mit der Information über die Größe der MIDI-Daten, diese mit der vorgesehenen Geschwindigkeit abzuspielen. Aus DE 101 46 887 Al ist ein Verfahren zur Synchronisation von digitalen Datenströmen mit Audiodaten auf zwei oder mehreren Datenverarbeitungsgeräten bekannt. Hierzu generiert eines der Datenverarbeitungsgeräte ein Steuersignal, das eine absolute Zeitposition in einem Datenstrom beschreibt. Bei dem bekannten Verfahren sind die Datenverarbeitungsgeräte über eine ASIO- Schnittstelle direkt miteinander verbunden.
Aus US 6,175,872 Bl ist ein System zum Verwalten und Synchronisieren von MIDI-Daten bekannt. Die Rechner, die die durch ein Netzwerk ausgetauschten MIDI-Daten abspielen, sind relativ zu einer Normzeit (Standard clock) synchronisiert. Zur Synchronisation der MIDI-Daten wird an ein Paket eine Zeitmarke mit der absoluten Uhrzeit plus einer relativen Zeitverzögerung angehängt. Die relative Zeitverzögerung ergibt sich aus der Position des Rechners auf dem die Daten zum Abspielen vorgesehen sind.
US 6,067,566 betrifft ein Verfahren zum Abspielen von MIDI-Datenströmen, während diese noch empfangen werden. Hierzu wird vorgeschlagen, einen Parser 207 und einen Zeitumwandler 209 vorzusehen. Der Parser 207 liest Ereignisnachrichten 117 und Ereignisdaten, die jeweils Angabe zur verstrichenen Zeit (elapsed time descriptor 119) enthalten. Die verstrichene Zeit bezieht sich hierbei jeweils auf den Beginn einer Spur (vgl. Spalte 5, Zeile 40- 43). Beim Abspielen von Dateien mit mehreren MIDI-Spuren werden diese sequentiell nacheinander eingelesen. Beim Abspielen von n-Spuren werden n- 1 -Spuren zunächst vollständig empfangen und abgespeichert. Die abgespeicherten Spuren werden zusammen mit der noch nicht vollständig empfange- nen Spur abgespielt, wenn die abgespielte Spur die aktuelle Position (SongPos 217) in den bereits abgespeicherten Spuren erreicht hat.
Der Erfindung liegt die technische Aufgabe zugrunde ein Verfahren bereitzustellen, mit dem Audiodaten von entfernt liegenden Rechnereinheiten zeitgenau zusammengefügt werden können. Erfindungsgemäß wird die Aufgabe durch ein Verfahren mit den Merkmalen aus Anspruch 1 gelöst. Vorteilhafte Ausgestaltungen bilden die Gegenstände der Unteransprüche.
Das Verfahren bezieht sich auf das Abspielen und Bearbeiten von Audiodaten von mindestens zwei Rechnereinheiten über ein paketvermitteltes Datennetz. Dabei wird eine Peer-2-Peer Verbindung zwischen den Rechnereinheiten hergestellt. Bei dem erfindungsgemäßen Verfahren empfängt eine erste Rechnereinheit Audiodaten beispielsweise von einem Instrument oder einem Mikrofon über einen Audioeingang. Den Audiodaten der ersten Rechnereinheit werden Zeitmarken zugeordnet. Eine zweite Rechnereinheit, die nur über das Datennetz mit der ersten Rechnereinheit verbunden ist, wird zum Abspielen weiterer Audiodaten initialisiert. Die weiteren Audiodaten sind ebenfalls mit Zeitmarken versehen. In einem Speicher werden die Audiodaten der mindestens zwei Rechnereinheiten zwischengespeichert und anhand ihrer Zeitmarken einander zugeordnet, so daß ein synchrones Abspielen der Audiodaten möglich ist. Das erfindungsgemäße Verfahren erlaubt es, einem Sänger oder Musiker Audiodaten über ein paketvermitteltes Datennetz zu schicken und diese synchronisiert mit anderen Audiodaten abzuspielen. Hierdurch können beispielsweise bei Aufnahmen und bei der Bearbeitung von Audiodaten die Teilnehmer sich an getrennten Orten befinden, wobei trotz der Ver- zögerung über das Datennetz die Audiodaten synchron miteinander abgespielt werden. Als Zeitmarken sind fortlaufende Sample-Nurnmern vorgesehen, die sich auf einen Anfangszeitpunkt beziehen. Die samplegenaue Synchronisation in den Audiodaten liefert eine Übereinstimmung im Bereich von 10 bis 20 Mikrosekunden, abhängig von der Abtastrate in den Audiodaten. Der Anfangszeitpunkt wird durch die erste Rechnereinheit festgesetzt. Hierzu wird der Anfangszeitpunkt der von der Rechnereinheit empfangenen Audiodaten relativ zu dem Anfangszeitpunkt in den weiteren Audiodaten definiert. Um die Setzung des Anfangszeitpunkts genau durchführen zu können, befindet sich eine Kopie der weiteren Audiodaten auf der ersten Rechnereinheit. Unter Umständen kann hier auch vorgesehen sein, daß lediglich eine Kopie vom Anfang der weiteren Audiodaten vorliegt, so daß samplegenau die Audiodaten mit den weiteren Audiodaten abgestimmt werden können. Bevorzugt sind die weiteren Audiodaten auf der zweiten Rechnereinheit belegt, wo sie dann mit dem Empfang der Audiodaten zusammengeführt werden.
Als besonders hilfreich hat es sich erwiesen, zusammen mit den Audiodaten auch Informationen zu der Rechnereinheit aufzuzeichnen. Diese Informationen können dabei helfen, die Rechnereinheiten besser aufeinander abzustimmen.
Das erfindungsgemäße Verfahren ist nicht auf einen zusätzlichen Datenstrom beschränkt, vielmehr können auch mehrere Audiodaten beispielsweise die Instrumente einer Band oder eines Orchesters nach dem erfmdungsgemäßen Verfahren zusammengeführt werden. Gerade bei Gesang und/oder Instrumenten werden das Mikrofon oder die zugehörigen Instrumente mit der ersten Rechnereinheit verbunden und die empfangenen Audiodaten dort aufgezeichnet, nachdem sie mit Zeitmarken versehen wurden. Hierzu ist es besonders vorteilhaft, wenn auch die weiteren Audiodaten in der ersten Rechnereinheit abgespielt werden, während zugleich die neuen Audiodaten aufgenommen werden. Die Audiodaten, die bei dem Verfahren übertragen werden, können als Audio, Video und/oder MIDI-Daten vorliegen.
Das erfindungsgemäße Verfahren wird nachfolgend anhand eines Ausführungsbeispiels näher erläutert:
Fig. 1 zeigt die Synchronisation von zwei zeitlich versetzten Audiodaten.
Fig. 2 zeigt einen prinzipiellen Aufbau einer bei dem Verfahren verwendeten Instanz.
Fig. 3 zeigt den bei einer Verbindung aufgebauten Kommunikationspfad.
Fig. 4 zeigt eine schematische Ansicht des Datenaustauschs bei der Synchronisation.
Die vorliegende Erfindung betrifft ein Verfahren zur Synchronisation von Audiodaten, so daß Musiker mit Hilfe des Verfahrens über das Internet miteinander in Kontakt treten und über eine direkte Datenverbindung miteinan- der musizieren können. Die Zusammenarbeit erfolgt über eine Peer-2-Peer Verbindung mit dem mehrere Musiker zeitgenau zusammenarbeiten können.
Kernpunkt dieser Zusammenarbeit ist, daß Audiodaten der Teilnehmer miteinander synchronisiert werden. Bei dem Verfahren bringt der Teilnehmer A sein System in den Abspielmodus, dieser Zustand wird dann dem zweiten Teilnehmer B übermittelt. Von diesem Zeitpunkt an werden die vom Teilnehmer B empfangenen Daten nicht direkt zum Abspielen weitergeleitet, sondern solange zwischengespeichert, bis auch Teilnehmer B sein System in den Abspielzustand versetzt hat. Fig. 1 zeigt eine Zeitreihe 10, die den Daten des Systems A entspricht. Im Zeitpunkt 12 wird das System von Teilnehmer B auf Start geschaltet. Das System B bleibt weiterhin im Ruhezustand und wird erst mit einem Startsignal 14 zu einem späteren Zeitpunkt 14 gestartet. Nach dem Startsignal 14 sind die einzelnen Samples fortlaufend innerhalb eines Pakets einander zugeordnet. Nachdem auch das System B mit dem Startsignal 14 in seinen Abspielmodus versetzt wird, werden die Audiodaten gemäß ihrer Zeitinformation synchron zur Zeitleiste von B umgewandelt und ausgegeben. Die Genauigkeit beim Ausgeben entspricht ungefähr einer zeitlichen Auflösung eines Samples, also ungefähr 10 bis 20 Mikrosekunden. Die Übereinstimmung der Daten ermöglicht es, daß beispielsweise Musiker und Produzent, obwohl räumlich getrennt, innerhalb eines Authoring-Systems zusammen arbeiten, beispielsweise auf einer Digital Audio Workstation (DAW). Bei einer entsprechenden Übertragungsgeschwindigkeit, können gezielt auch Aufnahmen vorgenommen werden, bei denen eine Person die empfangenen Daten kommentiert. Während die Daten mit vorhandenen Audiodaten zeitgenau zusammengefaßt werden, erfolgt durch die Übertragung eine Ver- zögerung von wenigen Sekunden, die immer noch ein interaktives Arbeiten erlauben.
Zu einer möglichen Weiterentwicklung kann auch der Empfänger B aus den empfangenen Daten ein Steuersignal generieren, welches er an einen Sequen- cer des Systems A schickt, um diesen automatisch zu starten. Dann wird System B automatisch gestartet, nachdem A gestartet wurde und die beiden zusätzlichen Leerlaufzeitschritte 16 in Fig. 1 können entfallen.
Fig. 2 zeigt einen schematischen Aufbau in einem DML-Netzwerk im (DML = Digital Musician Link). Als eine erste Instanz sind ein Audioinput 18 und ein Videoinput 20 vorgesehen. Audioinput 18 und Videoinput 20 enthalten Daten von einem anderen Teilnehmer 22 (Peer). Die empfangenen Eingangsdaten werden wie in dem in Fig. 2 dargestellten Ausführungsbeispiel an zwei Plug-in Instanzen weitergeleitet. Jede Instanz kann beispielsweise für eine Spur bei der Aufzeichnung stehen. Die Instanzen 24 und 26 greifen auf bestehende Technik beispielsweise für die Peer-2-Peer Kommunikation zurück. Die Audiodaten und die Videodaten der Eingänge liegen jeweils an den Instanzen 24 und 26 an. Zusätzlich liegen an den Instanzen noch Videosignale einer Kamera 26 an, die ebenfalls an den Peer 22 übertragen werden. Hinsichtlich der Bandbreitenverteilung und Priorisierung des erfindungsgemäßen Verfahrens, werden Audiodaten mit einer höheren Priorität übertragen als Videodaten. Der Audio Output 30 wird an einen Peer 22 weitergeleitet, wo er dann wie vorstehend beschrieben synchronisiert wird. Zur Abstimmung des Abspielens an dem System hat es sich als hilfreich erwiesen, neben den Audiodaten, und möglicherweise Videodaten auch Daten zum Betriebszustand des Systems weiterzuleiten. Beispielsweise darüber, ob ein Transport gestartet wurde oder gerade aktuell der Stopmodus vorliegt. Ferner können zusätzlich periodisch Informationen zwischen den Beteiligten ausgetauscht werden, um eventuelle Unterschiede in ihren Systemen abgleichen zu können.
Da die Audio Plug-in Instanzen 24 und 26 von einer übergeordneten Anwendung, beispielsweise einem Sequencer oder einem DAW im allgemeinen in die Kanäle eingeschleift werden, ist das in Fig. 2 dargestellte Beispiel so ausgestaltet, daß mehrere Instanzen des DML Plug-in Applikation vom Benutzer erzeugt werden können und zwar für jeden Kanal, von dem aus Audio-Daten gesendet oder von dem Audio-Daten empfangen werden sollen.
Fig. 3 zeigt ein Beispiel für eine Benutzerschnittstelle mit einer solchen Plugin Instanz. In Fig. 3 dargestellt liegen die Eingangsdaten eines Teilnehmers A an dem Eingang 32 an. Die eingehenden Daten, die beispielsweise auch Videodaten enthalten, werden in 34 dargestellt und abgespielt. Sofern über eine Auswahl 36 festgelegt wird, daß die eingehenden Daten 32 auch gesendet werden sollen, werden diese in der Stufe 38 zum senden aufgearbeitet. Die aufgearbeiteten Daten werden an den zweiten Teilnehmer gesendet, wo diese Daten, als Audiodaten oder als Audio- und Videodaten in der Ausgabeeinheit 40 dargestellt werden. Die von dem zweiten Teilnehmer aufgenommenen Audiodaten werden als Daten 42 an den ersten Teilnehmer gesendet und über eine Einheit 44 empfangen. Die Daten der Empfangseinheit 44 werden mit den aufgenommenen Enddaten 32 zusammengeführt und als Ausgangsdaten 46 weitergeleitet. Zur Synchronisation beider Daten, werden die Eingangsdaten 32 zwischengespeichert, bis die zugeordneten Daten 42 empfangen wurden.
Der vorstehende Ablauf bietet die Möglichkeit, durch eine entsprechende Einstellung in 36 das Senden der Daten zu unterdrücken (Mute On Play). Hierdurch kann eine Art „talkback" Funktionalität erzielt werden, damit der Produzent nicht während der Aufnahme für den Sänger oder Musiker hörbar ist, was aufgrund der zeitlichen Verzögerung störend sein kann. Über die Auswahl 48 (THRU) kann der Benutzer ebenfalls einstellen, ob ein zusendender Kanal selbst gehört werden soll. Alternativ können die Eingangs-Samples des Kanals durch die empfangenen Samples des verbundenen Partners ersetzt werden soll.
Über den Auswahlschalter 48 wird also ausgewählt, ob die ursprünglich aufgenommenen Daten 32 unverändert direkt abgespielt werden sollen, oder ob diese Daten synchronisiert mit an den Daten des zweiten Teilnehmers 40 abgespielt werden sollen. Ist beispielsweise über den Auswahlschalter 36 ausgewählt, daß die eingehenden Audiodaten 32 nicht gesendet werden soll, so kann in Stufe 38 immer noch Signale zur Synchronisation des Abspielens mit beispielsweise Videodaten vorgenommen werden.
Das in den Fig. 2 dargestellte Konzept sieht vor, daß alle Plug-In-Instanzen 24 und 26 ein gemeinsames Objekt verwenden (DML Network in Fig. 2). Das gemeinsame Objekt faßt alle Ströme der sendenden Plug-In-Instanzen zusammen und sendet in diese als einen gemeinsamen Strom. Ebenso werden empfangene Datenströme an alle empfangenen Instanzen weitergeleitet. Eine ähnliche Funktion erfüllt das gemeinsame Objekt im Hinblick auch auf die Videodaten, die nicht zusammengefügt werden, sondern als Datenstrom von der Kamera gesendet werden. Die eigenen Videodaten des Benutzers werden ebenfalls an die jeweiligen Plug-In-Instanzen weitergeleitet.
Die Videodaten werden im Kern wie die Audiodaten synchronisiert. Das heißt, wenn beide Teilnehmer das Transportsystem gestartet haben (vergl. Fig. 3), hört der zuletzt gestartete Benutzer nicht nur die Audiodaten des oder der anderen Teilnehmer synchron mit seiner Zeitleiste, sondern sieht auch die Kamera des Partners synchron zu seiner Zeitbasis, dieses ist beispielsweise für Tanz und Ballett wichtig.
Das erfindungsgemäße Verfahren sei nachfolgend an einem Beispiel erläutert:
Computer A wird von einem Produzenten benutzt und Computer B von einem Sänger. Beide haben eine Instanz des Plug-in in ihren Mikrofon-Eingangs- Kanal eingeschleift. Beide senden und empfangen (talkback), der Produzent hat „Mute On Play" 36 aktiviert. Im Ruhezustand können A und B sich unterhalten. Beide haben außerdem schon ein gleiches oder ein ähnliches Playback in ihrem Zeitleistenprojekt der übergeordneten Applikation.
Der Sänger startet den Verbindungsaufbau auf seinem Computer und beginnt zu seinem Playback zu singen. Auf der Seite des Produzenten (Computer A) geschieht folgendes: Die Daten seines Mikrofonkanals werden nicht mehr gesendet (Mute On
Play), um den Sänger nicht zu stören. Das Videobild des Sängers steht, der Produzent hört den Sänger nicht mehr,
Audio- und Videodaten werden mit den empfangenen Zeitmarken gespeichert.
Nun startet der Produzent seinerseits seinen Sequencer, wie bereits erwähnt, kann dies auch automatisch erfolgen. Der Sequencer des Produzenten nimmt nun auf, wobei für den Produzenten folgendes gilt:
Seine Mikrofon-Samples werden weiterhin unterdrückt, da der Sänger mittlerweile weiter vorangekommen ist. Lediglich wenn der Produzent auch „Mute On Play" aufhebt kann er beispielsweise zum Abbruch der Aufnahme auffordern. Der Produzent hört den Sänger synchron zu dem auf seinem Rechner gespeicherten Playback. Ferner werden die Videodaten synchron mit dem beim Produzenten gespeicherten Playback abgespielt.
Wenn beispielsweise an die Stelle des Sängers ein Instrumentalist tritt, kann für diesen eine zweite Instanz des Plug-in in den Gitarrenkanal eingeschleift sein. Es würde dann ein Mikrofonkanal für Sprache und Talkback vorgesehen sein, in dem während der Aufnahme ebenfalls „Mute On Play" eingeschaltet ist, damit der Produzent während der Aufnahme nur digital hört. Der Gitarrenkanal ist über TRANSMIT definiert. In der Umsetzung sieht das erfindungsgemäße Verfahren vor, daß beispielsweise ein VMNAudioPacket definiert ist. In dem AudioPacket ist als Zähler die samplePosition definiert. Die samplePosition gibt, wenn das Verfahren nicht läuft die aktuelle Position auf der Zeitskala an. Wenn das Projekt läuft, gibt samplePosition die Position des Packets relativ zu einem fortlaufenden (ewigen) Zähler an. Dieser fortlaufende Zähler wird über einen spezifisches Startsignal definiert, wobei der Zähler auf 0 gesetzt wird, wenn der Packet- zähler auf 0 gesetzt ist. Je nach Betriebsmodus des Verfahrens wird also die Position des Packets berechnet.
Unter Einbeziehung des Datenaustauschs für die Synchronisation der Datenströme stellt sich dem Verfahren wie folgt dar:
In Fig. 4 dargestellt ist ein Rechner 32, an dem die synchronisierten Audiodaten beispielsweise an einen Lautsprecher 34 ausgegeben werden. Die auszugebenden Audio-Daten werden in einem Speicher 36 samplegenau zusammenfügt. Die zusammengefügten Daten stammen von weiteren Rechnereinheiten 38, 40 und 42. Jeder der dargestellten Rechner ist über einen Audioeingang mit einem Mikrophon 44 oder einem Musikinstrument verbunden. Die aufgezeichneten Audio-Daten werden mit Sample-Nummern versehen und über ein Netzwerk 46 an die Rechnereinheit 32 gesendet. Zur Initialisierung der Rechnereinheiten 38, 40 und 42 wird zu Beginn ein Datensatz, der als weitere Audio-Daten bezeichnet wird, von dem Rechner 32 an die Rechner 38, 40, 42 geschickt. Die weiteren Audio-Daten 44, die möglicherweise auch nur mit dem Beginn der Audio-Daten an die übrigen Rechnereinheiten geschickt werden, liegen auf den Rechnereinheiten, über die die weiteren Audio-Daten zugespielt werden vor. Der Anfang dieser Daten definiert den Zeitursprung, von dem ab die Sample-Nummer gezählt wird. Bei den weiteren Daten 44 kann es sich beispielsweise um Playback-Daten handeln. Diese werden auf den Rechnereinheiten 38, 40 und 42 abgespielt, der dazu aufgenommene Gesang oder die Instrumentenstimmen werden dann über das Datennetz 46 verschickt. In dem Rechner 32 wird dann der empfangene Gesang samplegenau mit den Playback-Daten wieder zusammengesetzt. Durch dieses Verfahren wird eine sehr genaue Übereinstimmung beim Abspielen der Daten erzielt.

Claims

Ansprüche:
1. Verfahren zum Abspielen und Bearbeiten von Audiodaten von mindestens zwei Rechnereinheiten über ein paketvermitteltes Datennetz, wobei mindestens eine erste Rechnereinheit über einen Audioeingang Audiodaten empfängt und an die zweite Rechnereinheit weiterleitet, das Verfahren weist folgende Schritte auf:
- die Audiodaten der ersten Rechnereinheit werden mit fortlaufenden Sample-Nummern versehen, die sich auf einen Anfangszeitpunkt beziehen, wobei der Anfangszeitpunkt durch die erste Rechnereinheit gesetzt wird, indem eine Kopie vom Anfang der weiteren Audiodaten an die erste Rechnereinheit übertragen und der Anfangszeitpunkt der Audiodaten der ersten Rechnereinheit bezogen auf den Anfangszeitpunkt der weiteren Audiodaten definiert wird,
- eine zweite Rechnereinheit wird zum Abspielen der weiteren Audiodaten initialisiert, die ebenfalls mit fortlaufenden Sample- Nummern versehen sind,
- in einem Speicher werden die Audiodaten der mindestens zwei Rechnereinheiten zwischengespeichert und über die Sample- Nummern einander zugeordnet.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die weiteren Audiodaten auf der zweiten Rechnereinheit abgelegt sind.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, daß die weiteren Audiodaten von der ersten Rechnereinheit an die zweite Rechnereinheit gesendet werden.
4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daß mit den Audiodaten Informationen zu dem Betriebszustand der Rechner aufgezeichnet werden.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß von mehr als zwei Rechnereinheiten Audiodaten zusammengeführt werden.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, daß auf den Rechnereinheiten eine Sequencersoftware vorgesehen ist, die eine Bearbeitung der Audiodaten erlaubt.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß die erste Rechnereinheit die Audiodaten von einem Mikrophon und/oder einem Instrument empfängt, das mit der Rechnereinheit verbunden ist.
8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, daß die erste Rechnereinheit die weiteren Audiodaten abspielt, während die Audiodaten empfangen werden.
PCT/EP2006/001252 2005-02-12 2006-02-10 Verfahren zum abspielen und bearbeiten von audiodaten von mindestens zwei rechnereinheiten WO2006084747A2 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US11/815,999 US20080140238A1 (en) 2005-02-12 2006-02-10 Method for Playing and Processing Audio Data of at Least Two Computer Units
EP06706872A EP1847047A2 (de) 2005-02-12 2006-02-10 Verfahren zum abspielen und bearbeiten von audiodaten von mindestens zwei rechnereinheiten

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102005006487.6 2005-02-12
DE102005006487A DE102005006487A1 (de) 2005-02-12 2005-02-12 Verfahren zum Abspielen und Bearbeiten von Audiodaten von mindestens zwei Rechnereinheiten

Publications (2)

Publication Number Publication Date
WO2006084747A2 true WO2006084747A2 (de) 2006-08-17
WO2006084747A3 WO2006084747A3 (de) 2007-09-07

Family

ID=36658751

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2006/001252 WO2006084747A2 (de) 2005-02-12 2006-02-10 Verfahren zum abspielen und bearbeiten von audiodaten von mindestens zwei rechnereinheiten

Country Status (4)

Country Link
US (1) US20080140238A1 (de)
EP (1) EP1847047A2 (de)
DE (1) DE102005006487A1 (de)
WO (1) WO2006084747A2 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9646587B1 (en) * 2016-03-09 2017-05-09 Disney Enterprises, Inc. Rhythm-based musical game for generative group composition
US10460743B2 (en) * 2017-01-05 2019-10-29 Hallmark Cards, Incorporated Low-power convenient system for capturing a sound

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10146887A1 (de) * 2001-09-24 2003-04-30 Steinberg Media Technologies A Vorrichtung und Verfahren zur Synchronisation von digitalen Datenströmen

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6067566A (en) * 1996-09-20 2000-05-23 Laboratory Technologies Corporation Methods and apparatus for distributing live performances on MIDI devices via a non-real-time network protocol
US6175872B1 (en) * 1997-12-12 2001-01-16 Gte Internetworking Incorporated Collaborative environment for syncronizing audio from remote devices
JP3889919B2 (ja) * 2000-08-31 2007-03-07 株式会社日立製作所 情報配信方法、情報受信方法、情報配信システム、情報配信装置、受信端末及び記憶媒体
US7346698B2 (en) * 2000-12-20 2008-03-18 G. W. Hannaway & Associates Webcasting method and system for time-based synchronization of multiple, independent media streams
JP4423790B2 (ja) * 2001-01-11 2010-03-03 ソニー株式会社 実演システム、ネットワークを介した実演方法
US20050120391A1 (en) * 2003-12-02 2005-06-02 Quadrock Communications, Inc. System and method for generation of interactive TV content

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10146887A1 (de) * 2001-09-24 2003-04-30 Steinberg Media Technologies A Vorrichtung und Verfahren zur Synchronisation von digitalen Datenströmen

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1847047A2 *

Also Published As

Publication number Publication date
DE102005006487A1 (de) 2006-08-24
WO2006084747A3 (de) 2007-09-07
US20080140238A1 (en) 2008-06-12
EP1847047A2 (de) 2007-10-24

Similar Documents

Publication Publication Date Title
EP1794564B1 (de) Vorrichtung und verfahren zum synchronisieren von zusatzdaten und basisdaten
DE60211157T2 (de) Synchrones Abspielen von Medien-Paketen
DE69925004T2 (de) Kommunikationsverwaltungssystem für computernetzwerkgestützte telefone
DE60210671T2 (de) Freier zugang zu ip video-inhalt für mhp digitale anwendungen
US20020091658A1 (en) Multimedia electronic education system and method
DE102009059167B4 (de) Mischpultsystem und Verfahren zur Erzeugung einer Vielzahl von Mischsummensignalen
EP0765547B1 (de) Verfahren zur übertragung digitaler audiodaten und als datenpakete übertragener zusatzdaten
DE3820835A1 (de) Konzeption einer netzwerkfaehigen, volldigitalen hifi-videoanlage
CN108616800A (zh) 音频的播放方法和装置、存储介质、电子装置
DE60116341T2 (de) Kommunikationsverwaltungsystem für computernetzbasierte telefone
DE602004009560T2 (de) Datenübertragungssynchronisationsschema
EP0725522A2 (de) Verfahren zur gemeinsamen Übertragung von Quell- und Steuerdaten zwischen über Datenleitungen verbundenen Datenquellen und -senken
EP1869860B1 (de) Verfahren zum synchronisieren von inhaltsbezogenen datensegmenten von dateien
WO2006084747A2 (de) Verfahren zum abspielen und bearbeiten von audiodaten von mindestens zwei rechnereinheiten
DE69432631T2 (de) Multiplexieren in einem System zur Kompression und Expandierung von Daten
EP2090115A2 (de) Verfahren zur synchronisierung von szene-datenfiles und mediendatenströmen in einem unidirektionalen datenübertragungssystem
DE10146887B4 (de) Vorrichtung und Verfahren zur Synchronisation von digitalen Datenströmen
DE102006036562B4 (de) Verfahren und System zum Übertragen aufeinander bezogener Datenströme oder/und zum Synchronisieren aufeinander bezogener Datenströme
EP3729817A1 (de) Verfahren zum synchronisieren von einem zusatzsignal zu einem hauptsignal
EP0725518B1 (de) Verfahren zur gemeinsamen Übertragung von digitalen Quell- und Steuerdaten zwischen über Datenleitungen verbundenen Datenquellen und -senken
EP0095178B1 (de) Verfahren zum Protokollieren der in einer elektroakustischen Diskussionsanlage Übertragenen Sprechbeiträge
AT520998B1 (de) Verfahren zum Synchronisieren von einem Zusatzsignal zu einem Hauptsignal
EP1168829A2 (de) Verfahren zur Durchführung von Livesendungen mit Bildeinspielung
DE19940928B4 (de) Einrichtung und Verfahren zum Empfang und zur Weiterverarbeitung eines Paketes komprimierter Daten
DE102006002061B4 (de) Verfahren zum Empfangen, zum Senden sowie zum Übertragen, Sende- sowie Empfangsanordnung und System aus Sende- und Empfangsanordnung

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2006706872

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 11815999

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 2006706872

Country of ref document: EP