[Top][All Lists]
[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
- Re: [Qemu-devel] Solaris SPARC guest on QEMU, (continued)
- Re: [Qemu-devel] Solaris SPARC guest on QEMU, Artyom Tarasenko, 2009/09/15
- Re: [Qemu-devel] Solaris SPARC guest on QEMU, Blue Swirl, 2009/09/15
- Re: [Qemu-devel] Solaris SPARC guest on QEMU, Stuart Brady, 2009/09/15
- Re: [Qemu-devel] Solaris SPARC guest on QEMU, Artyom Tarasenko, 2009/09/16
- Re: [Qemu-devel] Solaris SPARC guest on QEMU, Luis Freitas, 2009/09/16
- Re: [Qemu-devel] Solaris SPARC guest on QEMU, Artyom Tarasenko, 2009/09/16
- [Qemu-devel] Re: Audio, Jan Kiszka, 2009/09/15
- [Qemu-devel] Re: Audio, Jan Kiszka, 2009/09/18
- [Qemu-devel] Re: Audio,
malc <=
- [Qemu-devel] Re: Audio, malc, 2009/09/13
- Re: [Qemu-devel] Re: Audio, Avi Kivity, 2009/09/15
- Re: [Qemu-devel] Re: Audio, malc, 2009/09/22