I just read http://wiki.ltsp.org/twiki/bin/view/Ltsp/Ltsp5
So maybe I'll just sit and wait.

The reason for RFC was exactly this:
On Saturday 23 September 2006 05:59, 
[EMAIL PROTECTED] wrote:
> > The objection to LTSP clients is sound (from my users)
> > There are solutions, but they are pretty yuk eg has anybody got skype to
> > work on a thin client?
> >
> > So ...
> > based on a request for midi on thin clients ...
> >
> > A (small) client daemon that accepts a tcp connection from the server
> > A server program that creates /dev/dspNN /dev/mixerNN and connects to
> > clientM All traffic to server:/dev/dspNN server:mixerNN is sent to
> > clientM:/dev/dsp and clientM:/dev/mixer
> > vice verse eg all client audio traffic is sent to the respective server
> > port
> >
> > Comments ...
>
> Congratulations.  You just described exactly what esd and the esd shim
> basically does.

So skype, mythtv, sound in browsers just work? They don't. So this is the 
reason for my thoughts ...

> You already see how well that works :)
Quite <grin>

> > Now extend the daemon to include /dev/midiNN perhaps /dev/pcmNN heck
> > even /dev/ttycMNN to allow the oft requested tty forwarding
>
> Nope.  This has been what's done before, and it's been proven NOT to
> work.
>
> Writing to /dev/dsp is evil.
> Writing to /dev/mixer is evil.
> Writing to /dev/midi is evil.
Why evil? It does work on my limited testing. The app considers /dev/midiBLA 
to be real. The fact that it's remote is cute.

> ALL of them, BY DEFINITION imply that you're expecting the sound
> resources to be be on the same box as the program making the sounds.
> Then, after the fact, you're trying to somehow, magically hijack the
> stream, and make it appear somewhere else.  It's not workable.
Again please indulge my ignorance. I do not contest your view, just don't 
understand. :-)

> What SHOULD be happening is:
>
> 1) We should be using proper multimedia libraries.  Instead of doing an
> open() on /dev/dsp, and just blatting sounds out, what programs SHOULD
> do, is use a proper audio stack, like gstreamer or phonon.  You call
> functions to set volume, make beeps and boops, etc.  These can be
> properly re-routed in software, and moved around programatically.
>
> 2) Any Open Source programs still writing to /dev/dsp should have help
> from the community to convert them to gstreamer.  Find a program that
> isn't doing this yet, and submit patches.
>
> 3) Any closed source programs (*cough* Java *cough*) that are still
> writing to /dev/dsp should get a nice, friendly email, explaining to
> them that you deploy their products on a thin client environment, and
> explaining to them that by utilizing one of the multimedia stacks out
> there, their program will now magically work on BOTH thick AND thin
> clients, and how this would be a win for everyone.

And eg skype totally ignore you.

Thanks for the input.
James

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_____________________________________________________________________
Ltsp-discuss mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help,   try #ltsp channel on irc.freenode.net

Reply via email to