Re: [Qemu-devel] Re: [Try2][PATCH] Initial implementation of a mpeg1 layer2 streaming audio driver.

[Anthony Liguori <anthony@codemonkey.ws>]

On 11/12/2010 10:54 AM, François Revol wrote:
> 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.
>    

Okay, but my thinking was that we'd do something like:

audio_capture "capture_command -opt=val -opt2=val" ...

Which would make it very easy to tie into lame, oggenc, etc.

Having simple alias commands like mp3_capture and ogg_capture that 
invoke common tools with reasonable options also would be a bonus.

Regards,

Anthony Liguori

> François.