snd_pcm_htimestamp returns time past since last boot not clock time
alsa-project/alsa-lib issue #131 was opened from RonaldAJ:
While on a PC snd_pcm_htimestamp returns the clock time since the epoch, under Raspbian on an RPI it returns the time since the last boot. (A similar issue was described here: https://stackoverflow.com/questions/45841230/alsa-retrieving-audio-buffer-ti...).
The problem shows if we run a slightly modified version of recordtest.py using the latest pyalsaaudio versions.
``` #!/usr/bin/env python3 # -*- mode: python; indent-tabs-mode: t; c-basic-offset: 4; tab-width: 4 -*-
## recordtest.py ## ## This is an example of a simple sound capture script. ## ## The script opens an ALSA pcm device for sound capture, sets ## various attributes of the capture, and reads in a loop, ## writing the data to standard out. ## ## To test it out do the following: ## python recordtest.py out.raw # talk to the microphone ## aplay -r 8000 -f S16_LE -c 1 out.raw
#!/usr/bin/env python
from __future__ import print_function
import sys import time import getopt import alsaaudio
def usage(): print('usage: recordtest.py [-d <device>] <file>', file=sys.stderr) sys.exit(2)
if __name__ == '__main__':
device = 'default'
opts, args = getopt.getopt(sys.argv[1:], 'd:') for o, a in opts: if o == '-d': device = a
if not args: usage()
f = open(args[0], 'wb')
# Open the device in nonblocking capture mode in mono, with a sampling rate of 44100 Hz # and 16 bit little endian samples # The period size controls the internal number of frames per period. # The significance of this parameter is documented in the ALSA api. # For our purposes, it is suficcient to know that reads from the device # will return this many frames. Each frame being 2 bytes long. # This means that the reads below will return either 320 bytes of data # or 0 bytes of data. The latter is possible because we are in nonblocking # mode. inp = alsaaudio.PCM(alsaaudio.PCM_CAPTURE, alsaaudio.PCM_NONBLOCK, channels=1, rate=44100, format=alsaaudio.PCM_FORMAT_S16_LE, periodsize=160, device=device)
print(inp.info()) # help(inp.htimestamp)
loops = 100000 while loops > 0: loops -= 1 # Read data from device l, data = inp.read() if l: print(l, inp.htimestamp(), time.time()) f.write(data) time.sleep(.001) ```
When executed on an RPi it yields: ``` {'name': 'plugsnoop:1,0', 'state': 'PREPARED', 'access_type': 'RW_INTERLEAVED', ' (call value) type': 1, ' (call value) type_name': 'CAPTURE', ' (call value) mode': 1, ' (call value) mode_name': 'PCM_NONBLOCK', 'format': 2, 'format_name': 'S16_LE', 'format_description': 'Signed 16 bit Little Endian', 'subformat_name': 'STD', 'subformat_description': 'Standard', 'channels': 1, 'rate': 44100, 'period_time': 21333, 'period_size': 940, 'buffer_time': 0, 'buffer_size': 4704, 'get_periods': 0, 'rate_numden': (44100, 1), 'significant_bits': 16, 'is_batch': True, 'is_block_transfer': True, 'is_double': False, 'is_half_duplex': False, 'is_joint_duplex': False, 'can_overrange': False, 'can_mmap_sample_resolution': False, 'can_pause': False, 'can_resume': False, 'can_sync_start': False} 940 (5596, 851796145, 0) 1617702646.0637105 940 (5596, 872796030, 0) 1617702646.084714 940 (5596, 893795916, 0) 1617702646.105702 940 (5596, 915796158, 0) 1617702646.1277127 940 (5596, 936795314, 0) 1617702646.1486921 940 (5596, 957795199, 0) 1617702646.1697078 940 (5596, 979795858, 0) 1617702646.191694 940 (5597, 795171, 0) 1617702646.212712 ... ``` I read that for the timestamp function to work there should be hardware support. But here we have it half working.
This behavior is shown if I use the following in my .asoundrc
``` pcm.plugsnoop { type plug
@args [ CARD DEV ]
@args.CARD { type string }
@args.DEV { type integer }
slave { pcm { @func concat strings [ "dsnoop:" $CARD "," $DEV ] } } } ``` and call it with: `python recordtest.py -d plugsnoop:1,0 test.raw`
Using plughw all timestamps become zero.
The attached microphone is an USB microphone: GoMic by SAMSON.
Is there a fix or workaround for this behavior which gives me clocktime instead of seconds since last boot?
Issue URL : https://github.com/alsa-project/alsa-lib/issues/131 Repository URL: https://github.com/alsa-project/alsa-lib
participants (1)
-
GitHub issues - opened