qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Leonardo E. Reiter" <lreiter@win4lin.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: esd audio output patch and debuging.
Date: Thu, 31 Aug 2006 13:19:16 -0400	[thread overview]
Message-ID: <44F71A14.6070509@win4lin.com> (raw)
In-Reply-To: <loom.20060831T115142-204@post.gmane.org>

malc,

Other than the lack of error handling and blocking mode, what is the 
problem with using QEMU's VM clock as the audio clock source?  In my 
experience from older projects using esd (not related to QEMU), it is 
almost impossible to get reliable timing from ESD, especially if you are 
transporting over a network.  The timing will certainly not be accurate 
enough for example for Windows guests using Windows Media Player, etc. 
Plus, you have to factor in socket buffering and underruns due to 
network latency if you expect anything synchronous on the socket.  So 
what is the reason for objecting to the QEMU vm clock, much like the 
mute audio driver uses?  I just want to know your reasoning for it just 
to further my own understanding.

Thank you,

Leo Reiter

P.S. I can attest that using the mute audio driver you used, if the host 
clock resolution is well above 100Hz such as on Linux and FreeBSD, 
Windows Media Player guests have no problem with multimedia streams.  I 
keep referring to WMP because it is extremely picky about timing in 
general, more so than other applications even.  It seems that QEMU's vm 
clock is accurate enough for this task, just FYI.

malc wrote:
<snip>

> There are several problems with this patch:
> 
> a. esd_play_stream returns negative values on error (not zero)
> b. esd_play_stream can return with EINTR
> c. no error checking whatsoever on write to the socket
> d. the socket is most likely opened in blocking mode
> e. i don't think it's wise to use anything other than esd itself
>    as a audio-clock source
> 
> So basically the only way it can work (given the circumstances)
> is to have a thread that would perform a blocking write to the
> esd, and the rest as per coreaudio and sdladuio.
> 
> P.S. Oh yeah, mixing tabs and spaces is also not a great idea.
> 
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

-- 
Leonardo E. Reiter
Vice President of Product Development, CTO

Win4Lin, Inc.
Virtual Computing that means Business
Main: +1 512 339 7979
Fax: +1 512 532 6501
http://www.win4lin.com

  reply	other threads:[~2006-08-31 17:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-30 15:45 [Qemu-devel] esd audio output patch and debuging Frederick Reeve
2006-08-31 11:46 ` [Qemu-devel] " malc
2006-08-31 17:19   ` Leonardo E. Reiter [this message]
2006-09-01 19:02     ` malc
  -- strict thread matches above, loose matches on Subject: below --
2006-09-03 22:33 malc
2006-09-04  8:56 ` Peter Oberndorfer
2006-09-04 12:01   ` Christophe Fillot
2006-09-04 14:04     ` Peter Oberndorfer
2006-09-04 12:02   ` malc
2006-09-04  0:07 malc
2006-09-04  5:33 ` Frederick Reeve

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44F71A14.6070509@win4lin.com \
    --to=lreiter@win4lin.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).