<div class="gmail_quote">On Fri, Jun 25, 2010 at 12:32 PM, Attila Sukosd <span dir="ltr"><<a href="mailto:attila.sukosd@gmail.com" target="_blank">attila.sukosd@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div><div class="gmail_quote">On Fri, Jun 25, 2010 at 11:41 AM, Gerd Hoffmann <span dir="ltr"><<a href="mailto:kraxel@redhat.com" target="_blank">kraxel@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<div><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Also, the kqueue implementation in OS X 10.6 seem to have been broken,<br>
so I went with your suggestion and reimplemented the event handler using<br>
select(). One thing I noticed though was that the epoll implementation<br>
watched the fds for both read and write (add_to_poll()), but since it is<br>
edge triggered, it only fires once per change, but my select()<br>
implementation is level triggered, which meant it would never block and<br>
use up 100% CPU (for example monitoring a File fd, it always triggers).<br>
After playing a bit around with it, i decided to drop watching write for<br>
fds all together, and the client seem to work fine. Is there a need to<br>
check it or am I safe with monitoring only reads?<br>
</blockquote>
<br></div>
It isn't save. When you got -EAGAIN from a write() or send() syscall because the output pipe is full you have to watch for the socket becoming writable so you can flush out the bits you havn't sent yet.<br>
<br>
As far I know there is no bulk data going from client to server, so if you are working on a fast LAN it is quite possible that you never hit the "output pipe full" case and the client works fine for you.<div>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Now on to the audio, I have been implementing audio using CoreAudio<br>
Framework for OS X (another idea could be OpenAL which is also<br>
cross-platform?), which pulls in a lot of extra headers, including<br>
MacTypes.h which unfortunately defines a "Rect" and "Point" struct which<br>
causes issues with the definitions inside common/draw.h. I can hack<br>
around it, but its not very nice, or I could rename the ones in spice,<br>
but that would break any compatibility with my patches to the current<br>
upstream code.<br>
</blockquote>
<br></div>
What code base you are working on? In the unstable tree the structs have been renamed to SpiceRect and SpicePoint exactly to avoid name clashes like this. Also the headers have been splitted away into a spice-protocol package.<br>
<br>
A few days ago Alex landed the marshaller bits in the unstable tree and the spice client can handle both 0.4 and unstable spice protocols now. So you can jump to the unstable code base even if you need the client play nicely with 0.4 spice servers. This will also make it easier to merge your patches upstream.<br>
<br>
HTH,<br><font color="#888888">
Gerd<br>
<br>
</font></blockquote></div></div></div>Hi Gerd,<br><br>Thanks for the fast reply! Sounds good! Yes, right now I've been working on version 0.4, but since the unstable tree is now backwards compatible, I will move on to that.<br>
<br>
Rgrds,<br><font color="#888888"><br>Attila.<br>
</font></blockquote></div><br>Hi guys,<br><br>I thought I'll post an update on the Mac client. I have it up and running using the latest sources from the git dev. Event handler is doing select(), playback and recording is done with PortAudio, R and B re-swapped for peer_major == 1, and CEGUI is disabled since it caused a LOT of issues...<br>
<br>So now I'm only facing a few minor issues/things I've noticed:<br><br>1. Video playback seem to stop after a few seconds, but if the window is moved around or scrolled the video playback resumes again for a few seconds. I've tried it with VLC, windows media player and flash video players (youtube). Also, sometimes only the center square gets updated but not the rest. It is not very consistent as sometimes the video plays back fine..<br>
<br>2. Bandwidth usage seemed to have increased, with the v0.4 client ive been seeing 1-2MB/s for full screen HD video playback, while with the current one I've been seeing peeks of 8-9MB/s on a 100mbit network<br><br>
3. We didn't receive (as far as I'm aware) the linux firefox plugin for the client with our RH beta package, and Im not sure where to find it? I've ended up creating a launcher script, associated that with spice:// protocol in firefox and modified the javascript on the management machine to redirect to a spice:// address in case the plugin wasn't found. Not sure if this is the best way of doing it?<br>
<br><br>Best Regards,<br><br>Attila<br>