Subject: [siprec] Sample synchronisation of multiple media streams

From: "Dave Higton" <[email-masked]>
Date: Wed, 16 Jan 2013 17:01:51 +0000

Does SIPREC provide any means to synchronise media streams from multiple sources?

In case there's anyone reading who isn't aware of the consequences:

Sometimes media streams can arrived from separate physical sources but have common content, e.g. a radio signal picked up by two receivers, and be recorded as separate streams.  Sometimes users wish to replay these streams simultaneously, mixed.  In the case of audio streams, unless they are perfectly synchronised, this causes a comb filter.  For short delays, it can sound rather like talking down a drainpipe; for longer delays, there is an echo.

It is highly desirable to have some means to synchronise multiple streams, preferably to one sample.

The subject of whether users are misguided in wanting to replay audio like this, is a separate debate.

Dave

NICE Systems UK Limited ("NICE") is registered in England under company number, 3403044. The registered office of NICE is at Tollbar Way, Hedge End, Southampton, Hampshire SO30 2ZP.

Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately.

Monitoring: NICE may monitor incoming and outgoing e-mails.

Viruses: Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 16 Jan 2013 21:16:24 +0000

Hi David,

If the media streams are synchronized within the CS, then they should be synchronized in the RS as well. However, it sounds as if you are referring to media streams that are not synchronized in the CS. In that case, I see a few alternatives:
1) SRC detects duplicate streams and includes only one in RS
2) SRC detects duplication streams and includes metadata for each such that the duplication is evident
3) SRC does not detect duplication and synchronization is based on wall clock, which is included per stream in metadata

I believe SIPREC today supports all of these options. SIPREC does not mandate that a SRC be able to detect duplicate streams but it provides mechanisms for the SRC to enhance the RS in the case it does.

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dave Higton
> Sent: Wednesday, January 16, 2013 9:02 AM
> To: [email-masked]
> Subject: [siprec] Sample synchronisation of multiple media streams
> 
> Sometimes media streams can arrived from separate physical sources but
> have common content, e.g. a radio signal picked up by two receivers, and be
> recorded as separate streams.  Sometimes users wish to replay these
> streams simultaneously, mixed.  In the case of audio streams, unless they
> are perfectly synchronised, this causes a comb filter.  For short delays, it can
> sound rather like talking down a drainpipe; for longer delays, there is an
> echo.
> 
> 
> 
> NICE Systems UK Limited ("NICE") is registered in England under company
> number, 3403044. The registered office of NICE is at Tollbar Way, Hedge End,
> Southampton, Hampshire SO30 2ZP.
> 
> Confidentiality: This communication and any attachments are intended for
> the above-named persons only and may be confidential and/or legally
> privileged. Any opinions expressed in this communication are not
> necessarily those of NICE. If this communication has come to you in error
> you must take no action based on it, nor must you copy or show it to
> anyone; please delete/destroy and inform the sender by e-mail
> immediately.
> 
> Viruses: Although we have taken steps toward ensuring that this e-mail and
> attachments are free from any virus, we advise that in keeping with good
> computing practice the recipient should ensure they are actually virus free.