[alsa-devel] proposal: snd_pcm_start_at()

[Tim Cussins]

Hi Peirre,

On 02/10/14 18:41, Pierre-Louis Bossart wrote:
> 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

Thanks heaps for the feedback :)

Agreed - streaming zeros 'as required' is pretty much the obvious 
solution when confined to the existing API.

So I guess I'll have to show a few more cards from my hand :D

The next iteration of our hardware platform will be accompanied by a 
move to linux, which explains our interest in ALSA for sound delivery.

The pcm hardware for the new platform can start rendering when a compare 
register matches a hw counter (driven by the audio clock). This allows 
for starting with frame-accurate timing.

By adding another tstamp_type - let's call it 
SND_PCM_TSTAMP_TYPE_HARDWARE for now - snd_pcm_start_at() could 
internally delegate to the driver (if it supports it, otherwise error)

I take your point about drift, but we're approaching that as a related, 
but orthogonal, problem. As a business we've decided that dropouts are 
unacceptable. Our products have several audio clock sources available, 
one of which is a high-quality VXCO. With an appropriate servo, it will 
track a clock recovered from the incoming stream.

I'm still working through a couple of options for exposing the VXCO 
audio clock to a userspace servo [The linux kernel has the PCH 
framework, for example, which is almost enough, but doesn't dovetail 
with ALSA in an obvious way].

In summary, we'd like to leverage our pcm hardware's ability to start on 
time (hence the chat about snd_pcm_start_at), and we'd also like to 
expose control of the pcm's audio clock in some way (WIP, suggestions 
welcome!).

The clock control stuff is harder, but I wanted to get on the ml with 
something simple, say hi, propose a thing

Thanks for reading - I'll have questions about clock control soon 
enough, see ya then.

Cheers,
Tim