Ubuntu Wiki

• Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/thinclient-sound

• Created: Date(2005-10-31T22:27:58Z) by OliverGrawert

• Contributors: OliverGrawert

• Packages affected:

  • esd/libesd
  • ltsp-server/ltsp-server-standalone

Summary

Thin Client Audio Support how to get audio to the thin clients

Rationale

Since LTSP sessions currently run fully on the server and there is no tweakage done, the first LTSP Client grabs the available audio device to play sounds. For dapper the sound output needs to get redirected to the Thin Client over the network to use the actual sound device the user listens to

Use cases

Ian clicks on a menu item in Gnome and the "plop" sound used for the menu item gets played on the thin client's sound system as expected.

Daniel is playing a tutorial video from a training website on his thin client at work. His phone rings, and he mutes his volume control so he can hear. It works as expected.

Wilma has edited some wav files in the music class at her schoool where a edubuntu LTSP server is used. She can easily play back the edited sound files because there is sound support for the Thin Clients in Edubuntu LTSP.

XXX: Use cases should describe what should happen, not what is currently broken; if you need more detail, use a "current status" section --smurf YYY: Fixed. --ScottBalneaves ScottJamesRemnant: please remove reviewer comments from specs before sending for approval

Scope

Options:

• ALSA itself does not support network operation, so an intermediary must be used.
• esound has problems, but is a workable solution, and is used currently.

ScottJamesRemnant: this seems to conflict with GstreamerAudioBackend which states that we're dropping esound

• polypaudio is dead upstream.
• jack needs kernel patches, has a bad security history and is not supportable in main.
• gstreamer: too limited in scope.

ScottJamesRemnant: and also the approved solution

• nas: poor performance leads to "stuttering" audio playback.
• mas: dead upstream
• vsound: only supports OSS, and not ALSA.

ScottJamesRemnant: which means it would work through the ALSA OSS emulation, no?

Design

Idea (network sound for the poor): Have ALSA output to a file/pipeline, and forward this (netcat/ssh) to the client. We should evaluate whether this works in principle (if this works we should make it the default for dapper+1 !).

For dapper, ltsp should still default to esound but forward the sound through a ssh tunnel to no break the current secure model we use with the ew ltsp implementation. We can automatically detect this in the planned automatic backend for gstreamer.

Implementation

• We will start the esound daemon from the ltsp-client bootscript.

ScottJamesRemnant: this will cause it to run as root? and will break when gnome-session also tries to start it, no?

• Create the configuration files necessary to have esound listen to TCP connections.

ScottJamesRemnant: isn't this commented out in the source for major secturity reasons?

• On the server side, gnome-session needs to use gstreamer-esd as sound output. This will require a change to the Gnome default session setup we plan to use in dapper, which is currently going to use alsa and dmix.

ScottJamesRemnant: that is an approved spec, please indicate the scope of this "replace".

• The correct environment variable will have to be set to allow libesd on the server to be aware to which IP it shall send the sound. This will be done by reading the LTSP_CLIENT environment variable to determine the clients IP, and then creating whatever other environment variables are needed.

Code

• Patches to libesd to make it know where to sent the sound stream to. The variables below need to go into the ldm binary or intoa config file ldm reads (ldm hands over environment varianbles to the ltsp session)

MattZimmerman: what patches are necessary here? ESPEAKER is already implemented upstream

• export ESPEAKER=${LTSP_CLIENT}:16001
• export ESDDSP_MIXER=1
• export LD_PRELOAD="/usr/lib/libesd.so.0 /usr/lib/libesddsp.so.0"

MattZimmerman: Seems simpler to use the esddsp wrapper to wrap the X session

• The following needs to be run on session startup (through ldm's session startup script) on the server:
  • /usr/bin/esdctl unlock

MattZimmerman: simpler to use esd -public on the client

• A change to the default setup in the gnome session is required (dapper will go with alsa/dmix by default, we need gstreamer-esd). This should be done by setting the default gstreamer output sink in ltsp-server's postinst/prerm scripts.

XXX:Is that enough detail to actually implement it? (Honest question, I don't have the technical experience in that area to judge that) --smurf YYY: Yes, since the implementation is very straight forward, very easy and already used in older ltsp implementations --ogra ZZZ: Cleaned up a bit --ScottBalneaves 000: JeffWaugh says this is entirely sane. This is the way to do thin client audio, it's not weird at all.

MattZimmerman: it would be preferable to do this only for thin client sessions, rather than globally. Isn't it possible to make this work more smoothly using the gstreamer autosink?

ScottJamesRemnant: what about gstreamer's network sink?

Data preservation and migration

Outstanding issues

BoF agenda and discussion