In normal ALSA operation, you can enable timestamps on an audio stream using the SND_PCM_TSTAMP_ENABLE flag to alsa_snd_pcm_sw_params_set_tstamp_mode(). Subsequently, calling alsa_snd_pcm_status_get_tstamp() (or the higher precision get_htstamp) gives timing information. On my machine this works fine with vanilla ALSA, but once I install an asoundrc which specifies "type pulse" for pcm.!default and ctl.!default timing information is no longer available (get_tstamp and get_htstamp always return zero).
http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=65ff6fdafb705b5e2e6d4b9a94a80e5de89f5de1;hp=9b716075de4f2f7f15e428ee7efaa8960ef45b9c not sure those io plugins support time stamp or not you have to ask this question in alsa dever mailing list
I'm not sure I've understood; judging by the discussions on alsa-devel it doesn't seem like the place for pulse questions or API queries. I sent a message anyway in case someone with the requisite wisdom had time to help, but I'm not confident I'll get a response (3 days so far).
I have just hit same issue here, which struct hard in GStreamer as it produce timestamp 0 which cannot be dissociated with "no timestamp".
The bug does indeed seem to be on the alsa side. Raymond is right, and your report on alsa-discuss seems to cover what's needed. If there's no response in a couple of days, you could ping the thread again.
Just realised how long it's been since the original mail, let me re-ping. For reference, the thread is at: http://mailman.alsa-project.org/pipermail/alsa-devel/2015-February/087353.html
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/234.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.