Re: sound through enbd

(snip)

Very nice!

> Curses! Anyone have any insight? Or even knowledge? About audio? Is
> there some transfer mode that doesn't use dma? Can I trick the calling
> application (mplayer, here) into using it?

I've been spending some days pulling my hairs about this general
problem, trying to send sound over to thin-clients. The sound servers
(esd, artsd) which (respectively) KDE and GNOME uses to mix sound face
the same problem... to fool applications that isn't specifically using
their APIs, they use a LD_PRELOAD trick with some wrappers, so instead
of "bplay test.wav" you do "artsdsp bplay test.wav" or "artsdsp -mmap
quake". Yes, it does mmap, but it is very specifically coded for quake.
Many applications doesn't work (kino for instance).

The best source of information is the source code of these wrappers. So
go grab the arts source (kde hosts it) and have a look at the source for
artsdsp...it has a heavy comment on the top.

I ended up buying something called MuNAS. It successfully simulates all
requests to /dev/dsp and forwards it to a user-specific daemon (so it
does different things depending on the user writing to it...something I
guess it would take a lot of work to have enbd do).

enbd would have some problems in a thin-client environment because you
would need to allocate a new sound device per thin-client, with all the
headaches that involve (running out of devices, need to reconfigure
applications when logging into a different client or juggle the devices
around all the time (see reuse thread...)). But open source solutions
are so sparse here that any new approach is very welcome.

I'll attach a post I just made to the FreeNX list on the issue in
general (NX is an X compression technology allowing you to remote X over
the internet...and sound to go with it would be nice! The commercial
server has it, but not the free alternative FreeNX).

// Dag Sverre

--- FROM FreeNX list:

I'm not going to answer the question, I'm merely taking the opportunity
to talk a little about the Networked Sound Problem, mainly from a
thin-client perspective when working with LTSP.

The problem is getting at the sound the applications produce. X, used
for getting at the graphics, is a well-defined protocol where network
was part of the considerations from the beginning - and therefore making
NX was just a matter of improving the network support already there. Not
so with sound.

Sound is a problem because all the applications use sound in different
ways - some access the kernel drivers directly, while others use
different sound servers to coordinate and mix sounds (of which there are
at least a dozen different). KDE apps use artsd, which was recently,
after a long period without changes, officially abandoned and stands
without a maintainer. Some time ago GNOME apps often used esd, though
just as often they accessed a /dev/dsp hardware device directly. Recent
GNOME apps seem to like to use gstreamer (not really a sound server but
you could code a NX sink to get at the sound from it...). Sound
applications seem to like jackd, a sound server specially developed for
low latency and professional features. The list goes on and on. For some
reason, people could just never get around to define a standard sound
API.

So, you can make it work per application by doing things in user-space,
but not for all, and you probably have to manually support each
application (artsd and esd have wrappers that intercept the system calls
done by applications accessing /dev/dsp directly, to trap the
sound ...however these only work on selected applications).

Since there is no standard, and won't be for a few years by the looks of
it, the only thing that would work well is a kernel driver. You then
need one solution per OS instead :-(

If and how NoMachine does it I don't know, it would be interesting to
know.

My personal proposal, for Linux: Write, or find if somebody has already
done so, a user-space ALSA driver. This would be an ALSA sound driver
that would forward sound to a process run by each logged-in user. Then
FreeNX could simply provide such a user-space program forwarding the
sound to the clients. (And the big bonus here is that the user-space
programs would be relatively simple, and you could simply switch it with
something else for NAS sound (for LTSP and other thin-client solutions
using normal X) or even wav writers or whatever.

The concept of a user-space sound driver could easily be transferred to
other systems than Linux as well, tough the kernel part would be
different.

The advantage in using ALSA is that the OSS emulation (/dev/dsp) is
already written, and one could probably also take advantage of software
mixing etc. from ALSA (in NX that is absolutely necesarry to get more
than one sound at the time).

At least one closed-source product (MuNAS) works like this, and it works
great (I'm using it myself, as there are no open source solutions in
this area, at least that I've found).

In the hope of a productive discussion,
// Dag Sverre