[LAD] AoIP question

[tom at trellis.ch]

On Sun, October 5, 2014 22:25, Fons Adriaensen wrote:
> On Sun, Oct 05, 2014 at 08:39:11PM +0200, tom at trellis.ch wrote:
>
>
>> As a scenario, at point a) an analog signal is injected that will be
>> played back (analog) at point b) with the lowest possible (and constant)
>>  latency. How do you intend to handle diverging clocks of the audio
>> interfaces (ADC/DAC) at both (a/b) ends?
>>
>
> Either
>
>
> 1. Sync the HW sample rates to an explicit or implicit reference
> provided by the network protocol. Requires special audio HW. A few normal
> audio interfaces (e.g. some RME cards) would allow to do this as well, but
> I know of no software that uses this
> capability.
>

Sounds interesting. I asked myself if it would be possible to drive the
audio interface clock by the host (not by a wordclock coming from another
audio interface which makes the "network" case local again to some
degree), i.e. through ticks sent via FW/USB.

> 2. Resample at the receiver, as njbridge does.
>

i know this, a real pearl! It's working amazingly well. The data on the
receiver is not 1:1 equal to what is being sent. This works for most cases
though.

>
> 3. Use some other trick. E.g. for VOIP a classical one is to
> modify the lenght of the pauses between words or phrases.
>

Interesting approach :)

Imagine this:
Many middle-class audio interfaces have an S/PDIF input that can drive the
internal clock (interface is slaved to S/PDIF). S/PDIF is rate-less, any
(?) rate would work. Now, if we'd have an external device that does
nothing else than providing a variable clock to the audio interface via
S/PDIF, software-controlled, it would be possible to match / align
decoupled, network-connected hosts. Scenario: endpoint audio interface is
slaved to that variable "speed" S/PDIF generator, that is software
controlled. Some clever tool could then adjust the speed to match the
sender's rate. This would allow non-resampled ~isochronous audio on remote
hosts for cheap.
The S/PDIF protocol looks relatively simple (~5 MHZ bit by bit output for
SR 44100 needed though). Unfortunately this hack is beyond my skills (if
it would work at all).

Cheers
Tom