qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 11/11] audio/rfc: remove PLIVE and PERIOD opt


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [PATCH v4 11/11] audio/rfc: remove PLIVE and PERIOD options
Date: Wed, 14 Mar 2012 12:49:13 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1

On 03/14/12 12:20, Marc-André Lureau wrote:
> Hi
> 
> On Wed, Mar 14, 2012 at 10:22 AM, Gerd Hoffmann <address@hidden> wrote:
>> On 03/13/12 16:47, malc wrote:
>>> On Tue, 13 Mar 2012, Marc-Andr? Lureau wrote:
>>>
>>>> - period seems to be unused now
>>
>>> Period on the other hand is unused because i somehow missed the subtle
>>> change of behavior in one of the patches made by, i think, Gerd.
>>
>> Uhm, which patch?  I think that wasn't intentional, at least I can't
>> remember intentionally disabling period.  Maybe I missed the subtle
>> change of behavior too.
> 
> Could be:
> 
> 39deb1e496de81957167daebf5cf5d1fbd5e47c2

Yes, looks like this one is it.

>> I do see the point in having this configurable as this is a cpu overhead
>> vs. latency tradeoff which one might want to tweak depending on the use
>> case.
> 
> But that would impact a/v sync, or can you report added latency back
> to the guest somehow? I imagine audio backend latency should depend on
> the configured device buffering/latency, not on an environment tweak.

Sure, with lower latency you get better a/v sync too.

Guest interfacing is next to impossible I think, simply because real
hardware has no need for that and thus the interfaces simply don't exist
in the hardware we are emulating.  We can try to fix that with a virtio
soundcard which has such interfaces, but it could be this simply shifts
the issue from the driver/hardware interface to the os-kernel/driver
interface.

cheers,
  Gerd



reply via email to

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