RT-timings when recording

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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( &timestamp_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( &timestamp_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( &timestamp_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



[Index of Archives]     [ALSA Devel]     [Linux Audio Users]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]

  Powered by Linux