[sldev] gstreamer

Glen Canaday gcanaday at gmail.com
Fri Mar 13 16:43:14 PDT 2009


ALSA was originally written to replace the OSS system in the kernel for the 
2.2 kernel series because the OSS stuff had a lot of legacy cruft in it and it 
was becoming increasingly hard to maintain. OSS wasn't buggy, but its drivers 
were difficult to write from what I remember. It's been a long time... what was 
that, 1999? 2000?

Unless I remember wrong, ALSA was partly created also to permit a single 
unified interface to the kernel-level sound system no matter the hardware... I 
think in order to avoid having to write more ioctls. It's been a while; I 
don't remember everything and it's also likely that I remember a thing or two 
wrongly. OSS *is* older than ALSA by a long shot though. I used to use only 
OSS drivers because my SoundBlaster live 5.1 (emu10k1) was simply awesome 
though it circa 2001.

>> What to do for video, then?
>What has video to do with voice? The two are unrelated (voice doesn't
>use gstreamer for anything, it is completely a Vivox issue).

lol I know that... what I was meaning is if we could choose the backend for 
everything else including audio streaming, we're left with only video 
streaming to contend with and all of the I/O nightmares would essentially be 
stomped out. The switch to OpenAL in 1.22 fixed everything except streaming for 
me due to the 32- vs 64-bit gstreamer dependency.

>BTW, in your case, I would strongly suggest to use your own 64bit
>version of gstreamer. That may fix many of the crashes you are having.
>Mixing 32bit and 64bit libraries is rarely good idea.

Easier said than done. No client build = no link to 64-bit libs, and was the 
source of my rant in the first place! But I agree 100%.

>A new developer has NO value unless he has an overview of the process,
>the components involved and how everything hangs together.
>New developers need to learn a lot of things. The best way to
>learn is by doing. Changing a whole install/compile step to
>a one-click won't make them any wiser and they will be of no
>value imho.

It's of value to get people started. Starting with a success is encouraging; 
starting with failure is not. Start a new dev at a known working position with 
a successful build is far more productive than handing them a pile of crap and 
saying "fix it and make it work." People do learn by doing it's true, but after 
trying and failing so many times I'm surprised many more haven't given up 
entirely. It's impossible to learn how things work together when they don't 
work at all because you can't see them interact. After things work, they can 
dive in and find out why it works and break it themselves to learn even more. 
Baby steps.

Ambrosia earned mega mega points with me because of her (or his?) attempt to 
address this at that level even though it didn't work on my system! That got 
at least two people successfully building on Debian and that's awesome because 
now they can learn how things really work. If only one of them contributes 
only one patch to fix only one bug then it was worth the effort, imo.

I haven't given up. I'm waiting for someone on a similar system (ubuntu 8.10 
amd 64) to meet with success so I can ask them what they did that I didn't. 
I'm no n00b with Linux by a pretty big stretch; I learned why you don't move 
libc in a dynamic linked situation the hard way in 1997, for example, but the 
SL client build has me stumped but good. I bring it up on the list from time 
to time partly to remind people that there are still many who can't build, 
partly to remain in the loop though I'm one of those whom has contributed only 
one patch (which does not seem to have made it into 1.22 >:( ), and partly to 
test the waters to see if someone can give me a lightbulb moment.

--GC

On Friday 13 March 2009 12:47:57 pm Henri Beauchamp wrote:
> On Fri, 13 Mar 2009 12:38:15 +0100, Jan Ciger wrote:
> > Henri Beauchamp wrote:
> > > I personally got all audio device usage conflicts solved by getting rid
> > > of ALSA and *all* sound wrappers/daemons (pulseaudio, esd, jackit,
> > > arts, you name it) and installing OSS v4.1
> > > (http://www.opensound.com/oss.html).
> >
> > Henri, that is unfortunately not an option for the majority of Linux
> > users. They do not have neither the skills nor the means to install this
> > version of OSS.
>
> Did you try it at all ???  I doubt so...
>
> It's as simple as downloading a package from OSS website and
> installing it, just like you do with your distro packaging
> mechanism (RPM and DEB and TAR are provided)...
> And if your packaging mechanism is not supported, you got an
> auto-extractible package (just run it and it will do the rest).
>
> > Distros will not ship it, because it is not free (libre)
> > software.
>
> Sorry, but OSS v4 *is* Open Source...
> http://developer.opensound.com/sources/
>
> My bet is that given how more performant and easy is OSS (not to
> mention the OSS API has been around since day one of audio support
> in Linux and all software support it), it will replace the buggy,
> extremely flacky and unfriendly ALSA in the future.
> With OSS, you can get rid of *all* the stupid sound daemons and
> not have to worry if this or that software will support them.
>
> Henri.
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges



More information about the SLDev mailing list