02:19 <set_> About my inquiry...the pwm instance on the BBAI-64 has an overlay which handles the "Fan" pin.

02:20 <set_> Dudes...gals. Fans!

02:21 <set_> Anyway, I actually had a connector to fit. Now, to do stuff to it. This way, cooling sensations all around!

10:06 <Siegurd> zmatt: Hi! Earlier you mentioned CLOCK_RAW_MONOTONIC, is it possible to use this timer?

10:06 <zmatt> Siegurd: I mean, sure, though why would you want to?

10:07 <zmatt> and what do you mean by "use"

10:07 <zmatt> you can query it and I'd guess probably use it with a timerfd (though I've never tried that), but generally you should use CLOCK_MONOTONIC instead

10:11 <Siegurd> I am successfully reading data from AD7771 through a pipe in my C++ program in bursts of 32768 bytes and I need the precission timestamps to write data in to data base.

10:15 <zmatt> I mean, the measurements are regularly spaced so you can interpolate the block-timestamp alsa gives you

10:16 <zmatt> alsa lets you choose whether you want CLOCK_REALTIME, CLOCK_MONOTONIC, or CLOCK_MONOTONIC_RAW as clock source for timestamps

10:16 <Siegurd> So that the signals that are received every 32768/32/128000 = 8 milliseconds get into the database in a seamless mode.

10:16 <Siegurd> I don't use ALSA lib

10:18 <zmatt> if you want your audio blocks to be timestamped you'll want to use alsa directly, obviously you don't have access to these if you're using arecord

10:18 <Siegurd> I tried but I couldn't get data from the audio device with 128kHz

10:18 <zmatt> then you probably just configured something wrong

10:19 <Siegurd> only pipe gives me a desired data stream speed

10:19 <zmatt> you should probably configure 96 kHz since we know the kernel thinks it doesn't support 128 kHz

10:19 <zmatt> arecord is just a simple demo program that uses the alsa library

10:21 <zmatt> like previously discussed, the data rate you'll get does not actually depend on the samplerate you configure via alsa

10:22 <zmatt> you just need to configure some rate the kernel thinks is okay, the actual data rate only depends on your configuration of the AD7771

10:23 <zmatt> note btw that alsa's audio block timestamps are not super accurate since they're done in software, though obviously they'll be more accurate than any timestamping done in userspace

10:23 <zmatt> we actually use PRU for the timestamping because alsa's timestamps were too jittery for our purposes

10:24 <Siegurd> Yes, I measured the period of data coming from the pipe and got 8 milliseconds for 1028 measurements, which is expected for a frequency of 128 kHz. Now it remains only to a precise timestamps of each 8ms period.

10:26 <zmatt> timestamp relative to what? like, both CLOCK_MONOTONIC and CLOCK_MONOTONIC_RAW are essentially arbitrary timebases, and if you only need a timestapm in an arbitrary timebase then you can just multiply the sample index by 8ms

10:29 <zmatt> if you do want timestamps specifically in one of the three timebases supported by alsa then just take the block timestamps provided by alsa and interpolate/extrapolate. to reduce the impact of jitter you may want to apply some filtering

10:31 <zmatt> we actually use a PID loop to create a smooth translation between the sampling clock and the timebase we care about (which is CLOCK_MONOTONIC_RAW for us due to very application-specific reasons)

10:33 <Siegurd> actually I want to get epoch timestamps. For example, I am subtracting the epoch timestamp and нI'm starting to read data from the AD7771. After about 8ms, when the data is read, I need to make another timestamp to understand how long it took to read the data block. It could be 7887267 or 7935639 ns. Therefore, I need a timestamp that is tied to the PRU so that the time value is not affected by operating system glitches.

10:33 <zmatt> if you're only going to store the data anyway then I'd suggest just saving the alsa-provided timestamp of each block of samples received from alsa, and filter/interpolate the timestamps as needed when consuming the data

10:34 <zmatt> I don't really understand what you mean

10:34 <zmatt> like, I don't get what you're trying to achieve

10:35 <zmatt> I assume by "epoch timestamps" you mean CLOCK_REALTIME (the system date/time)

10:37 <zmatt> at 128 kHz you'll get exactly 1024 samples in 8ms. if you measure accurately then the measured interval will be 8ms ± some tiny difference due to oscillator frequency error

10:41 <zmatt> like, ±100 ppm frequency error (which is quite a large error) would mean that an interval of 1024 samples (measured accurately) takes 7999200 - 8000800 ns

10:41 <Siegurd> yes, and I vant to accurately meashure that 8ms period to eliminate those tiny difference due to oscillator frequency error by using PRU timestamps

10:42 <Siegurd> now 125 meashurments took 999588136 ns instesd of 1 second

10:42 <zmatt> what are you doing right now?

10:43 <zmatt> if you're doing something with a pipe and arecord then whatever you're measuring is nonsense

10:43 <zmatt> start by using alsa-provided timestamps

10:44 <zmatt> if you set a blocksize of 1024 then alsa will give you a block of 1024 samples every 8 ms, along with a timestamp for that block of data

10:45 <zmatt> those timestamps will be jittery, but it's not like the beaglebone's system time and date will be ultra-accurate either anyway

10:49 <zmatt> like, the fact that you say you want CLOCK_REALTIME timestamps but you also seem to think you want nanosecond accuracy makes me very much question whether you understand your actual needs

10:51 <zmatt> if you can explain to me what you're actually trying to achieve then maybe I can give useful feedback

10:53 <zmatt> like, the main reason I can think of to get very high precision timestamps in some particular timebase is to be able to relate them to *other* high-precision timestamps in the same timebase

11:02 <zmatt> e.g. we get audio data timestamped in CLOCK_MONOTONIC_RAW because we also get Precision Time Protocol (PTP) packets timestamped in that same timebase; we use PTP timesync to be able to convert between the CLOCK_MONOTONIC_RAW of one device and that of another, thus ultimately allowing audio to be accurately synchronized between the devices. all of this required PRU code, a whole bunch of kernel ...

11:02 <zmatt> ...patches, and a customized ptp daemon. we didn't really have much choice since it's the only way to achieve such synchronization via the network

11:03 <zmatt> I'm kinda hoping for you that you don't actually have a similar need :P

11:09 <Siegurd> this is my pipe code that works https://pastebin.com/dsN2Mz1f and this https://pastebin.com/KMVW8L2c is my alsa code that does not give me a 128kHz output. Perhaps this is due to a too small buffer or other settings that I did not take into account.

11:11 <zmatt> note only are these measurements bogus, you're also reading arbitrary chunks of data and discarding them

11:11 <zmatt> (the first code you gave)

11:12 <zmatt> read() will return *up to* the requested number of bytes, it may return less. if you want to read a specific number of samples then you need to track the actual number of bytes receive

11:12 <zmatt> d

11:14 <zmatt> anyway, don't use arecord or pipe

11:14 <Siegurd> it always gives me 32768 bytes

11:15 <Siegurd> i check it

11:15 <zmatt> there's no checking in the code you pastebinned

11:17 <Siegurd> I delete it because it was optional. Here read() this is a blocking call.

11:17 <zmatt> like it's possible arecord happens to be buffering the data and writing it in big enough chunks, or maybe it just uses a blocksize that big (I don't know what its defaults are)

11:18 <zmatt> regardless, whatever you're measuring is completely at the mercy of what arecord is doing along with linux process scheduling

11:19 <zmatt> your alsa version will still be quite inaccurate since you're timestamping in userspace instead of using alsa's timestamps and you're not reading entire blocks

11:21 <zmatt> lemme check what our alsa code is doing

11:25 <zmatt> btw my guess would be arecord is using snd_pcm_hw_params_set_rate_near (to request the nearest "supported" rate, i.e. 96 kHz) rather than snd_pcm_hw_params_set_rate (which fails on the requested rate because the kernel thinks it's not supported by the codec)

11:25 <zmatt> regardless, just set 96 kHz or whatever, it doesn't matter anyhow

11:26 <zmatt> ah yaeh we're using the mmap-based access model, snd_pcm_hw_params_set_access(handle, hw_params, SND_PCM_ACCESS_MMAP_INTERLEAVED)

11:27 <zmatt> and use snd_pcm_sw_params_set_tstamp_mode and snd_pcm_sw_params_set_tstamp_type to enable timestamping

11:27 <Siegurd> alsa snd_pcm_readi took 7037977 ns to read 1024 bytes (32 readings of all channels) that gives 32 readings in 8 ms instead of 1024 readings in 8ms

11:28 <Siegurd> ok, will try that

11:30 <zmatt> I'm seeing about 7 us per read-call, which seems plausible enough for a kernel call

11:32 <zmatt> I don't know what the block size is since you didn't configure it but it'll no doubt be much larger than 32 samples, so you're really just measuring the time it takes to call into the kernel to read some bytes from its buffer

11:34 <zmatt> 32 samples would also be an unreasonably small block size

11:47 <zmatt> I see in our code we're also using snd_pcm_status_set_audio_htstamp_config() where the config argument is snd_pcm_audio_tstamp_config_t audio_tstamp_config {2,1};

11:47 <zmatt> whatever that means

11:48 <zmatt> oh the 2 is SND_PCM_AUDIO_TSTAMP_TYPE_LINK

11:51 <zmatt> I don't really know much about alsa anyway, but hopefully there exist examples on how to use timestamping

11:51 <zmatt> afk

11:54 <Siegurd> I foung this example https://github.com/intel/SmartXbar/blob/master/private/apps/alsa_capture_example/src/alsa_capture_example.cpp

12:06 <zmatt> the kernel has some documentation about alsa timestamping: https://docs.kernel.org/sound/designs/timestamping.html

12:08 <zmatt> anyway, afk