qemu-devel
[Top][All Lists]
Advanced

[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 13:45:58 +0100
User-agent: Mozilla/5.0 (X11; NetBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 23.01.2019 13:20, Gerd Hoffmann wrote:
>   Hi,
> 
>> Pulseaudio uses OSS backend on NetBSD anyway and we keep an in-kernel
>> mixer. So it adds nothing except additional intermediate layer.
>>
>> For non-professional audio purposes OSS is good enough for such
>> applications.
> 
> What happens if pulseaudio is running and using the sound device?  Can
> qemu open and use the device in parallel?  "in-kernel mixer" sounds like
> this is works and the kernel mixes the streams from all applications
> before sending it to the sound device.  Or will qemu get a -EBUSY?

Multiple applications can use the OSS/native kernel API device nodes
concurrently and the in-kernel mixer will take care of mixing.

This approach has some cons, but it's practical in the current state of
affairs.

As far as I'm aware FreeBSD uses a similar approach.

> 
> If parallel usage works we can default to oss I think.  Otherwise we
> should try pulse first, and in case it is not available (daemon not
> running) try oss next.
> 
> What about sdl?  Prefer oss over sdl I guess?  Or the other way around?
> 
> What is the native sound interface for openbsd btw?  oss doesn't
> compile (missing sys/soundcard.h header).
> 

OpenBSD uses sndio, a similar audio daemon to pulseaudio and it's
enforced for all [well integrated] audio applications.

SDL is an optional intermediate layer kept for practical/compatibility
purposes, but all software shall use sndio natively.

> cheers,
>   Gerd
> 
> 


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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