Re: [Linux-wildo-devel] Sound in/out on the client

[Gabriele D. C. <dar...@io...>]

First of all one consideration, it' sad that now that we have some
traffic on the ML 2 people just unsubscibed... I hope that when we go
out with new version some of them will come back.

Hi Robert, here I'm with the answer, it's divided in 3 parts:

1) current code:

Current code is a real fast thing that is there just to have audio
something working, currently at compile time you have to choose which
audio support have, but you can choose to have more than one, and the
code generated will try to use one the best one, so yes it's like you
have only one at compile time, /dev/dsp is hardcoded too. I think
that best would be to read the device setting from a
configuration file and in the future when we get one we will store the
default value there that the gui/client frontend will have the duty to
set it at startup.

2) old plugin code:

Time ago out plugin master gros allready rewrote that part of code to
not be anymore a crap static fast thing to be plug in style. So we got
a loader and al other nifty things. That code did not got integrated
yet due to the pending need to clean and reorganize the cvs and dues to
the fact we was going out with alpha.
Those question moved our attention to the fact that going out with an
alpha 0.2.0 without a so important change as the plugin was nonsense,
cause when plugin would be integrated that would have required another
minor release for sure (0.3.0) and this was a non sense.

3)

Here we arrive to recent (1 month or so). I decided to delay alpha
until I could integrate all gros code and redesign the client API to
have it readable. Currently there are many legacies on the order in
which you have to call client API function and the reason/behavor is
not always clear.
When I communicated gros about that I was goign to integrate his code,
I talked him about a nifty filter/codec plugin structure I have thought
about, he liked the idea and said me to freeze cvs until he can
integrate such a thing.
So when gros will be done we will probably have stack for message
reporting and plugin support for both audio and codec.

Now extra, as you higligthed we miss a function in the audio api for
settign the device, you are rigth and that is a serious miss.
What about a:
int LW_Sound::set_device(char *device)

lwplaytest is a nice small program used to test audio support.. just now
as you see it works only for the hardcoded oss, idea was to make it able
to load any plugin (gros allready did that, we both have the source I
think). Last time gros tested ALSA it showed some weakness that need
fix. Portaudio is another thing I will fix when i have time, and after
ALSA works.
ESD support would be nice as SDL, the main problem is to write decent
configure scripts so that compilation is smooth.
So if you feel like you are willing to test you could write ESD
support, when plugin goes in we will convert it to plugin, it's not
complex. The API is in lw_sound.h apart the function from above, that
after your mail, is scheduled for addition.

Ciao,
Gabriele

On Thu, 9 Feb 2006 20:33:21 -0500
"Robert A.M. Diamond" <ram...@gm...> wrote:

> Hey guys,
> 
> 	This is DeadRAM on IRC. Was looking over the lwplaytest in the current
> cvs (can't wait for the new stuff to be commited to cvs :P). Looks to me
> like the client will have to be built with say, OSS sound support (for
> playback and recording). If someone wanted to change over to portaudio,
> or alsa, they would have to rebuild the client. I'd prefer it if they
> set an option durring build time to include all the types of sound
> support they wanted, and then configured thier client to use OSS, or
> ALSA, or whatever. I havn't seen the client code yet, so I might be
> wrong about this. If it is the case though, I wouldn't mind writing some
> code to let people choose say, /dev/dsp as thier OSS in/out device, or
> 127.0.0.1:8000 as thier ESD in/out device. Couldn't find gros or dark on
> IRC, and I'll be away for most of tomorrow, so I figured I'd make this
> post. I think my days are your nights anyways 0.o
> 
> My gpg key is attached.
> 
> -- 
> Robert A.M. Diamond
>   <ram...@gm...>
> 
> Sentimentality -- that's what we call the sentiment we don't share.
> 		-- Graham Greene


----------- 
http://linux-wildo.sf.net
http://www.diniciacci.org