Hi all, please let me know how I can give more/different info and testing.
my app makes a simple readi-writei loop (with a select before the readi) on six virtual asym duplex devices each one with 1 channel, S16_LE, 8000hz
In this case I'm using a 1010lt (ice 1712).
the issue that puzzles me is that the cpu load stay at 0.0% all the time, with very strong spikes at regular intervals. I've seen this exact same behavior also using arecord/aplay and test/latency on plugins, and I suspect is not specific for ice1712, but for any card type.
I've oprofiled alsa-lib 1-0-13, both using dmix-dsnoop asound.conf and using dshare-dsnoop devices.
Before each run I've : # opcontrol --shutdown # opcontrol --reset # opcontrol --no-vmlinux # opcontrol --start
The two results follows, at the end the asound.conf with dsnoop-dshare (the other one simply substitute dmix to dshare) TAKE NOTE that the running times was very different, so different number of samples:
******************************* opreport -l /usr/lib/libasound.so.2.0.0 using dsnoop-dmix devices gives me: samples % symbol name 4806 21.5913 mix_areas2 3550 15.9486 snd_pcm_linear_convert 3262 14.6547 snd_pcm_area_copy 936 4.2050 snd_pcm_state 771 3.4638 snd_pcm_dmix_sync_area 760 3.4143 snd_pcm_generic_state 713 3.2032 snd_pcm_hw_state 623 2.7989 snd_pcm_dsnoop_sync_ptr 382 1.7162 snd_pcm_read_areas 378 1.6982 snd_pcm_mmap_begin 365 1.6398 snd_pcm_write_areas 345 1.5499 snd_pcm_plugin_avail_update 308 1.3837 snd_pcm_mmap_commit 303 1.3612 snd_pcm_dmix_sync_ptr 293 1.3163 snd_pcm_hwsync 272 1.2220 .plt 253 1.1366 snd_pcm_areas_from_buf 230 1.0333 __i686.get_pc_thunk.bx 227 1.0198 snd_pcm_readi 215 0.9659 snd_pcm_dsnoop_state 208 0.9345 snd_timer_read 197 0.8850 snd_pcm_plugin_write_areas 194 0.8716 snd_pcm_dmix_mmap_commit 186 0.8356 snd_timer_hw_read 185 0.8311 snd_pcm_dmix_state 168 0.7548 snd_pcm_plugin_read_areas 166 0.7458 snd_pcm_writei 153 0.6874 snd_pcm_dsnoop_mmap_commit 145 0.6514 snd_pcm_generic_hwsync 145 0.6514 snd_pcm_plugin_readi 135 0.6065 snd_pcm_avail_update 133 0.5975 snd_pcm_mmap_appl_forward 124 0.5571 snd_pcm_dsnoop_hwsync 120 0.5391 snd_pcm_direct_clear_timer_queue 120 0.5391 snd_pcm_linear_write_areas 119 0.5346 snd_pcm_plugin_writei 101 0.4537 snd_pcm_dmix_avail_update 94 0.4223 snd_pcm_linear_read_areas ..........................
***************************************** opreport -l /usr/lib/libasound.so.2.0.0 using dsnoop-dshare devices gives me: samples % symbol name 7818 29.4175 snd_pcm_area_copy 5332 20.0632 snd_pcm_linear_convert 1161 4.3686 snd_pcm_state 849 3.1946 snd_pcm_hw_state 770 2.8974 snd_pcm_dsnoop_sync_ptr 768 2.8898 snd_pcm_generic_state 679 2.5549 snd_pcm_dshare_sync_area 500 1.8814 snd_pcm_read_areas 484 1.8212 snd_pcm_write_areas 482 1.8137 snd_pcm_mmap_begin 442 1.6632 snd_pcm_plugin_avail_update 398 1.4976 snd_pcm_hwsync 397 1.4938 snd_pcm_mmap_commit 343 1.2906 snd_pcm_dshare_mmap_commit 323 1.2154 snd_pcm_areas_from_buf 322 1.2116 snd_pcm_dshare_sync_ptr 319 1.2003 .plt 305 1.1477 snd_pcm_direct_clear_timer_queue 299 1.1251 __i686.get_pc_thunk.bx 292 1.0987 snd_timer_hw_read 281 1.0573 snd_pcm_dsnoop_state 274 1.0310 snd_timer_read 272 1.0235 snd_pcm_dsnoop_mmap_commit 232 0.8730 snd_pcm_plugin_write_areas 227 0.8542 snd_pcm_plugin_read_areas 222 0.8353 snd_pcm_mmap_appl_forward 222 0.8353 snd_pcm_readi 219 0.8241 snd_pcm_plugin_readi 202 0.7601 snd_pcm_dshare_state 192 0.7225 snd_pcm_generic_hwsync 189 0.7112 snd_pcm_writei 184 0.6924 snd_pcm_plugin_writei 177 0.6660 snd_pcm_dsnoop_hwsync 169 0.6359 snd_pcm_linear_read_areas 164 0.6171 snd_pcm_avail_update 161 0.6058 snd_pcm_dshare_avail_update 155 0.5832 snd_pcm_format_physical_width 137 0.5155 snd_pcm_linear_write_areas 82 0.3085 __i686.get_pc_thunk.cx 81 0.3048 snd_pcm_dsnoop_avail_update 76 0.2860 snd_pcm_dshare_hwsync 29 0.1091 get_char 26 0.0978 check_linear_format 17 0.0640 snd_pcm_build_linear_format 16 0.0602 snd_pcm_format_mask_test 16 0.0602 snd_pcm_hw_refine_soft 15 0.0564 _snd_config_search 12 0.0452 get_nonwhite 12 0.0452 snd_input_getc 11 0.0414 snd_pcm_plug_slave_format 10 0.0376 get_string *********************************************************************
That is the asoundrc with dsnoop-dshare (dmix), my app was using the cell3-cell8 devices:
########### begin ################### pcm.c3 { type dsnoop ipc_key 56789 slave { pcm "hw:0,0" rate 8000 period_time 0 period_size 320 channels 12 format S32_LE } bindings { 0 2 } } pcm.capt3 { type plug slave.pcm c3 }
pcm.c4 { type dsnoop ipc_key 56789 slave { pcm "hw:0,0" rate 8000 period_time 0 period_size 320 channels 12 format S32_LE } bindings { 0 3 } } pcm.capt4 { type plug slave.pcm c4 }
pcm.c5 { type dsnoop ipc_key 56789 slave { pcm "hw:0,0" rate 8000 period_time 0 period_size 320 channels 12 format S32_LE } bindings { 0 4 } } pcm.capt5 { type plug slave.pcm c5 }
pcm.c6 { type dsnoop ipc_key 56789 slave { pcm "hw:0,0" rate 8000 period_time 0 period_size 320 channels 12 format S32_LE } bindings { 0 5 } } pcm.capt6 { type plug slave.pcm c6 }
pcm.c7 { type dsnoop ipc_key 56789 slave { pcm "hw:0,0" rate 8000 period_time 0 period_size 320 channels 12 format S32_LE } bindings { 0 6 } } pcm.capt7 { type plug slave.pcm c7 }
pcm.c8 { type dsnoop ipc_key 56789 slave { pcm "hw:0,0" rate 8000 period_time 0 period_size 320 channels 12 format S32_LE } bindings { 0 7 } } pcm.capt8 { type plug slave.pcm c8 }
############################# ############################# pcm.p3 { type dshare #ipc_key 123456789 ipc_key 56789 slave { pcm "hw:0,0" rate 8000 period_time 0 period_size 320 channels 10 format S32_LE } bindings { 0 2 } } pcm.play3 { type plug slave.pcm p3 }
pcm.p4 { type dshare #ipc_key 123456789 ipc_key 56789 slave { pcm "hw:0,0" rate 8000 period_time 0 period_size 320 channels 10 format S32_LE } bindings { 0 3 } } pcm.play4 { type plug slave.pcm p4 }
pcm.p5 { type dshare #ipc_key 123456789 ipc_key 56789 slave { pcm "hw:0,0" rate 8000 period_time 0 period_size 320 channels 10 format S32_LE } bindings { 0 4 } } pcm.play5 { type plug slave.pcm p5 }
pcm.p6 { type dshare #ipc_key 123456789 ipc_key 56789 slave { pcm "hw:0,0" rate 8000 period_time 0 period_size 320 channels 10 format S32_LE } bindings { 0 5 } } pcm.play6 { type plug slave.pcm p6 }
pcm.p7 { type dshare #ipc_key 123456789 ipc_key 56789 slave { pcm "hw:0,0" rate 8000 period_time 0 period_size 320 channels 10 format S32_LE } bindings { 0 6 } } pcm.play7 { type plug slave.pcm p7 }
pcm.p8 { type dshare #ipc_key 123456789 ipc_key 56789 slave { pcm "hw:0,0" rate 8000 period_time 0 period_size 320 channels 10 format S32_LE } bindings { 0 7 } } pcm.play8 { type plug slave.pcm p8 }
#################################### #################################### pcm.cell3 { type asym playback.pcm "play3" capture.pcm "capt3" } pcm.cell4 { type asym playback.pcm "play4" capture.pcm "capt4" }
pcm.cell5 { type asym playback.pcm "play5" capture.pcm "capt5" } pcm.cell6 { type asym playback.pcm "play6" capture.pcm "capt6" } pcm.cell7 { type asym playback.pcm "play7" capture.pcm "capt7" } pcm.cell8 { type asym playback.pcm "play8" capture.pcm "capt8" }
#################################### #################################### ctl.cell3 { type hw card 0 } ctl.cell4 { type hw card 0 } ctl.cell5 { type hw card 0 } ctl.cell6 { type hw card 0 } ctl.cell7 { type hw card 0 } ctl.cell8 { type hw card 0 }
########### end ###################
On 4/17/07, Takashi Iwai tiwai@suse.de wrote:
At Fri, 13 Apr 2007 16:34:55 +0200, Giovanni Maruzzelli wrote:
btw, I tried the latency.c app in polling mode too (./latency -P plughw:0 -C plughw:0 -f S16_LE -c 1 -r 8000 -m 320 -M 960 -s 600 -p) with same "spiking" results.
Which ALSA version are you using?
The CPU usage is relatively easy to analyze. For example, you can try oprofile.
Takashi