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:av1...@comtv.ru
