[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default

From: Kamil Rytarowski
Subject: Re: [Qemu-devel] [PATCH 4/4] [RfC] audio: probe audio drivers by default
Date: Wed, 23 Jan 2019 12:30:28 +0100
User-agent: Mozilla/5.0 (X11; NetBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 23.01.2019 12:16, Peter Maydell wrote:
> On Wed, 23 Jan 2019 at 11:09, Kamil Rytarowski <address@hidden> wrote:
>> On 23.01.2019 11:59, Peter Maydell wrote:
>>> On Wed, 23 Jan 2019 at 10:37, Kamil Rytarowski <address@hidden> wrote:
>>>> OSS is the portable UNIX audio backend. We could point some flaws in it,
>>>> but it's a good enough for portable UNIX applications. The question is
>>>> what UNIX-like desktop OS does not implement it or removed it.
>>> If your desktop's native audio API is pulse, like Linux's often
>>> is, then you want to use pulse directly, because the compat layers
>>> are (or were last time I looked) not great, and typically add
>>> in an extra thread and an extra layer of buffering, which means
>>> more latency or more audio dropouts or both.
>> Pulseaudio uses OSS backend on NetBSD anyway and we keep an in-kernel
>> mixer. So it adds nothing except additional intermediate layer.
> Yes, exactly -- if your native API is OSS, we should be using that.
> It's the compat layers that are problematic, so we can't just use
> a single portable API on all platforms.

OSS is +/- native for NetBSD, it uses a different selection of ioctl(2)s
and a thin compat layer in the kernel.

Maintaining a backend support for SunOS API (our current native audio)
does not win us at this point anything and it makes things worse as
there would be a need for more code to maintain. In my opinion it's
better to not add support for it in 3rd party software and look for
moving forward into sound subsystem on par with more modern solutions.
Until we will get there, the right thing is to use OSS.

>> For non-professional audio purposes OSS is good enough for such
>> applications.
> QEMU has to care about the buffering that compat layers add,
> because guest programs tend to work on the assumption that they're
> talking directly to the hardware and extra buffering trips them up.
> thanks
> -- PMM

Correct, we don't want a stack of unwanted software like pulseaudio.

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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