[alsa-devel] Is there a way to figure out if the clocks of two snd_pcm_t's deviate? (snd_pcm_info_get_sync?)
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
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.
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.
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
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
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
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
participants (4)
-
Jaroslav Kysela -
Lennart Poettering -
Mark Brown -
pl bossart