[v3]
- Fix UNUSED size to 3 for ac97.
- use %zd for sizeof() values insead of %lu.

[v2]
- rebased to top of qemu/master
- removed IO_READ/WRITE_PROTO cleanups.
- rest is the same that previous round.  malc agreed to let them it.

Later, Juan.

[v1]

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
- es1370: the best working with migration.
- adlib: I am not able to get sound out of it on any recent Fedora :(
- cs4231a: it uses irq9, and that don't fly with acpi using that irq on qemu
  I disabled dma_running before loading state.  malc can you take a look here?
  I changed it to be able to use dma_running state field for state.
- gus: no module anymore on Fedora
- 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).
  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?

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 :)

Later, Juan.


Juan Quintela (10):
  audio: fix compilation of DEBUG_PLIVE
  audio: port to vmstate
  sb16: port to vmstate
  es1370: port to vmstate
  c4231a: port to vmstate
  gus: port to vmstate
  ac97: sizeof needs %zd
  ac97: recalculate active after loadvm
  ac97: up savevm version and remove active from state
  ac97: port to vmstate

 audio/audio.c          |   26 +++-----
 audio/audio_template.h |    6 +-
 hw/ac97.c              |  113 ++++++++++++++------------------
 hw/cs4231a.c           |   58 +++++++++--------
 hw/es1370.c            |   77 ++++++++++------------
 hw/gus.c               |   47 +++++---------
 hw/sb16.c              |  168 +++++++++++++++++------------------------------
 7 files changed, 205 insertions(+), 290 deletions(-)



Reply via email to