From: Jan Kiszka <jan.kiszka@web.de>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [4249] Improve audio api use in WM8750.
Date: Fri, 25 Apr 2008 01:57:21 +0200 [thread overview]
Message-ID: <48111E61.9050002@web.de> (raw)
In-Reply-To: <fb249edb0804241634q745bad0cpbce40f3087036f6a@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1966 bytes --]
andrzej zaborowski wrote:
> On 24/04/2008, Jan Kiszka <jan.kiszka@web.de> wrote:
>> Hi Andrzej,
>>
>> Andrzej Zaborowski wrote:
>> > Revision: 4249
>> ...
>> > static void wm8750_audio_out_cb(void *opaque, int free_b)
>> > {
>> > struct wm8750_s *s = (struct wm8750_s *) opaque;
>> >
>> > - s->req_out = free_b;
>> > - s->data_req(s->opaque, free_b >> 2, s->req_in >> 2);
>> > - wm8750_out_flush(s);
>> > + if (s->idx_out >= free_b) {
>> > + s->idx_out = free_b;
>> > + s->req_out = 0;
>> > + wm8750_out_flush(s);
>> > + } else
>> > + s->req_out = free_b - s->idx_out;
>> > +
>> > + s->data_req(s->opaque, s->req_out >> 2, s->req_in >> 2);
>>
>> Please make sure that the callback is always issued _before_ the flush
>> (keep in mind: it may increase the amount of data that has to be flushed
>> ASAP!). And this change also leaves the MusicPal broken.
>
> The idea is to output free_b bytes immediately if we have that many in
> the buffer (it could happen assuming that free_b value can change
Wrong ordering: If there has been a _relevant_ amount of data (not a few
10 bytes) hanging around in our internal buffer between the guest has
filled it during the last callbacks and the host reports demand via the
new callback, that data was missing in the host's audio buffer! That's
what I saw (heard) with the old version (the current one even causes
total silence).
> between callbacks). I'm not sure how this can break something: if
> *inside* the data_req() callback we receive enough bytes to fill the
> the whole buffer then dac_dat() will call out_flush().
>
> Without that all buffering becomes useless because we flush every
> sample we receive and we start to crawl.
Nothing is crawling here, just use a reasonable threshold for flushing
_after_ the callback. Need to check, but maybe we can even wait the a
full buffer.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
next prev parent reply other threads:[~2008-04-24 23:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-24 21:01 [Qemu-devel] [4249] Improve audio api use in WM8750 Andrzej Zaborowski
2008-04-24 21:30 ` Jan Kiszka
2008-04-24 23:34 ` andrzej zaborowski
2008-04-24 23:57 ` Jan Kiszka [this message]
2008-04-25 0:09 ` Jan Kiszka
2008-04-25 0:23 ` andrzej zaborowski
2008-04-25 0:45 ` Jan Kiszka
2008-04-25 1:00 ` Jan Kiszka
2008-04-25 1:41 ` andrzej zaborowski
2008-04-25 1:05 ` andrzej zaborowski
2008-04-25 1:10 ` Jan Kiszka
2008-04-25 0:15 ` andrzej zaborowski
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=48111E61.9050002@web.de \
--to=jan.kiszka@web.de \
--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).