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
