Re: sound through enbd

Dag Sverre Seljebotn <[email protected]> wrote:
> > 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

Me too! I've learned a bit, however.

> (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).

Oh, OK, of course, yes. I could do that.

> 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.

Thanks!

> 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).

Does one have to do that? The linux sound devices are exclusive-open,
but I dn't think they depend on user capabilities in any specific way
(you have to be able to open the special device file, and maybe
sometimes you have to be root - but I can always fulfil those
requirements :).

Enbd is just acting as a proxy - once you have opened the proxy device,
anything you do to it should be transported over the net by enbd, and
it is. I've checked at ioctl level. Yes, there may be a problem with
multiple daemons, but enbd does not keep its resource (the sound
device) open all the time in order not to prejudice operation
on removable devices. Indeed, I think one of its flags (:) ensures an
open and close before and after every i/o transfer. And I think I
recall that it uses locking on the resource (actually a virtual region
just outside the file) in order to avoid all conflicts with itself.

So I don't think that sort of thing will be a big problem.

In my experiments I was also able easily to intercept the GET_SND_FMTS
ioctl within the enbd transfers and make sure that the list returned to
the enquiry from the other side only listed formats I want the remote
end to use.


> enbd would have some problems in a thin-client environment because you
> would need to allocate a new sound device per thin-client,

Oh, I see, this is exclusive-open. I disregarded this problem - I
supposed I could always speak to one of those mixer daemons like esd
somewhere along the way or solve it somehow.  But yes, I noticed that
r/w to several devices was held off while I had enbd running, serving
from /dev/dsp.


> 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 discovered that many of my problems came from trying to pass static
in the first place! I was intending to use "sun au" format to the
/dev/audio device file, but eventually I realised that sox has a
really hard time creating this format, and I'm still not sure what it
"is".  I finally managed to make recognizable noises out of a 44.1K .wav
file dumped by mplayer with

    sox .. -t ul -s -c 2 -r 4000 resample highpass 400

but it still sounds awful. I don't have an oscilloscope to see what's
been done to the wave - or the spectrum. Something logarithmic. 

But it travels across fine via enbd in that format.

I have learned that /dev/dsp is a "generic" interface. One configures
it as the type of device one wants it to be via a SET_FMT call. I can
control what gets through, either way, to such ioctls, and I should
be able to avoid formats being picked which involve dma, though I
haven't investigated in detail.


> 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).

OK, thanks very much!

Peter