On 10/2/14, 9:34 AM, Tim Cussins wrote:
Hi all,
I'm Tim: I work at Linn Products Ltd - we make Network Music Players, amongst other things.
As you might imagine, synchronised-start is important when multiple devices on the network are rendering the same audio. We'd be interested in contributing a small expansion of the alsa-lib API to support synchronised start.
Assuming we can synchronise the audio clocks (I'm aware this is not trivial - It's not the topic of this post), we'd propose something like:
int snd_pcm_start_at(snd_pcm_t* pcm, snd_htimestamp_t* tstamp);and playback would begin as close to tstamp as possible. If tstamp is in the past, it would should return an error.
Recent work by Takashi Iwai enables client code to set the clock type of timestamps using snd_pcm_sw_params_set_tstamp_type(). This context could quite naturally extend to tstamp argument of snd_pcm_start_at().
Before I get stuck into working up the details under the hood, it'd be good to get some feedback/objections regarding this approach.
It's probably better idea to start PCM playback with a bunch of zeroes and then rely on existing timestamping to insert samples at the right location in the ring buffer - which you have to do anyway to compensate for drifts between your network clock and audio clock. This is a more predictable solution that abstracts away all the time needed to arm DMA, FIFOs, etc. The only hardware-dependent variable that would remain is the precision/granularity of the timestamping. -Pierre