isa sound cards: module-alsa-(sink|source) eats all CPU (100%)

[verem]

I run pulseaudio on some old PCs with ISA sound board. If module-alsa-* selected for operating with hardware pulseaudio eat all CPU (on dual processor computer it eat both CPU time, but if i disable either module-alsa-sink or module-alsa-source during running pulseaudio it eat only one CPU).

I start pulseaudio by command:

/usr/bin/pulseaudio -vvvvvv --system \

--exit-idle-time=-1 \ --disable-shm \ --no-cpu-limit \ --resample-method=trivial \ --high-priority \ -L "module-alsa-sink device=hw:0" \ -L "module-alsa-source device=hw:0" \ -L "module-esound-protocol-tcp auth-ip-acl=127.0.0.1 auth-anonymous=1" \ -L "module-native-protocol-tcp auth-ip-acl=127.0.0.1 auth-anonymous=1" \ -L module-volume-restore \ -L module-rescue-streams \ -L module-native-protocol-unix \ -n

Executing of pulseaudio (with alsa-(sink|source)) could terminated only by kill -9.

If i switch to module-oss it works, but very often i got warning about underrun, but it works.

Alsa driver for that ISA boards works, at least i hear sound during executing command:

aplay -Dhw:0 Front_Center.way

dmesg and pulseaudio stderr output attached from different old PCs.

[verem]

dmesg output from LT-9

[verem]

pulseaudio output from LT-9

[verem]

dmesg output from LT-25

[verem]

pulseaudio output from LT-25

[lennart]

Might be a buggy audio driver that signals "writability" too often.

[verem]

Replying to lennart:

Might be a buggy audio driver that signals "writability" too often.

I noticed that it only happens to ISA PnP boards, for PCI audio adapters it does happens. I checked with aplay - no problem, also almost no problem if i use module-oss

[lennart]

aplay doesn't use poll() on the fds in question. PA makes use of a much larger set of ALSA API functions than aplay. If something works in aplay it doesn't mean the driver works completely correctly.

[verem]

Replying to lennart:

aplay doesn't use poll() on the fds in question. PA makes use of a much larger set of ALSA API functions than aplay. If something works in aplay it doesn't mean the driver works completely correctly.

i just tested agains test/pcm.c (http://git.alsa-project.org/?p=alsa-lib.git;a=blob_plain;f=test/pcm.c;hb=HEAD) in different modes:

./pcm -m write

./pcm -m write_and_poll

./pcm -m async

no problems at all, i hear a tone, CPU load approx 4% on PII266Mhz.

could you post modified test/pcm.c exaclty with same method used in $subj to check your idea?

[lennart]

This might be related to a broken snd_pcm_avail() implementation of the soud drivers.

Please follow what is suggested at the end of wiki:BrokenSoundDrivers