OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [virtio-dev] [PATCH] snd: Add virtio sound device specification

On 14.11.2019 22:29, Mark Brown wrote:
On Wed, Nov 13, 2019 at 01:01:56PM +0100, Anton Yakovlev wrote:
On 11.11.2019 20:39, Mark Brown wrote:

Can you provide examples of host systems which have interfaces that
provide absolutely no timing information that can be used by
applications?  It's common for systems to provide simplified interfaces
for applications that have simple needs (especially "please play this
track" style interfaces) but there's usually something richer there for
the applications that need it.

Two common cases: PulseAudio and QEmu. PA has some timing info, but it
states clear that it's "rough estimations".

PA does a lot better than it claims, and bear in mind that the PA
specific APIs are simplified ones and it does expose emulations of far
richer interfaces.

Yes, certainly, PA itself is pretty good.

                                             QEmu provides nothing in this
regard. And it's understandable, since they need to provide some unified
API/strategy to clients while hiding details of actual backends (that could
be a PCM device, bluetooth, network, whatever).

My understanding was that QEmu emulated some regular sound hardware?

Yes, it is. And all emulated sound hardware communicate with built-in QEmu audio mixer.

Yes, it's true. And it's not like we against having error reporting. The
problem is there's no deterministic way how to treat such errors in

I think you are being overly pessimistic about what is posible and not
providing any room for better quality of implementation.  I'm not seeing
how a virtualized system is that different to an application running
with a sound server.

That's why we needed discussion. It makes little sense to put something that
you are not sure into a public spec.


It's like with periods discussed above. If a device is a native
ALSA-application and talks directly with hardware in exclusive mode, then
it's capable to signal actual underflow/overflow condition reported by ALSA
layer. But if a device is a client of sw mixer server, then reported error
might be server-specific (like "underflow" means, that server's queue is
empty, but real hardware buffer still might contain 10ms or 50ms of frames
for playback; i.e. guest application probably has enough time to provide new

You're describing a quality of implementation issue there, if something
is indicating that it's underlowed when it has not in fact underflowed
then it's buggy.

Not necessary. It may implement its own workflow. And if our terms do not
align with their, it does not necessary mean they have buggy anything.

To me it's about what the spec says - if the spec says X and you do Y
then that's quality of implementation.  There can definitely be issues
translating the spec language into something that's useful in the
context of the specific implementation but that's a normal part of
interacting with a spec.

In that regards yes, you are right. We just talked about features that could be useful in one particular case and totally useless in another one.

At the end, the main source of xrun conditions is delayed execution of a
virtual machine or an application in it (like double scheduling and so on).
And 44100Hz is still ~44100 frames per seconds. After different experiments,
we decided just to stick to simpler design.

People are more than capable of writing software which has trouble even
without any involvement from virtualization!  Applications like VoIP,
music production and gaming frequently try to push latencies very low.

I'm not sure what you mean by experiments here but I don't really see
how they are relevant here, obviously if the system is working well then
none of this will come up - under and overflow are about situations
where things go wrong.

I meant, what did work good enough and what not.

I see.  Part of my pessimism about the need for error handling here is
that there's a great deal of quality variation in audio hardware and
software out there so lots of potential for things to not behave as
expected when put under stress.  Adding a virtualization layer seems
like the sort of stress that might cause problems, hopefully not but it
seems better to at least have the facilities in the spec so it's easier
to resolve any problems that do come up.

Good, I will summarize all the points from our discussion and we will decide how to improve current spec draft.

Again, it could be an optional feature if device has reliable source of
error notifications.

Right now there is no option to provide the feature.

It's under discussion right now.

Ah, I see - I may be confused about the process, I saw a call for votes
which looked like things were pretty final.

We had no comments for quite a long time. And it looked like the spec is ready.

Anton Yakovlev
Senior Software Engineer

OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin

Phone: +49 30 60 98 54 0
E-Mail: anton.yakovlev@opensynergy.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]