qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: Audio


From: malc
Subject: [Qemu-devel] Re: Audio
Date: Fri, 18 Sep 2009 23:29:50 +0400 (MSD)

On Fri, 18 Sep 2009, Jan Kiszka wrote:

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

Just so that i have more information to try and reproduce it, can you
send me the output of -audio-help (so that i can see what values are
really set), the configure line (so that i can see whether i should
myself throw -enable-iothread into the mix) and perhaps the name of
the sound card.

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

Guest under load? Like when is musicpal under load (apart from
startup)?

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

What's the output when running with QEMU_ALSA_VERBOSE=1?

P.S. Please send the things to me directly, let's not polute the
     list with tons of uninteresting information.

-- 
mailto:address@hidden




reply via email to

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