Subject: RE: [AVT] AVT IETF 70 minutes

From: "BABONNEAU Gerard RD-MAPS-REN" <[email-masked]>
Date: Wed, 9 Jan 2008 10:19:48 +0100

Hi,

I have some questions on behalf of peoples (CC) involved in a french project (called Scalim@ges) around transport and description of SVC.

After reading minutes of the 70th IETF meeting, I have some trouble with the position on Colin Perkin.
 
I agree with him that it is necessary to conform the requirements of RTP to have random TimeStamps for each session.
- I see an advantage, specialy in case of SRTP because using the same timestamp for all session may help some malicious people to discover a relation between sessions to discover the encryption key.
- RTF 3550 specify "The initial value of the timestamp SHOULD be random" on page 15, but "should" does not mean it is mandatory.
- From another point of view, RFC3550 specifies that "the timstamps reflects the sampling instant of the first octet in the RTP data packet". Since all NALUs that belong to an AU share the same timestamp as they come from the same media/content, encoded by the same encoder, each session containing data packets coming from the same SVC stream should share the same timestamp base.
 
Consequently, no CL-mode is possible in both cases either with a common TimeStamp or with RTCP/SR/NTP to synchronize sessions. As said Colin, it is easy to send an SR per session before starting a unicast VOD. But the problem is fussy about multicast IPTV programs, because the main challenge for all the video provider is to reduce the zapping latency. Lots of efforts aims to gain hundreds of milliseconds, and a new service that adds seconds of latency (to synchronize SR) is not credible. The risk could be the burying of SVC for such kinds of services.
 
I believe that both processing for TS may be usefull according to services. I suggest to define an additional field in the SDP to precise that RTP session share the same TS (per default, the synchronization use RTCP/SR); may be:
        a=fmtp: share-ts=1 
 
Moreover, to allow RTCP SR based synchronisation, I would replace the second MUST by SHALL in current 05 draft section 7.I.d: "All RTP sessions MUST use the same RTP Timestamp scale and SHALL use the same RTP timestamp for packets in the different RTP session containing NAL units of the same sampling time instance."
 
 Have other people an opinion on this?

About non CL-DON mode, RFC 3984 is very clear for me as long as the SVC compatibility must be. From the RFC:
- "6.2.  Single NAL Unit Mode .......  All receivers MUST support this mode."
- "6.3.  Non-Interleaved Mode ........ .  This mode SHOULD be supported. "
- "6.4.  Interleaved Mode ....... .  Some receivers MAY support this mode.  "
In my understanding it is obvious that the same specifications must apply to SVC payload, and there is no question about the validity of the non CL-DON mode, particulary since the draft well demontrate that synchronization is possible.
 
I understand that MANE is a very fine concept for the future, but certainly SVC services will start with basic modes and simple receivers. So packetization modes 0 and 1 without CL-DON will be necessary in a first time. 

I think also that this draft needs a very large open-mindedness because we each have some ideas on possible applications for SVC, but I am not shure we have discover which will be the most successful in the future.
 
Another suggestion: (part 5.1.2) local definition are ambiguous. In my thought, I defined some terms more appropriate. Why not "Base RTP session" and "enhancement RTP session" ...., in order to reserve layers to encoding. In fact, you define that one or many layers are encapsulated in an RTP session.
 
Best regards,

Gérard Babonneau
FT/RD/MAPS/DPC/APA
IG RD   AV services and transport protocols
tél. (33)2 99 12 40 08
[email-masked]

-----Message d'origine-----
De : Tom Taylor [mailto:[email-masked]] 
Envoyé : vendredi 4 janvier 2008 04:54
À : IETF AVT WG; Colin Perkins; Roni Even
Objet : [AVT] AVT IETF 70 minutes

Please find the minutes attached. Thanks to Alan Clark and Stephen Casner for their note taking.

Tom Taylor

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Wed, 9 Jan 2008 14:09:42 +0000

Gerard,

The issue with start-up latency, waiting to receive the first RTCP SR  
packet sent to a multicast group, is a general limitation of RTP, and  
not something specific to the SVC payload format. Accordingly, if  
it's becoming a problem, it should be solved in a general manner, not  
as part of the SVC payload format specification.

Use the existing mechanisms: don't try to reinvent them for each new  
payload format.

Colin

On 9 Jan 2008, at 09:19, BABONNEAU Gerard RD-MAPS-REN wrote:
> I have some questions on behalf of peoples (CC) involved in a  
> french project (called Scalim@ges) around transport and description  
> of SVC.
>
> I agree with him that it is necessary to conform the requirements  
> of RTP to have random TimeStamps for each session.
> - I see an advantage, specialy in case of SRTP because using the  
> same timestamp for all session may help some malicious people to  
> discover a relation between sessions to discover the encryption key.
> - RTF 3550 specify "The initial value of the timestamp SHOULD be  
> random" on page 15, but "should" does not mean it is mandatory.
> - From another point of view, RFC3550 specifies that "the timstamps  
> reflects the sampling instant of the first octet in the RTP data  
> packet". Since all NALUs that belong to an AU share the same  
> timestamp as they come from the same media/content, encoded by the  
> same encoder, each session containing data packets coming from the  
> same SVC stream should share the same timestamp base.
>
> Consequently, no CL-mode is possible in both cases either with a  
> common TimeStamp or with RTCP/SR/NTP to synchronize sessions. As  
> said Colin, it is easy to send an SR per session before starting a  
> unicast VOD. But the problem is fussy about multicast IPTV  
> programs, because the main challenge for all the video provider is  
> to reduce the zapping latency. Lots of efforts aims to gain  
> hundreds of milliseconds, and a new service that adds seconds of  
> latency (to synchronize SR) is not credible. The risk could be the  
> burying of SVC for such kinds of services.
>
> I believe that both processing for TS may be usefull according to  
> services. I suggest to define an additional field in the SDP to  
> precise that RTP session share the same TS (per default, the  
> synchronization use RTCP/SR); may be:
>         a=fmtp: share-ts=1
>
> Moreover, to allow RTCP SR based synchronisation, I would replace  
> the second MUST by SHALL in current 05 draft section 7.I.d: "All  
> RTP sessions MUST use the same RTP Timestamp scale and SHALL use  
> the same RTP timestamp for packets in the different RTP session  
> containing NAL units of the same sampling time instance."
>
> In my understanding it is obvious that the same specifications must  
> apply to SVC payload, and there is no question about the validity  
> of the non CL-DON mode, particulary since the draft well demontrate  
> that synchronization is possible.
>
> I understand that MANE is a very fine concept for the future, but  
> certainly SVC services will start with basic modes and simple  
> receivers. So packetization modes 0 and 1 without CL-DON will be  
> necessary in a first time.
>
> I think also that this draft needs a very large open-mindedness  
> because we each have some ideas on possible applications for SVC,  
> but I am not shure we have discover which will be the most  
> successful in the future.
>
> Another suggestion: (part 5.1.2) local definition are ambiguous. In  
> my thought, I defined some terms more appropriate. Why not "Base  
> RTP session" and "enhancement RTP session" ...., in order to  
> reserve layers to encoding. In fact, you define that one or many  
> layers are encapsulated in an RTP session.
>
> Best regards,
>
>
>
>
> Gérard Babonneau
> FT/RD/MAPS/DPC/APA

-- 
Colin Perkins
http://csperkins.org/

---

From: Randell Jesup <[email-masked]>
Date: Mon, 14 Jan 2008 10:20:53 -0500

Colin Perkins <[email-masked]> writes:
>packet sent to a multicast group, is a general limitation of RTP, and  not
>something specific to the SVC payload format. Accordingly, if  it's
>becoming a problem, it should be solved in a general manner, not  as part
>of the SVC payload format specification.
>

I agree - but that means someone has to generalize a solution to startup
latency, and that might not be feasible without a significant change to the
architecture of RTP/RTCP, or without a very large shoehorn.

No one has put forward a general solution, and unless/until someone does
we'll see this happen again and again.

As I see it, there are two primary issues here:
1) Delay between start of stream reception and getting TS<->NTP mappings
   for that stream.  (I.e. current RTCP reception delay.)
2) Delay in getting cross-stream synchronization (currently, occurs once
   all streams have passed case 1 and have valid NTP mappings).

These are complicated by RTCP bandwidth and timing issues in multicast
sessions, though that's just a matter of degree.

Case 1 is affected by fundamentals of RTP/RTCP design: first that RTCP are
unreliable, and second that the timings for RTCP AVP mean that a
lost/missed RTCP packet means a 2.5-7.5 second delay before the next one,
or longer.  AVPF can certainly help this, if bandwidth doesn't become an
issue and if the sender knows it's a "good time" to send extra/early RTCP
(like when it knows a listener just joined).  The separation of RTP from
RTCP on differnt ports can add to the problem in some cases, since they
might take different paths or RTCP might be blocked (by a firewall/router).

One thing for people to remember when trying to solve this problem (SVC
people for example) is that part of the reason for using RTCP/NTP for
synchronizing channels is that the streams might come from different
sources, and still need to be synchronized (think multiple microphones, or
multiple cameras at a game, or a conference call).  That doesn't mean you
can't design something that can improve on the current solution, but that
you need to think about other cases and if possible find a way to help them
as well.

As for solutions to the problem I've laid out....  I don't know.  Solutions
that fit in the current framework all have issues; solving this problem
*might* require something outside of what RFC 3550 envisions/allows.

Possibilities:

* Signal initial Timestamp->NTP mappings for streams
  This may have the most possible wins and least downside, but it's not
  without serious issues.  It preserves the security aspects of random
  timestamps (not that they're huge), and is backwards-compatible.  It
  allows first-packet synchronization in many cases.

  Downsides:
  * If you signal it as a sender (I'll send with this mapping), then
    you have issues with conferences (need multiple mappings by sender
    SSRC/etc in the signaling), and you can still have an unsynchronized
    period if a 200 OK is lost, for example.
  * If you signal it as a receiver, then there are compatibility issues and
    there are some issues with multiple senders.  It probably won't work in
    any multicast setup (true or pseudo).  To handle the multiple streams
    and non-multicast multiple senders:
    * Have all the streams use the same TS<->NTP mapping.  This might have
      security or other downsides.  Comments?
    * Have each sender use the TS<->NTP mapping provided by the receiver
      with some type of hashing function to generate a TS<->NTP mapping
      based on their SSRC value. 

* Implictly synchronized streams
  This is what some SVC people have proposed, where the inter-stream
  synchronization is implicit in the timestamps.  The advantage again is
  compatibility (may not matter) and conciseness.

  Downsides:
  * Only can work for single-source sets of streams.  This may make it
    non-viable for some conferencing situations.
  * Provides only inter-stream sync - though the advantage is that a single
    RTCP for any of the TS-synced streams would sync all of them to NTP
    implicitly.
  * May cause security issues (I'm not really sure of this, and I don't
    think it's a significant issue in practice, but some real crypto mavens
    should vet that).  I *suspect* we're ok if the starting point is still
    random.
  * Requires some type of signaling of the relationship between the
    streams.  This could be implicit in an SVC-only solution, but would
    probably need to be explicit in a general solution.

Others?

>> Consequently, no CL-mode is possible in both cases either with a  common
>> TimeStamp or with RTCP/SR/NTP to synchronize sessions. As  said Colin, it
>> is easy to send an SR per session before starting a  unicast VOD. But the
>> problem is fussy about multicast IPTV  programs, because the main
>> challenge for all the video provider is  to reduce the zapping
>> latency. Lots of efforts aims to gain  hundreds of milliseconds, and a
>> new service that adds seconds of  latency (to synchronize SR) is not
>> credible. The risk could be the  burying of SVC for such kinds of
>> services.
>>
>> services. I suggest to define an additional field in the SDP to  precise
>> that RTP session share the same TS (per default, the  synchronization use
>> RTCP/SR); may be:
>>         a=fmtp: share-ts=1
>>
>> Moreover, to allow RTCP SR based synchronisation, I would replace  the
>> second MUST by SHALL in current 05 draft section 7.I.d: "All  RTP
>> sessions MUST use the same RTP Timestamp scale and SHALL use  the same
>> RTP timestamp for packets in the different RTP session  containing NAL
>> units of the same sampling time instance."
>>
-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: "Jonathan Lennox" <[email-masked]>
Date: Tue, 15 Jan 2008 11:28:32 -0500

Randell Jesup writes:

> 1) Delay between start of stream reception and getting TS<->NTP
>    mappings for that stream.  (I.e. current RTCP reception delay.)
> 2) Delay in getting cross-stream synchronization (currently, occurs
>    once all streams have passed case 1 and have valid NTP mappings).

There's actually a third issue: stability of the TS<->NTP mapping.  Some
initial experiments on Windows XP (with NTP timestamps derived from
GetSystemTimeAsFileTime(), and RTP timestamps from
QueryPerformanceCounter()) indicate that this can vary by as much as
30-40 ms in the worst case.  (Source code is available on request.)

For audio/video synchronization, this arguably isn't so crucial, since
the speed of sound inherently limits synchronization anyway.  (Sound
travels at just over 1 foot per millisecond in air, so light from an
event 10 feet away will arrive 10 ms before the sound from the event.)
Furthermore, without fairly heroic hardware and system engineering, it's
not really possible to say that a particular set of photons arrived at
your CCD at the same instant as a particular sound wave arrived at your
microphone -- this is why professional video production uses
clapperboards.

However, for session-multiplexed layered codecs (both for SVC, which I'm
more familiar with, and for the various layered audio codecs being
developed), correct decoding requires not just approximate session
synchronization, but that decoders be able to associate correctly and
reliably the packets that encode various portions of an original source
sample.  This requires that any error in timestamp precision must be
significantly less than the inter-packet interval.

I believe that this case -- multiple cross-session encodings of a single
original source sample, that need to be associated by decoders --
addresses all the uses cases presented recently, and I think that
designing a mechanism that handles this case is much more tractable than
trying to improve the general TS<->NTP association problem.

-- 
Jonathan Lennox
Vidyo, Inc (formerly Layered Media)
[email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Tue, 15 Jan 2008 17:29:49 +0000

Jonathan,

> 30-40 ms in the worst case.  (Source code is available on request.)

That seems like a strange way of doing things. Surely the RTP  
timestamp is calculated, not measured, and both audio and video use a  
common NTP clock?

-- 
Colin Perkins
http://csperkins.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 Jan 2008 19:55:28 +0100

Colin Perkins skrev:
> That seems like a strange way of doing things. Surely the RTP timestamp 
> is calculated, not measured, and both audio and video use a common NTP 
> clock?
> 

Agreed.

You also run a process on the side to check for clock drift by comparing 
the wall clock time with sampling instance for different media. As you 
point out this data is likely to require filtering to remove the jitter 
from the measurement process. But this is in fact necessary as I have 
colleagues that have experience of sound card that for 8k Hz sampling 
actually was sampling at several percent wrong length of the period.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Chuck Harrison <[email-masked]>
Date: Tue, 15 Jan 2008 11:16:42 -0800

More accurate wallclock/NTP may be part of the solution in some
applications.

Items to be aware of: IEEE P1588 (Precision Time Protocol) and its
consumer-LAN cousin IEEE 802.1AS. P1588 has been fielded for several
years and 802.1AS is still in development.

http://ieee1588.nist.gov/
http://www.ieee802.org/1/pages/802.1as.html

Jonathan Lennox wrote:
> [...]
> For audio/video synchronization, this arguably isn't so crucial [...]

Incidentally for multichannel (stereo, surround, etc) audio it sure
is.

Cheers,
  Chuck

---

From: Randell Jesup <[email-masked]>
Date: Tue, 15 Jan 2008 21:38:12 -0500

>> is calculated, not measured, and both audio and video use a common NTP

That does seem an odd way to do it, though I'm not a Win32/etc expert.

For audio and other highly regular streams, typically the timestamp rate
(timestamp-delta per encoded-frame) is basically a constant most of the
time, and you send the calculated (from system time) NTP time in the RTCP.
In some non-regular settings where sampling might be variable (or in the
presence of things like silence suppression) you could have somewhat random
offsets).

For example, in 20ms G.711 you expect a timestamp rate of 160 per
frame/packet.  If your sampling clock isn't 8000.000Hz, then the NTP time
difference in RTCP will indicate that.  Note: read the RFC requirements for
SR fields very carefully.

>actually was sampling at several percent wrong length of the period.

Drift is a fact of life, true.  Your "wall-clock" time (typically system
timer-based) will drift relative to the sampling clock (if not on the same
crystal); if you send multiple streams their clocks will drift relative to
each other, and your playout clock will drift relative to the clock of a
sender.  Great fun. :-)

---

From: Dave Singer <[email-masked]>
Date: Wed, 16 Jan 2008 13:21:50 +0200

ISMA put together a document on tune-in latency, which is avalable 
free on request from the web site www.isma.tv.  It discusses sync 
acquisition, I-frame acquisition, RTSP delays, FEC boundaries, and so 
on.  Might be worth looking at, as it has ideas on how to ameliorate 
things.
-- 
David Singer
Apple/QuickTime

---

From: Colin Perkins <[email-masked]>
Date: Thu, 17 Jan 2008 11:48:01 +0000

Randell,

This is a good analysis, and perhaps something you might consider  
turning into an internet-draft to focus discussion.

(more inline)

On 14 Jan 2008, at 15:20, Randell Jesup wrote:
> mappings
> once

Sure, but since RTCP timings are influenced by the group size, the  
RTCP bandwidth fraction, and the media data rate, we do need to know  
what are the actual delays people are seeing for the scenarios being  
considered?

>     probably need to be explicit in a general solution.

Define a new AVPF feedback report, to say "please send an RTCP SR at  
your earliest convenience", which receivers can use to quickly signal  
that they don't have the information needed to synchronise the media?

-- 
Colin Perkins
http://csperkins.org/

---

From: "Allison, Art" <[email-masked]>
Date: Fri, 18 Jan 2008 13:24:11 -0500

A/V synch is very complex and has many uncontrolled variables. But some
parameters can be somewhat bounded.
For typical viewing distance, in Europe Jackson found it to be 3m. In
the US, Lechner found it to be 9 feet.
See Digital Video and HDTV: Algorithms and Interfaces By Charles A.
Poynton @ p.73.

The average room size was the primary determinant for the average
situation. So a nominal value of 9-10 ms for sound getting to the ear is
reasonable to establish as typical. It is 'wrong' for some content as
the perception of when it should arrive varies based on the picture
content...if the view is of something in the distance then it 'should'
arrive later than a close up of a face. And HD lips are easier to see
move, so some feel that tighter tolerances are needed with 5.1/surround
to maintain the immersion experience. 

The ATSC Implementation Subcommittee studied the timing issue and issued
a finding establishing thresholds on the maximum amount of total
implementation error that was felt to be tolerable. Exceeding the
thresholds established was anticipated to result in 'too many' customer
complaints.  See http://www.atsc.org/standards/is_191.pdf.

Also for an example analysis of some of the time stamping issues (done
for Dolby AC-3), the ATSC Implementation Subcommittee issued an analysis
on that point. See http://www.atsc.org/standards/is_161.pdf.

Art
Art Allison

Director Advanced Engineering, Science and Technology
 
National Association of Broadcasters
1771 N Street NW
Washington, DC 20036
Phone  202 429 5418 
Fax  202 775 4981
www.nab.org

Advocacy  Education  Innovation

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 26 Jan 2008 14:33:19 -0800

On Jan 15, 2008, at 10:55 AM, Magnus Westerlund wrote:

> But this is in fact necessary as I have colleagues that have  
> experience of sound card that for 8k Hz sampling actually was  
> sampling at several percent wrong length of the period.

If anyone actually has one of these cards that is out by more than 1%,  
I would really love to get to play with one or find out more about  
which cards do this. This rumor about some cards being way out was  
circulated around my employer for a long time (an complicated some of  
our software) and I went on a hunt to actually track one down. I  
totally failed to find any sound card that was not highly accurate.  
Looking at the designs I found, they were all driven one way or  
another off crystal oscillators with accuracies best measured in parts  
per millions. The root cause of why some of them appeared to have bad  
rates was software bugs (typically buffer overflow causing them to  
look like they were running slow). However, many people I highly  
regard with respect to RTP claim these  bad cards exist so I remain  
hopeful I will find out the source. Anyways, if you have one, I'd love  
to learn more about it. Thanks, Cullen <with my individual contributor  
hat on>

---

From: Stephen Casner <[email-masked]>
Date: Sat, 26 Jan 2008 15:36:50 -0800 (PST)

On Sat, 26 Jan 2008, Cullen Jennings wrote:
> > But this is in fact necessary as I have colleagues that have experience of
> > sound card that for 8k Hz sampling actually was sampling at several percent
> > wrong length of the period.
> 
> If anyone actually has one of these cards that is out by more than 1%, I would
> really love to get to play with one or find out more about which cards do
> this. This rumor about some cards being way out was circulated around my
> employer for a long time (an complicated some of our software) and I went on a
> hunt to actually track one down. I totally failed to find any sound card that
> was not highly accurate. Looking at the designs I found, they were all driven
> one way or another off crystal oscillators with accuracies best measured in
> parts per millions. The root cause of why some of them appeared to have bad
> rates was software bugs (typically buffer overflow causing them to look like
> they were running slow). However, many people I highly regard with respect to
> RTP claim these  bad cards exist so I remain hopeful I will find out the
> source. Anyways, if you have one, I'd love to learn more about it. Thanks,
> Cullen <with my individual contributor hat on>

I know it was the case with SoundBlaster cards in Windows PCs 10 years
ago.  I measured it when at Precept Software.  I have not explored the
question in recent years.

                                                        -- Steve

---

From: Ron Frederick <[email-masked]>
Date: Sun, 27 Jan 2008 01:23:49 -0800

Stephen Casner wrote:
>>> But this is in fact necessary as I have colleagues that have experience of sound card that for 8k Hz sampling actually was sampling at several percent wrong length of the period.
>>>       
>> If anyone actually has one of these cards that is out by more than 1%, I would really love to get to play with one or find out more about which cards do this. This rumor about some cards being way out was circulated around my employer for a long time (an complicated some of our software) and I went on a hunt to actually track one down. I totally failed to find any sound card that was not highly accurate. Looking at the designs I found, they were all driven one way or another off crystal oscillators with accuracies best measured in parts per millions. The root cause of why some of them appeared to have bad rates was software bugs (typically buffer overflow causing them to look like they were running slow). However, many people I highly regard with respect to RTP claim these  bad cards exist so I remain hopeful I will find out the source. Anyways, if you have one, I'd love to learn more about it. Thanks, Cullen <with my individual contributor hat on>
>>     
>

My experience (also somewhat dated) was mostly with SPARCstation 
hardware, and I did see quite a bit of variability from one system to 
the next. However, the errors were nowhere near 1%. The worst case I saw 
was somewhere around 0.05%, or about 500 ppm. That was higher than it 
should have been for a crystal oscillator, and definitely high enough 
that for long continuous audio streams I had to have software which 
could properly insert or remove frames periodically to maintain sync, 
but it would have been almost unnoticeable in most systems with silence 
detection.

If you have a card with a fine enough granularity in a programmable 
sample rate, the easiest way to test software that copes with this is to 
simply misprogram the sample rate slightly, causing it to run slightly 
fast or slow intentionally.

-- 
Ron Frederick
[email-masked]

---

From: "Jaehwan Kim" <[email-masked]>
Date: Tue, 29 Jan 2008 18:46:16 +0900

There were some issues with Winnov card. We found that driver had some
issues in certain scenario, giving out improper timestamp as compared to
actual data. Eventually we added a correction module to our software,
but later driver also fixed the issue and so we were fine.

Regards,
Jaehwan
Vidiator

-----Original Message-----
From: Ron Frederick [mailto:[email-masked]] 
Sent: Sunday, January 27, 2008 6:24 PM
To: Magnus Westerlund
Cc: IETF AVT WG
Subject: Re: [AVT] Inter-stream synchronization and startup sync latency

>>> But this is in fact necessary as I have colleagues that have
experience of sound card that for 8k Hz sampling actually was sampling
at several percent wrong length of the period.
>>>       
>> If anyone actually has one of these cards that is out by more than
1%, I would really love to get to play with one or find out more about
which cards do this. This rumor about some cards being way out was
circulated around my employer for a long time (an complicated some of
our software) and I went on a hunt to actually track one down. I totally
failed to find any sound card that was not highly accurate. Looking at
the designs I found, they were all driven one way or another off crystal
oscillators with accuracies best measured in parts per millions. The
root cause of why some of them appeared to have bad rates was software
bugs (typically buffer overflow causing them to look like they were
running slow). However, many people I highly regard with respect to RTP
claim these  bad cards exist so I remain hopeful I will find out the
source. Anyways, if you have one, I'd love to learn more about it.
Thanks, Cullen <with my individual contributor hat on>

-- 
Ron Frederick
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 29 Jan 2008 11:13:03 +0100

Cullen Jennings skrev:
> If anyone actually has one of these cards that is out by more than 1%, I 
> would really love to get to play with one or find out more about which 
> cards do this. This rumor about some cards being way out was circulated 
> around my employer for a long time (an complicated some of our software) 
> and I went on a hunt to actually track one down. I totally failed to 
> find any sound card that was not highly accurate. Looking at the designs 
> I found, they were all driven one way or another off crystal oscillators 
> with accuracies best measured in parts per millions. The root cause of 
> why some of them appeared to have bad rates was software bugs (typically 
> buffer overflow causing them to look like they were running slow). 
> However, many people I highly regard with respect to RTP claim these  
> bad cards exist so I remain hopeful I will find out the source. Anyways, 
> if you have one, I'd love to learn more about it. Thanks, Cullen <with 
> my individual contributor hat on>
> 
> 

Sorry Cullen, my colleagues worst case was a PC with the sound card 
incorporated into the motherboard which was running at around 8600 Hz 
instead of the 8k it should. This such an extreme case that something 
must have been really broken.

Cheers

Magnus Westerlund

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 29 Jan 2008 12:40:38 -0800

> question in recent years.

Thanks - many of the other reports on this linked back to early  
SoundBlaster cards too. Actually, when I was digging into this last  
time some of the Cisco internal documentation discussed  results  
Precept had found so I guess I found who made theses measurements  
now :-)  I managed to find an ISA bus SoundBlaster 16 to play with  
back last time I looked at this but could not find any of the earlier  
cards to play with. I imagine there were various rev's of the  
soundblaster 16 but I could not reproduce it on the one I had. I also  
tested some of the later soundblaster AWE based cards.  I know there  
were several soundblaster designs that predated the 16.

Anyway, it has been an interesting design questions of if RTP software  
should be designed to deal with sample rates that are substantially  
wrong - there seem to be people with strong opinions on either side of  
this so I do appreciate the data folks have provided.