qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [Try2][PATCH] Initial implementation of a mpeg1 lay


From: François Revol
Subject: Re: [Qemu-devel] Re: [Try2][PATCH] Initial implementation of a mpeg1 layer2 streaming audio driver.
Date: Fri, 12 Nov 2010 17:54:05 +0100

Le 12 nov. 2010 à 15:32, Anthony Liguori a écrit :

>> I did try years ago, but at least the current wav driver really didn't like 
>> fifos back then. I recall trying for hours to get it pipe to ffmpeg or 
>> others without much luck.
>> 
>> Also, this poses several problems about the control of the external process 
>> (respawn on listener disconnection, close on exit...).
> 
> Doing encoding in QEMU is going to starve the guest pretty bad.  For an x86 
> guest, that's going to result in issues with time drift, etc.
> 
> Making reencoding with an external process work a bit more nicely also has 
> the advantage of making this work with other formats like Ogg which are a bit 
> more Open Source friendly.

The current patch uses a separate thread, but since I clone this part from the 
esdaudio code I didn't check what it was doing. It seems it's not really 
queueing anything though except the single mix buffer, which kind of defeats 
the purpose of having a separate thread. This might explain why it lags so much 
here... I tried increasing the buffer size and lowering the threshold but it 
doesn't seem to help.

I agree it'd be better to use external programs when possible but as I said 
it's a bit harder to handle the errors and such, and I wanted to have something 
working.
Also, it requires more work to set it up for users, they must install the 
externals, figure out the command line options...
Possibly we can provide default templates for known programs, either text files 
with % escaping for args, or just a shell script passing env vars maybe...

Besides, external or not, IIRC a pipe is by default 4kB max, which isn't much 
better for decoupling the processing on its own, if the encoder is too slow it 
will still starve the audio thread, and the rest. Also it all requires more 
context switching and IPC, which increase the total processing time.

So I think it might be interesting to have both.

I'll see if I can buffer a bit more in the twolame code and if it helps, then 
I'll try to merge with the failed attempts I have around at using external 
progs.

François.


reply via email to

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