Re: [Qemu-devel] [PATCH 00/20] Port audio to vmstate

[malc]

On Thu, 22 Oct 2009, Juan Quintela wrote:

> Hi
> 
> THis patch series port audio to vmstate.
> - fix compliation with DEBUG_PLIVE and DEBUG_AC97
> - unfold IO_READ_PROTO/IO_WRITE_PROTO and remove them
> - audio.c: the easiest thing to port (nothing inside)
> - sb16: port to vmstate, testing shows that it didn't survive migrations
>   very well (it happened before already).  Guest got this messages:
>    I got lots of underruns on the guest reported by alsa
>   on monitor I get lots of:
>    sb16: warning: command 0x42,2 is not truly understood yet

That's an attempt to do something or other with ADC (which is not
implmented for SB16) if my memory serves me.

> - es1370: the best working with migration.
> - adlib: I am not able to get sound out of it on any recent Fedora :(

It's an FM chip, trying to play PCM with it just not gonna fly.

> - cs4231a: it uses irq9, and that don't fly with acpi using that irq on qemu

-no-acpi

>   I disabled dma_running before loading state.  malc can you take a look here?

Can you please elaborate on what is exactly the problem.

>   I changed it to be able to use dma_running state field for state.

> - gus: no module anymore on Fedora

Use DOS.

> - ac97: from Anthony sugestion, remove the use of active array, it can be
>         recalculated.  All my testing (muted, not muted, ..., shows that
>         transmited array is the same one than the recalculated one).

Good.

>   ac97 don't work always with migration.
> 
> How did I test:
> - start a linux guest
> - inside there play a song (ogg123 foo.ogg)
> - in the middle of the song do savevm foo
> - later restart qemu with -loadvm foo option
> 
> What did I expect?:
> - I expected after ending the loadvm to hear the contination of the song.
> 
> Actual results:
> - es1370: the one working better
> - sb16: lots of underruns, very low sound quality.
> - ac97: mixed results.  The 1st 5-10 seconds always sound perfect
>    Then, between 10 and 30 seconds, sometimes it lots syncs and start playing 
> at
>    full speed, basiaclly no sound ouput. No sound after this is ever 
> generated.
>    If it is able to generate sound for 30-40 seconds, then sound works 
> correctly.
>   I tried to debug this, enabled all the audio DEBUG*, but I didn't find what 
> is
>   happening.
>   Notice that this happens when I launch from the same savevm image.  Some 
> times
>   it works well, some times it stops working at 5 seconds, sometimes it stops
>   working at 10 seconds, and so on.
>   My theory is that we are not saving all the state that we need, but I have 
> been
>   unable to found anything obviosu here.  malc, do you have any suggestion?

a. See how it behaves when you use OSS on the guest instead
   (might need clocking=48000 module parameter)

b. http://mpxplay.sourceforge.net/ is the DOS player which knows about
   i810 audio, see how it fares there
> 
> This took a lot because the ac97 testing, I thouguht the ac97
> problems were due to my changes.  It just happened that the 1st time
> that I loaded without my changes it just worked :( Problem can be
> reproduced as easily without any of my changes.  More work needs to
> be done to be sure that ac97 migrates correctly, but that is
> independent of this patch :)
> 

I don't like vmstate, but if you are dead bent on adding it to audio,
knock yourself out, IO_READ/WRITE_PROTO will stay. Can't help with
migration, GUS/Adlib are better tested with DOS and as for cs4231a i
don't quite understand what you are asking.

-- 
mailto:address@hidden