----- "Attila Sukosd" <attila.suk...@gmail.com> wrote: > From: "Attila Sukosd" <attila.suk...@gmail.com> > To: spice-de...@freedesktop.org > Sent: Tuesday, July 6, 2010 4:53:45 AM GMT -05:00 US/Canada Eastern > Subject: Re: [Spice-devel] spice BSD/OSX client > > > On Fri, Jun 25, 2010 at 12:32 PM, Attila Sukosd < attila.suk...@gmail.com > > wrote: >
> On Fri, Jun 25, 2010 at 11:41 AM, Gerd Hoffmann < kra...@redhat.com > wrote: > Hi, > > Also, the kqueue implementation in OS X 10.6 seem to have been broken, > so I went with your suggestion and reimplemented the event handler using > select(). One thing I noticed though was that the epoll implementation > watched the fds for both read and write (add_to_poll()), but since it is > edge triggered, it only fires once per change, but my select() > implementation is level triggered, which meant it would never block and > use up 100% CPU (for example monitoring a File fd, it always triggers). > After playing a bit around with it, i decided to drop watching write for > fds all together, and the client seem to work fine. Is there a need to > check it or am I safe with monitoring only reads? > > 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. > > 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. > > Now on to the audio, I have been implementing audio using CoreAudio > Framework for OS X (another idea could be OpenAL which is also > cross-platform?), which pulls in a lot of extra headers, including > MacTypes.h which unfortunately defines a "Rect" and "Point" struct which > causes issues with the definitions inside common/draw.h. I can hack > around it, but its not very nice, or I could rename the ones in spice, > but that would break any compatibility with my patches to the current > upstream code. > > 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. > > 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. > > HTH, > Gerd > > Hi Gerd, > > 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. > > Rgrds, > > Attila. > > Hi guys, > > 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... > > So now I'm only facing a few minor issues/things I've noticed: > > 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.. > > 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 > > 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? Attila, The Red Hat package shipped to customers is here https://rhn.redhat.com/rhn/software/packages/details/Overview.do?pid=533006 If you don't have access please ping me off list. thanks for your work on this. Aic > > > Best Regards, > > Attila > > _______________________________________________ Spice-devel mailing list > Spice-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/spice-devel
_______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
