Is there a way to figure out if the clocks of two snd_pcm_t's deviate? (snd_pcm_info_get_sync?)

Is there a way to figure out if the clocks of two snd_pcm_t's deviate? (snd_pcm_info_get_sync?)

[Lennart Poettering]

Heya!

I am looking for a way to find out whether the clocks of two
snd_pcm_t's are perfectly in sync and don't deviate (or only deviate
by a constant phase). 

i.e. for real duplex devices that use the same crystal for input and
output this should tell me "Yes" for the playback snd_pcm_t tested
against the recording snd_pcm_t; and for all other, unrelated audio
devices it should return "No".

I found snd_pcm_info_get_sync() in the docs, but its documentation is
a bit terse, so I am wondering if this might be what I want. Is it?

Does this (untested) code snippet do what I hope it does?

<snip>
  snd_pcm_info(a, info_a);
  snd_pcm_info(b, info_b);
  in_sync = memcmp(&snd_pcm_info_get_sync(info_a), &snd_pcm_info_get_sync(info_b)) == 0;
</snip>

Thanks,

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Is there a way to figure out if the clocks of two snd_pcm_t's deviate? (snd_pcm_info_get_sync?)

[Jaroslav Kysela]

On Fri, 4 Sep 2009, Lennart Poettering wrote:

> Heya!
>
> I am looking for a way to find out whether the clocks of two
> snd_pcm_t's are perfectly in sync and don't deviate (or only deviate
> by a constant phase).
>
> i.e. for real duplex devices that use the same crystal for input and
> output this should tell me "Yes" for the playback snd_pcm_t tested
> against the recording snd_pcm_t; and for all other, unrelated audio
> devices it should return "No".
>
> I found snd_pcm_info_get_sync() in the docs, but its documentation is
> a bit terse, so I am wondering if this might be what I want. Is it?
>
> Does this (untested) code snippet do what I hope it does?

Hi,

Nope. The snd_pcm_info_get_sync() function identifies streams with 
"sample sync and sample synchronized start".

All standard soundcards have only one clock source, so if 
snd_pcm_info_get_card() number matches, the streams will most probably 
run in sync.

I cannot recall from my mind, if any card has two clock sources - maybe 
only old Gravis UltraSound hardware with GF1 and CS4231 chips, but it's 
history. Also, professional hardware can run with word clock sync (wire 
connection carrying sample clock) or S/PDIF clock sync. But it's matter of 
user configuration.

I would suggest to match card number as default for used streams and add 
an user option to modify the stream word clock configuration for your app.

 						Jaroslav

-----
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.

Re: Is there a way to figure out if the clocks of two snd_pcm_t's deviate? (snd_pcm_info_get_sync?)

[Mark Brown]

On Fri, Sep 04, 2009 at 08:44:50AM +0200, Jaroslav Kysela wrote:

> I cannot recall from my mind, if any card has two clock sources - maybe 
> only old Gravis UltraSound hardware with GF1 and CS4231 chips, but it's 
> history. Also, professional hardware can run with word clock sync (wire 
> connection carrying sample clock) or S/PDIF clock sync. But it's matter of 
> user configuration.

Several of the embedded CODECs can have multiple master clocks active
simultaneously within just that device and even more embedded systems
are able to run with multiple masters.

Re: Is there a way to figure out if the clocks of two snd_pcm_t's deviate? (snd_pcm_info_get_sync?)

[pl bossart]

> I am looking for a way to find out whether the clocks of two
> snd_pcm_t's are perfectly in sync and don't deviate (or only deviate
> by a constant phase).

short answer:no
You would need hardware that would count the bit clock transitions and
provide the delta. Few devices provide this in the consumer space, and
when they do they actually perform an asynchronous sample-rate
conversion on the fly (cf. Freescale DSP563xx). Analog Devices also
provides dedicated sample-rate converters that perform this comparison
and resampling; they are typically used when multiple masters are
present.
All this nice hardware wouldn't work anyway for USB where audio is
transmitted in packets every ms; it's hard to guess what the real
audio speed is.
That's the reason why I introduced the resampling enable/disable in
the PA module-loopback code, only the user/system designer will know
if you have one master or more, and whether you should enable
variable-rate interpolation.
Cheers
- PL

Re: Is there a way to figure out if the clocks of two snd_pcm_t's deviate? (snd_pcm_info_get_sync?)

[Lennart Poettering]

On Fri, 04.09.09 08:44, Jaroslav Kysela (perex@perex.cz) wrote:

> All standard soundcards have only one clock source, so if  
> snd_pcm_info_get_card() number matches, the streams will most probably  
> run in sync.

Hmm, does this also mean that SPDIF output and analog output of the
same sound card stay in sync on most cards?

> I would suggest to match card number as default for used streams and add  
> an user option to modify the stream word clock configuration for your 
> app.

OK, sounds good.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Is there a way to figure out if the clocks of two snd_pcm_t's deviate? (snd_pcm_info_get_sync?)

[Lennart Poettering]

On Fri, 04.09.09 07:52, pl bossart (bossart.nospam@gmail.com) wrote:

> 
> > I am looking for a way to find out whether the clocks of two
> > snd_pcm_t's are perfectly in sync and don't deviate (or only deviate
> > by a constant phase).
> 
> short answer:no
> You would need hardware that would count the bit clock transitions and
> provide the delta. Few devices provide this in the consumer space, and
> when they do they actually perform an asynchronous sample-rate
> conversion on the fly (cf. Freescale DSP563xx). Analog Devices also
> provides dedicated sample-rate converters that perform this comparison
> and resampling; they are typically used when multiple masters are
> present.
> All this nice hardware wouldn't work anyway for USB where audio is
> transmitted in packets every ms; it's hard to guess what the real
> audio speed is.

But that should already be good enough for my purposes. I mostly care
that over a longer period of time the deviation between input and
output (or two outputs) is bounded. That means, if there is a fixed
time deviation between recording and playback and I know only that it
is fixed but don't know exactly what it is I am already a happier man.

> That's the reason why I introduced the resampling enable/disable in
> the PA module-loopback code, only the user/system designer will know
> if you have one master or more, and whether you should enable
> variable-rate interpolation.

but why shouldn't this information be queriable from the drivers?
Drivers do know a lot about the hardware they drive, so they should
now about clocks, too.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Is there a way to figure out if the clocks of two snd_pcm_t's deviate? (snd_pcm_info_get_sync?)

[pl bossart]

> but why shouldn't this information be queriable from the drivers?
> Drivers do know a lot about the hardware they drive, so they should
> now about clocks, too.

You are correct, drivers typically configure serial audio links to be
master or slave, and what is the clock source. In SoC this would be
done in the dai link configurations. If you had a means to report this
information to userspace then yes you could find out if two interfaces
are in sync. It might be a bit more complex for USB since the standard
specifies different ways of sending audio out.
Cheers
- Pierre