On Wednesday 07 March 2001 12:23, Stefan Westerfeld wrote:
>    Hi!

Thanks for the infos Stefan!  I'll see what I can do.

Achim
>
> On Wed, Mar 07, 2001 at 02:45:18AM +0100, Achim Bohnet wrote:
> > We have several linux X-terminals (just the stuff to run a
> > X-server). I've now additionally installed artsd on them.  So
> >
> > 	artsplay /path/on/host/running/the/xserver/soundfile
> >
> > works fine now but
> >
> > 	artsplay /path/on/remote/login/host/soundfile
> >
> > does not (as I expected).  Unfortunately it's what a
> > user sitting infront of the X-terminal would expect :(
> >
> > I've checked artsd -A  and got 'none' and 'oss'. So I
> > assume there is no mode where artsd (running on a multiuser server
> > without sound card) just forward to the artsd runnning on the X-server
> > host, right?
> >
> > So I would like to ask if another audiosubsys sub class the right thing
> > to do?  Is another interface more appropriate for artsd -> artsd
> > communication (better one to one correspondance of local and remote
> > (mcop?) calls)?   I guess I have to use a async stream, because a
> > permanent flow of 44.1k x 2 bytes x 2 channels would stress the
> > network interface of the server too much :)
>
> Oh yes, artsd cascading. I think it would be a good idea to have this.
> can make either an AudioIOArts class or an Synth_PLAY_ARTS and
> Synth_RECORD_ARTS. The first one has the advantage that it is much simpler
> to implement. The second one has the advantage that it will be usable in
> more complex setups, like the case where you have two hosts and want that
> each of them uses it's local soundcard for recording/playing, but also can
> get and receive sound from the other host.
>
> Well, as for async streams: yes, I think you should use them. You can
> mostly copypaste the client code from artscat, as this is pretty much what
> AudioIOArts or Synth_PLAY_ARTS would need to do. In the end, you might want
> to save the float->int conversion in the "sending" artsd and the int->float
> conversion in the "receiving" artsd, but thats just fine-tuning.
>
>
> An issue you will run into is the one of the initial object reference. The
> ordinary way to connect to an aRts soundserver is
>
>   SoundServer server = Reference("global:Arts_SoundServer");
>
> The required object references are stored under /tmp/mcop-<username>, or on
> the X11 server. While that scheme works find under the assumption that
> there is at most one sound server around, it will break now you have two.
>
> There might be the approach of telling artsd to register itself under
> Arts_SoundServer_0 or Arts_SoundServer_1 so that the two will not collide.
>
> Another way would be making it possible to connect to an artsd without an
> initial object reference (if you just know host and port), and let each
> server store their references in /tmp (so they will not collide). I think
> implementing that would make sense in any case, and probably I'll do that
> some day.
>
>
> If you don't want to deal with these issues for now, the simplest way will
> be adding
>
> 	printf("my reference is '%s'\n",server.toString());
>
> to artsd.cc. Then you can for now manually copy that string to the client,
> where you can use
>
>     SoundServer cascadeToServer = Reference(<the string printed above>);
>
> to find "the other artsd" to send the data to.
>
>    Cu... Stefan

-- 
  To me vi is Zen.  To use vi is to practice zen. Every command is
  a koan. Profound to the user, unintelligible to the uninitiated.
  You discover truth everytime you use it.
                                      -- reddy@lion.austin.ibm.com
_______________________________________________
Kde-multimedia mailing list
Kde-multimedia@master.kde.org
http://master.kde.org/mailman/listinfo/kde-multimedia