malc wrote:
> On Mon, 14 Sep 2009, Jan Kiszka wrote:
> 
>> malc wrote:
>>> On Sun, 13 Sep 2009, Jan Kiszka wrote:
>>>
>>>> Jan Kiszka wrote:
>>>>> malc wrote:
>>>>>> Does following help?
>>> [..snip.]
>>>
>>>>> Nope, still full CPU load.
>>>> Forgot to mention: I also tried OSS before, but it suffered the same
>>>> way, and polling had to be disabled.
>>>>
>>> Aha, i've commited this patch and another which correct premature
>>> closure of audio device (for both OSS and ALSA), can not notice
>>> anything particularly wrong when running with poll enabled now, can
>>> you please retest things on your end, once again it would be nice to
>>> have both audio systems, tested. Thanks in advance.
>>>
>> Sorry, both audio systems still require to disable polling for a normal
>> cpu load.
> 
> I believe the problem is within wm8750(/musicpal combination?)
> wm8750_set_format creates a bunch of ADC voices and enables them, but
> no reads are ever performed, so ALSA/OSS quickly fills the buffers
> and then stops reading into them thus leaving respective fd's in a
> selectable state. My main machine lacks ADC so i was unable to reproduce
> the behaviour you've seen on it on another box the issue is indeed very
> visible. Setting QEMU_OSS_ADC_DEV to /dev/moo or commenting out
> AUD_set_active_in in wm8750.c cures the problem as does, contrary to
> your report, setting QEMU_AUDIO_ADC_TRY_POLL to 0.

Cannot confirm this: Neither commenting out AUD_set_active_in nor
"tuning" QEMU_OSS_ADC_DEV makes any difference here.

But what I observed is that once I tune in some station / play some song
on the Musicpal, the load goes down and stays in normal range. Will dig
a bit in this direction, trying to find out what is different then.

Jan