Timing of linked devices

Timing of linked devices

[louis]

I am developing an application which opens both inputs and outputs for
digital and s/pdif (so, 4 devices).  The sync IDs all match.  However,
under certain conditions, I am receiving partial buffers from the input. 
So, I have a few questions:

Does linking input and output devices, from a programmer's perspective,
mean that input is ready at precisely the same time that the device is
ready to output a buffer?  Or, does it only mean that the ins and outs
will be synchronized for each given buffer?  More to the point, will
blocking on a write also accurately tell the program when the device is
ready for a read (including under non-ideal circumstances like after a
bunch of xruns)?

And, in the case that I am doing a non-blocking read (pcm_read) from a
buffer which is not yet ready, should I receive an outdated buffer, a
blank buffer, or one which has both partially new and  partially old data?

I am using ALSA 1.0.15 and the ICE1724 driver.

Thanks in advance for your help!
- Louis

Re: Timing of linked devices

[Clemens Ladisch]

louis@museresearch.com wrote:
> I am developing an application which opens both inputs and outputs for
> digital and s/pdif (so, 4 devices).  The sync IDs all match.  However,
> under certain conditions, I am receiving partial buffers from the input. 
> So, I have a few questions:
> 
> Does linking input and output devices, from a programmer's perspective,
> mean that input is ready at precisely the same time that the device is
> ready to output a buffer?

No; linking just means that ALSA tries to start the streams at the same
time.  If the sync IDs match, the hardware actually supports this.

> Or, does it only mean that the ins and outs will be synchronized for
> each given buffer?

Not even that.  Linking streams does not guarantee that they run at the
same speed.

If two streams are handled by the same DMA controller and are using the
same clock, they should be perfectly synchronous.  In the case of S/PDIF
recording, the clock is determined by the sending device, so it is
likely to be different from the other stream.

> And, in the case that I am doing a non-blocking read (pcm_read) from a
> buffer which is not yet ready, should I receive an outdated buffer, a
> blank buffer, or one which has both partially new and partially old data?

You get no data and error code -EAGAIN.


HTH
Clemens