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( ×tamp_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( ×tamp_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) * 1000000); > gettimeofday( ×tamp_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 > 10000, 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 : 10000 > 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 <pid-of-RTC> > # chrt -f -p 89 <pid-of-IntelSST> > # chrt -f -p 89 <pid-of-IntelSSP> > [/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@xxxxxxxxxxxxxxxxxxxxx > https://lists.sourceforge.net/lists/listinfo/alsa-user Hi, gettimeofday is not guaranteed to be monotonic and also may not have the desired accuracy on your system, so my guess is that your measurement process is not accurate enough. Maybe have a look at clock_gettime or another more accurate method that is suitable for timing instead. Cheers Markus ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ Alsa-user mailing list Alsa-user@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-user
