esd audio output patch and debuging.

[Frederick Reeve]

Hello.

Attached you will find a patch for esd audio support in QEMU. It is more or less a large modification of audio/wavaudio.c. The patch will apply against the latest tarball release http://fabrice.bellard.free.fr/qemu/qemu-0.8.2.tar.gz (0.8.2 at the time of this writing). You will of course need libesd to compile this. To apply and test on linux/*nix simply:

$ cd qemu-src-dir
$ patch -Np1 -i path/to/patch/file
$ ./configure --enable-esd
$ make
$ sudo make install
$ export QEMU_AUDIO_DRV=esd
$ qemu (your options here) -soundhw es1370

You will also need to make sure esd is running when you do that of course. Sorry if that is insulting your intelegence. I just wanted to make everything very clear.

Now, I would not have you thinking this patch is a ready to go. I am writing this email because I am having a little trouble with this. It outputs sound fine but it produces artafacts. I'm not sure of the cause. Though I think it may have to do with frame alignment or with the conversion process (see code). It sounds like its clipping at high sample volume but this is the first time I have done anything with audio programing. I had planed to submit a completed patch but... anyway if anyone can point me in the right direction I would appreciate it. Alternately if you just want to fix it that would be great to. :-)

Just a note also on esd as far as I can tell it only supports 8 and 16 bit unsigned.

You may be wondering why with all the sound support options qemu has that I would want to write another one. Here is the logic. I am running an LTSP server setup. The servers I use have no sound card at all. Yet all the programs run on that server. The clients however have sound cards. None of QEMUs sound outputs will work without a sound card with the exeption of wav. None of QEMUs sound outputs can be broadcast over a network to clients but esd can. In short esd support allows me to run many QEMU copies on a server and output the audio to client terminals with out the server even having a sound card. esd is old but its about the only well supported option for network audio output in both linux distros and LTSP.

Background: I am maintaining LTSP servers for small elementy schools with "no budget". I currently maintain these networks for free to help with education though they may be offering me a job in the future. The teachers require a small few windows programs that do not run under wine. So I pipe qemu over the thin terms and use gdm so when they log into a qemu session it just pulls up windows full screen. Howerver they have resently needed sound and yes they actualy need it (though I whish I could say they didn't). School will be starting on september 4 and I am trying to be ready.

Anyway if you have any questions or I can help at all let me know.
If you can see what is wrong or have sugestions I welcome help. Also if you know of a better way that I would be happy to here it but after looking at our situation I think this sound module is the path of least resistance.

I thank you also for QEMU it has been a huge boon to the schools.

Thanks

Frederick

[malc]

Post by Frederick Reeve
Hello.
Attached you will find a patch for esd audio support in QEMU. It is more or

less a large modification of

Post by Frederick Reeve
audio/wavaudio.c. The patch will apply against the latest tarball release
http://fabrice.bellard.free.fr/qemu/qemu-0.8.2.tar.gz (0.8.2 at the time of

this writing). You

Post by Frederick Reeve
will of course need libesd to compile this. To apply and test on linux/*nix
$ cd qemu-src-dir
$ patch -Np1 -i path/to/patch/file
$ ./configure --enable-esd
$ make
$ sudo make install
$ export QEMU_AUDIO_DRV=esd
$ qemu (your options here) -soundhw es1370

[..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.

[Leonardo E. Reiter]

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>

Post by malc
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
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[malc]

Post by Leonardo E. Reiter
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.

Mute/wav rendering works by the virtue of having one clock source, i.e.
vm clock, furthermore the writes are non-blocking and instantaneous[1].
With esd one has to deal with two clock sources - one is vm clock other
is esds ability to consume the data. If vm clock is a bit lower w.r.t.
the audio clock esd uses - you will always starve the esd and in turn
audio subsystem it uses.

All in all real-time(in a loose sense) audio will only work if your
only constraint is the receivers ability to consume data. Given esds
interface the only safe way to do that is by emulating of a blocking
write, this in trun (given all other things into consideration) means
threads and interaction with QEMUs audio/main loop a'la sdlaudio or
coreaudio.

[1] Less so for wav due to I/O, but close enough for all intents and
purposes.

[malc]

Post by Frederick Reeve
Hello.

[..snip..]

Post by Frederick Reeve
Now, I would not have you thinking this patch is a ready to go. I
am writing this email because I am having a little trouble with
this. It outputs sound fine but it produces artafacts. I'm not
sure of the cause. Though I think it may have to do with frame
alignment or with the conversion process (see code). It sounds like
its clipping at high sample volume but this is the first time I have
done anything with audio programing. I had planed to submit a
completed patch but... anyway if anyone can point me in the right
direction I would appreciate it. Alternately if you just want to
fix it that would be great to.

Implemented the ideas described in previous post, latency is no good
(something to be expected) but the quality seems to be fine now.

Fabrice: i think this can be safely applied.

--
mailto:***@pulsesoft.com

[Peter Oberndorfer]

Post by malc

Post by Frederick Reeve
Hello.

[..snip..]

Post by Frederick Reeve
Now, I would not have you thinking this patch is a ready to go. I
am writing this email because I am having a little trouble with
this. It outputs sound fine but it produces artafacts. I'm not
sure of the cause. Though I think it may have to do with frame
alignment or with the conversion process (see code). It sounds like
its clipping at high sample volume but this is the first time I have
done anything with audio programing. I had planed to submit a
completed patch but... anyway if anyone can point me in the right
direction I would appreciate it. Alternately if you just want to
fix it that would be great to.

Implemented the ideas described in previous post, latency is no good
(something to be expected) but the quality seems to be fine now.
Fabrice: i think this can be safely applied.
--

 
     if (info->sign) {
-        memset (buf, 0x00, len << info->shift);
+        memset (buf, len << info->shift, 0x00);
     }
     else {
         if (info->bits == 8) {
-            memset (buf, 0x80, len << info->shift);
+            memset (buf, len << info->shift, 0x80);
         }


This part looks wrong (swapped parameters)

Greetings Peter

[Christophe Fillot]

Post by Peter Oberndorfer
if (info->sign) {
- memset (buf, 0x00, len << info->shift);
+ memset (buf, len << info->shift, 0x00);
}
else {
if (info->bits == 8) {
- memset (buf, 0x80, len << info->shift);
+ memset (buf, len << info->shift, 0x80);
}
This part looks wrong (swapped parameters)

Hello,

No, this is correct:

#include <string.h>

void *memset(void *s, int c, size_t n);

Best regards.

[Peter Oberndorfer]

Post by Christophe Fillot

Post by Peter Oberndorfer
if (info->sign) {
- memset (buf, 0x00, len << info->shift);
+ memset (buf, len << info->shift, 0x00);
}
else {
if (info->bits == 8) {
- memset (buf, 0x80, len << info->shift);
+ memset (buf, len << info->shift, 0x80);
}
This part looks wrong (swapped parameters)

Hello,
#include <string.h>
void *memset(void *s, int c, size_t n);

"The memset() function fills the first n bytes of the memory area pointed to by s with the constant byte c."

But isn't a size of 0x00 bytes a bit pointless?
Or is this a reverse patch? (doesn't look like one)

Post by Christophe Fillot
Best regards.

Greetings Peter

[malc]

Post by malc

Post by Frederick Reeve
Hello.

[..snip..]

š š šif (info->sign) {
- š š š šmemset (buf, 0x00, len << info->shift);
+ š š š šmemset (buf, len << info->shift, 0x00);
š š š}
š š šelse {
š š š š šif (info->bits == 8) {
- š š š š š šmemset (buf, 0x80, len << info->shift);
+ š š š š š šmemset (buf, len << info->shift, 0x80);
š š š š š}
This part looks wrong (swapped parameters)

Yes, that was fixed in CVS a while ago i just never updated my own
repository.

--
mailto:***@pulsesoft.com

[malc]

Attached patch fixes a couple of problems.

--
mailto:***@pulsesoft.com

[Frederick Reeve]

On Mon, 4 Sep 2006 04:07:51 +0400 (MSD)

Post by malc
Attached patch fixes a couple of problems.

I just want to say a big thanks to you for this. I have really had my hands full the last couple of days and have been putting in 12+ hour days at the schools trying to be ready. I was trying to figure out where to sneek in the time to fix this. This is really great. Even if you didn't do it for me I thank you none the less.

Big thanks! :-)

Frederick.

P.S. how long till a qemu release with the patches applied?