On 10/24/2016 05:22 PM, Dennis Borgmann wrote:
> Hello ALSA-user list!
>
> I am trying to read on an ALSA-device with a simple example program I
> found here:
>
> https://gist.github.com/albanpeignier/104902
>
> It just sets up the audio interface and then records audio samples in a
> loop. That's it already. I enhanced it a little in order to measure some
> timings, that are relevant for me. So I'd like to have an endless loop
> running, that just records audio and does this at a fixed interval. For
> that reason, I altered the loop within the example-prorgam linked above
> like this:
>
> [code]
>gettimeofday( _debug_output_StTV, NULL );
>for (i=0;i<10;i++) {
> if ((err = snd_pcm_readi (capture_handle, buffer,
> buffer_frames)) != buffer_frames) {
>fprintf (stderr, "read from audio interface failed %d (%s)\n",
> err, snd_strerror (err));
>return (1);
> }
> gettimeofday( _end_of_loop_StTV, NULL );
> looptime_I = (timestamp_end_of_loop_StTV.tv_usec -
> timestamp_debug_output_StTV.tv_usec + (timestamp_end_of_loop_StTV.tv_sec
> - timestamp_debug_output_StTV.tv_sec) * 100);
> gettimeofday( _debug_output_StTV, NULL );
> fprintf(stdout, "read %d done, %05d usec\n", i, looptime_I);
>}
> [/code]
>
> I am reading a certain amount of frames. After that I measure the time
> it took to get this amount of frames.
>
> What surprises me is, that the intervals of reading are varying a lot.
> So my output looks like this:
>
> [quote]
> read 0 done, 45664 usec
> read 1 done, 00128 usec
> read 2 done, 00084 usec
> read 3 done, 09773 usec
> read 4 done, 00100 usec
> read 5 done, 00066 usec
> read 6 done, 00063 usec
> read 7 done, 09765 usec
> read 8 done, 00096 usec
> read 9 done, 00066 usec
> [/quote]
>
> The first one is irrelevant as the times taken are not reliable due to
> the initiation of this process. But then, I get 128 usecs, then 84 usecs
> - values that seem to be ok as the buffer that I am reading from might
> be filled initially. So reading does not take long, I am directly
> getting the audio data from the kernel driver. Then, it once takes
> longer - almost 10ms. This is alright, as my configured period time is
> 1, which I can observe from the output of snd_pcm_dump();
>
> [quote]
> Hardware PCM card 1 'dummy-audio' device 0 subdevice 0
> Its setup is:
>stream : CAPTURE
>access : RW_INTERLEAVED
>format : S16_LE
>subformat: STD
>channels : 2
>rate : 48000
>exact rate : 48000 (48000/1)
>msbits : 16
>buffer_size : 24000
>period_size : 480
>period_time : 1
>tstamp_mode : NONE
>tstamp_type : MONOTONIC
>period_step : 1
>avail_min: 480
>period_event : 0
>start_threshold : 1
>stop_threshold : 24000
>silence_threshold: 0
>silence_size : 0
>boundary : 1572864000
>appl_ptr : 0
>hw_ptr : 0
> [/quote]
>
> After this 10ms run, there are three runs with values around 100us,
> which tells me, that everytime I want to read audio data in my loop,
> there is data waiting for me (mind my VERY simple snd_pcm_readi()-loop).
> But I don't understand, why it is that way. I would expect the next run
> after the first 10ms run to take 10ms again.
>
> I am running this program on an Intel Edison-Board using an RT-Kernel:
>
> [quote]
> # uname -a
> Linux wurst 3.10.17-rt12-poky-edison-preempt_rt+ #9 SMP PREEMPT RT Mon
> Sep 19 14:24:24 CEST 2016 i686 GNU/Linux
> [/quote]
>
> I also set some IRQ-priorities like this:
>
> [code]
> # chrt -f -p 90
> # chrt -f -p 89
> # chrt -f -p 89
> [/code]
>
> The same measurement-results of the timings can be observed on a virtual
> machine using Oracle VirtualBox running an Ubuntu 14.04 with this Kernel:
>
> [quote]
> # uname -a
> Linux test-VirtualBox 3.13.0-35-generic #62-Ubuntu SMP Fri Aug 15
> 01:58:42 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
> [/quote]
>
> I will continue doing some tests even with other hardware in order to
> get an idea, why the program behaves like this. In the meantime, I'd
> appreciate any idea that could help in finding the source of my
> obervations. Maybe there is no "error" that I am searching for, but I
> rather misunderstand something in this matter.
>
> Thanks for any hints in advance. If there is any additonal information
> required, please ask me and I'll do my best to provide the information.
>
> Best regards,
> Dennis
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Alsa-user mailing list
> Alsa-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-user
Hi,
gettimeofday is not guaranteed to be monotonic and