----- Mensaje original ----- > Thanks for the answer, Marc-Andr é ! > > I'll think about these areas of enhancements you've suggested. They need a > bit of clarification though - because it isn't clear for a newcomer what and > how to improve :) > > As for OS preferences, I'm a cross-platform guy, though giving a favor to > Linux naturally. This may be considered as a minus as I'm used to > cross-platform frameworks which do so much low-level work and hide > OS-specifics behind nice interfaces... I want to mention that I'm used to > C++, so getting in mostly C-written components would be harder for me. What > Spice parts are more C++-friendly actually? Iirc, the browser plugins (only XPI is public atm), and win-vdagent are C++. The rest is in C. The Spice client is sharing 99% of the code, while the platform-specific bits are handled at lower levels: gdk/cairo etc.. The code is quite portable, thanks to libraries like GLib/GIO/Gtk+. But there are still platform-specific components that are not portable (this situation could still be improved). > BTW, right now I've come across 2 tickets in the tracker: > https://bugs.freedesktop.org/show_bug.cgi?id=63807( No way to filter > devices) and https://bugs.freedesktop.org/show_bug.cgi?id=62033 ( Means to > detect local-only, and related > https://bugs.freedesktop.org/show_bug.cgi?id=62187 , > https://bugs.freedesktop.org/show_bug.cgi?id=62188 ). Are they relevant to > work on? I need an advice on how to actually fix them (I've added some > initial suggestions/questions in comments). There is a lot of improvements possible for local-only, and this is very relevant for desktop applications like Boxes. It is not so relevant for VDI in general, so it's not highest priority. It's indeed a good bug to work on. Regarding USB filtering, the bug was has a solution and was reopened. Imho, this is quite out of scope of Spice client libraries, so it should be handled at a different level, either libusb* or in the application. Probably in the application until a good API is found. > > For my future work I'm thinking about particular features useful for > enhancing VoIP clients performance/quality within VDI. One of them is listed > at the wiki, http://spice-space.org/page/Features/CodecPassthrough . While > it is useful(and probably should be done at first, or alongside), I think > there are even better possibilities - when the traffic doesn't go to VM at > all. How to implement this - it is another question:) One of the most > obvious ways is to implement something like 'remote media engine' capability > for spice client, and provide an API to apps running at guest via extending > vdagent. It should be easier for audio-only solution, for video-capable > another level of integration would be needed, when this media engine would > be rendering video in the app-provided window from the guest... Some sort of > such 'window overlay' APIs are part of Citrix HDX and VMWare Horizon View > suites actually. Do applications need to be aware of those API? Perhaps we could implement that? Tbh, I think a Linux solution using GStreamer elements should work. But adapting Windows directshow/media/whatever API to use that framework under the hood might be difficult. We lack of Windows experience to tell what is the best level or API to hook into. > > Suggested simple scheme above requires re-write of media subsystems of > VoIP/media consumer applications at the guests - not very feasible... Next > step would be introducing something to support the same for unchanged or > only very slightly changed applications. I have some ideas on this topic as > well, though looking hard/unrealistic/unclear (specific virtual network for > targeted applications, where network traffic is heuristically analyzed and > audio/video isn't transferred but used to control clients' media; signaling > traffic pass-through). > > All this seems to be very exciting topic to me, with many different > approaches and directions actually possible. I'd like to hear your opinions > about it, discuss it. _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel