qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: Audio


From: Jan Kiszka
Subject: [Qemu-devel] Re: Audio
Date: Fri, 18 Sep 2009 20:49:40 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

Jan Kiszka wrote:
> 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.

The situation now looks like this:

QEMU_AUDIO_DAC_TRY_POLL=0 is required to avoid that Musicpal emulation
generates high load after boot-up and before the first sound playback
(interestingly not including the startup sound of the Musicpal). ADC
subsystem or settings have no effect on this.

Moreover, the playback quality under ALSA suffers in polling mode when
the guest CPU is under load.

Jan

PS: Independent of the polling issue, QEMU_ALSA_DAC_BUFFER_SIZE=0
currently gives skip-free playback for me while the default does not.
Not sure what changed, but I suspect it's some local package.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]