[alsa-devel] 1010lt (ice1712) asoundrc for 6 virtual mono cards question

Giovanni Maruzzelli gmaruzz.lists at gmail.com
Tue Apr 17 14:34:45 CEST 2007


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 at 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
>


More information about the Alsa-devel mailing list