[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