> Greg,
>
> The sound is "warbled" with a high end distortion which is very
> noticible in human speach and hence, alas, unsuitable for my needs.
> Since I can play human speach with very clear results using the ALSA
> drivers for the alsaplayer I conclude that it is not my computer system
> but the ALSA/OSS emulation which is the problem (at least on my system).
>
> After making two simple up-stream changes together with a couple of
> umakefile changes, I have won through to a static linking of libasound.a
> into clntcore.so.  I now need to add tracing code to find out why the
> ALSA driver immediately destroys itself :-(
>
> I will make ALSA 1.0.5 work on a Linux 2.6.6 kernel.
>
> Can you elaborate on what does not work when you were testing the ALSA
> driver?
>
> Has the ALSA driver ever run correctly?

It has always crashed for me while it worked for the person who
submitted it. That is about where we are at with it. All the code
is in place, but crashes on some systems.

To start with, make the following change:

Index: helix-client-core-audio-advanced.pfi
===================================================================
RCS file: /cvsroot/ribosome/build/umakepf/helix-client-core-audio-advanced.pfi,v
retrieving revision 1.9
diff -u -w -r1.9 helix-client-core-audio-advanced.pfi
--- helix-client-core-audio-advanced.pfi 25 Mar 2004 22:09:22 -0000 1.9
+++ helix-client-core-audio-advanced.pfi 6 Jul 2004 18:07:07 -0000
@@ -50,9 +50,9 @@
 #Other sound systems (besides OSS) that you can compile
 #into the Helix core. OSS is compiled in by default right
 #now.
-#project.AddDefines('HELIX_FEATURE_OSS')
+project.AddDefines('HELIX_FEATURE_OSS')
 #project.AddDefines('HELIX_FEATURE_ESOUND')
-#project.AddDefines('HELIX_FEATURE_ALSA')
+project.AddDefines('HELIX_FEATURE_ALSA')
 #project.AddDefines('HELIX_FEATURE_USOUND')

 #DirectSound support for win32 platforms


That will turn on the ALSA support. Next, to use alsa (since there is
no GUI preference box for it yet) you need to manually change the
pref, SoundDriver, to use it. Your prefs file will change depending on
what player you are using but should be one of:

    splay: ~/.helix/Helix*SDK*
    helixplayer: ~/.helixplayerrc
    realplayer: ~/.realplayerrc

Just add 'SoundDriver=x' to your prefs file where 'x' is
between 0 and 4 according to:

#if defined( _LINUX ) || defined ( _FREEBSD )
#  define kOSS               0
#  define kSupportForOldOSS  1
#  define kESound            2
#  define kALSA              3
#  define kUSound            4
#endif

SoundDriver=0 is the default if it is not found in the prefs
file.

Sounds like you already statically linked in libasound. After
that you should be able to run the ALSA code foudn in:

    audio/device/platform/unix/audlinux_alsa.cpp

One thing we need to figure out, after the crash is gone and
we verify A/V sync, is if we want to statically link against
libasound or do what we do for ESound and look for the DLL at
runtime and to dlopen/dlsym for all the calls.

Let me know how it goes,
--greg.

>
> Cheers!
>
> Stephen Gaito
>
>
> Greg Wright wrote:
>
> >>Greg,
> >>
> >>Thanks for this reply.  Alas the Helix/RealPlayer using the ALSA
> >>emulation of OSS on the computer that I am using is too poor to use...
> >>
> >>
> >
> >Really? How is it poor? Is performance low, or do you just want native
> >ALSA support (which isn't bad).
> >
> >
> >
> >>Since I want to write some sound apps of my own I may as well start with
> >>RealPlayer since we love listening to the BBC Audio on Demand.
> >>
> >>However I assume that your desired target ALSA is version 1.0.x on Linux
> >>2.6.x is this correct?
> >>
> >>
> >
> >Well, since we don't have ALSA support working yet (most of the code is
> >in place) we will target whatever version of ALSA is the current stable
> >version. It should work on any OS/Kernal version that ALSA supports, for
> >the most part anyway.
> >
> >--greg.
> >
> >
> >
> >
> >>Cheers!
> >>
> >>Stephen Gaito
> >>
> >>Greg Wright wrote:
> >>
> >>
> >>
> >>>I have had a couple people say they were going to work on it, but
> >>>none ever did. If no one from outside of Real signs up for the work
> >>>we will probably get started on it, but it will be a while.
> >>>
> >>>Right now, the player should run fine on top of ALSA with OSS
> >>>emulation. That is how I run it.
> >>>
> >>>The alsa drivers just need about a couple days work (for someone
> >>>who devs fast and knows alsa).
> >>>
> >>>I know that ALSA support is high on the player teams list.
> >>>--greg.
> >>>
> >>>
> >>>----- Original Message ----- 
> >>>From: "Stephen Gaito (stgaito)" <stephen at greyson-gaito.demon.co.uk>
> >>>To: <gwright at real.com>
> >>>Sent: Friday, July 02, 2004 8:46 AM
> >>>Subject: RE: ALSA work (Helix-client AUDIO proj)
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>Greg,
> >>>>
> >>>>I notice that this position is still open.  I *am* not the developer you are looking for... just a "source-code-hack".
However
> >>>>
> >>>>
> >I
> >
> >
> >>>>
> >>>>
> >>>would like to know what the current state is and if possible be an early tester.
> >>>
> >>>
> >>>
> >>>
> >>>>I want Helix/RealPlayer to work with ALSA 1.0.5 on Linux 2.6.6
> >>>>
> >>>>What do you preceive to be the current problems with the device?
> >>>>
> >>>>-----------
> >>>>
> >>>>Note that I have managed to compile the contents of realplayer10-beta-source.tar by running the straight make command. However
> >>>>
> >>>>
> >to
> >
> >
> >>>>
> >>>>
> >>>get alsa compiled in I have had to do slightly more hacking than just adding project.AddDefines('HELIX_FEATURE_ALSA') to my
> >>>
> >>>
> >buildrc
> >
> >
> >>>file... I note that the GLADE based perferences GUI interface does not have ALSA or USOUND so there is no way to express a
> >>>preference for a non OSS SoundDriver... at least no way that was obvious to me ;-)  The current (out of the 'box') files also
> >>>
> >>>
> >don't
> >
> >
> >>>either statically or dynamically link in either libasound.a or libasound.so.
> >>>
> >>>
> >>>
> >>>
> >>>>I am now forcing a static linking of libasound.a and I am now stuck with a:
> >>>>
> >>>>/usr/bin/ld: dbg/clntcore.so: undefined versioned symbol name snd_pcm_hw_params_get_buffer_size_max at ALSA_0.9
> >>>>
> >>>>error.  It seems to me that you may be using the old depreciated ALSA APIs... a problem that I will continue investigating.
(I
> >>>>
> >>>>
> >>>>
> >>>>
> >>>will learn the ribosome build system).
> >>>
> >>>
> >>>
> >>>
> >>>>----------------
> >>>>
> >>>>SO:
> >>>>(1)  Do you have anyone else working on this?
> >>>>
> >>>>(2)  If you do I would very much like to be an early tester
> >>>>
> >>>>(3)  If you do not I would like to know what *you* think needs fixing...
> >>>>    AND which version of ALSA you plan to support...
> >>>>
> >>>>Cheers!
> >>>>
> >>>>Stephen Gaito
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >
> >
> >
>