[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-multimedia
Subject:    Re: Xterminals: artsd talking to remote artsd?
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       2001-03-07 11:23:18
[Download RAW message or body]

   Hi!

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
-- 
  -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         
_______________________________________________
Kde-multimedia mailing list
Kde-multimedia@master.kde.org
http://master.kde.org/mailman/listinfo/kde-multimedia

[prev in list] [next in list] [prev in thread] [next in thread]