Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Songcast Timestamps
07-03-2014, 10:09 AM (This post was last modified: 07-03-2014 10:13 AM by PeteManchester.)
Post: #1
Songcast Timestamps
Hi,

I'm making very good progress with my Songcast Receiver, I have got it working and am now looking to use the timestamps and latency to add a delay the playback..

Is there a special format for the network timestamp and media timestamp in the audio message.

Maybe I should read the docs a bit more Angry

Quote:Timestamps
Accurate timestamps allow appropriately equipped Songcast Receivers to achieve close audio synchronisation. But timestamps should only be used when high accuracy is achievable. The timestamps and the media latency are measured according to an audio MCLK that is 256 * 44K1, or 256 * 48K.

I'm not sure I understand the description though, if possible please can you explain a bit more.

I tried a simple conversion to an int and a long, but at times I get a negative number and the value does not seem to relate to any system time that I have.

Also for the latency I convert that to an int, but if in the OpenHome Songcast sender I set the latency to 150ms the value I get in my receiver is 1843200, Hex 001C2000. This value changes when I change it in the sender, it does go up or down, but does not equal what is set in the sender, it's ok for me, but just wondered if I missed something on the conversion.

Thanks,

Pete.
Find all posts by this user
07-03-2014, 02:07 PM (This post was last modified: 07-03-2014 02:12 PM by simonc.)
Post: #2
RE: Songcast Timestamps
To calculate latency in a sender:
  • start with a millisecond value
  • multiply by 256
  • multiply by a factor dependent on the clock family in use. (44100 if your audio's sample rate is in the 44.1kHz family; 48000 for the 48kHz family.)
  • divide by 1000
In psuedocode, this becomes
Code:
uint CalculateLatency(uint aLatencyMs, uint aSampleRate)
{
    uint multiplier = ((aSampleRate%441) == 0? 44100 : 48000);
    return ((uint64)aLatencyMs * multiplier * 256) / 1000;
}

A receiver would reverse this calculation to retrieve a millisecond latency.

Timestamping must only be used if your sender has a very accurate clock. If used, it allows a receiver to detect that it's clock runs at a very slightly different rate to the sender's. If the receiver is capable of varying the rate of its clock, it can adjust to match the sender's speed, avoiding the possibility of eventual audio glitches (either audio starvation if the receiver is faster than the sender or audio buffer overflow if the receiver is slower). This type of small change to clock speed is referred to as clock pulling in some docs.

For best results, the timestamp is applied as close to the network as possible. Linn's DS players use dedicated hardware for this. Songcast app (PC senders) do not supply timestamps; despite using kernel-side software, they still can't access sufficiently accurate clocks. User-side senders should not attempt to provide a timestamp.

I think you have a Java app that runs entirely in user space and primarily targets RaspberryPi? If so, I'd suggest ignoring timestamping. I don't think the RPi is capable of clock pulling. Timestamps applied by a user space sender would be too coarse/unpredictable to help a receiver.
Find all posts by this user
07-03-2014, 06:13 PM (This post was last modified: 09-03-2014 10:04 AM by PeteManchester.)
Post: #3
RE: Songcast Timestamps
(07-03-2014 02:07 PM)simonc Wrote:  To calculate latency in a sender:
  • start with a millisecond value
  • multiply by 256
  • multiply by a factor dependent on the clock family in use. (44100 if your audio's sample rate is in the 44.1kHz family; 48000 for the 48kHz family.)
  • divide by 1000
In psuedocode, this becomes
Code:
uint CalculateLatency(uint aLatencyMs, uint aSampleRate)
{
    uint multiplier = ((aSampleRate%441) == 0? 44100 : 48000);
    return ((uint64)aLatencyMs * multiplier * 256) / 1000;
}

A receiver would reverse this calculation to retrieve a millisecond latency.

Timestamping must only be used if your sender has a very accurate clock. If used, it allows a receiver to detect that it's clock runs at a very slightly different rate to the sender's. If the receiver is capable of varying the rate of its clock, it can adjust to match the sender's speed, avoiding the possibility of eventual audio glitches (either audio starvation if the receiver is faster than the sender or audio buffer overflow if the receiver is slower). This type of small change to clock speed is referred to as clock pulling in some docs.

For best results, the timestamp is applied as close to the network as possible. Linn's DS players use dedicated hardware for this. Songcast app (PC senders) do not supply timestamps; despite using kernel-side software, they still can't access sufficiently accurate clocks. User-side senders should not attempt to provide a timestamp.

I think you have a Java app that runs entirely in user space and primarily targets RaspberryPi? If so, I'd suggest ignoring timestamping. I don't think the RPi is capable of clock pulling. Timestamps applied by a user space sender would be too coarse/unpredictable to help a receiver.

Thanks Simon, it maybe a bit too ambitious to try using the timestamps on a raspi, I just implemented a slight delay based on the latency value.

It good to know how the timestamps work though..
Find all posts by this user


Forum Jump: