Re: Alsa-devel Digest, Vol 17, Issue 128

Re: Alsa-devel Digest, Vol 17, Issue 128

[Peter Dolding]

> Peter,
>
> Two assumptions you make are problematic:
>
> 1. You assume that one FOSS project can "kill" another. This is false.
> For a project to continue existing, the only thing it needs is people
> working on the code to maintain it so that it works in the
> ever-changing environment around it (the compiler, the kernel, core
> libraries, etc.)
>
To be correct a FOSS project can kill another buy taking its
developers.   Its way simpler than you could think.

If ALSA has all the features of PulseAudio including its interfacing
API's why will you add PulseAudio.  This is exactly how PulseAudio is
killing off ESD.   So in time not a single person is going to use ESD
other than threw PulseAudio.

Now PulseAudio killing Alsa is a lot harder and equally possible.   So
its a shark in the water.

> 2. You assume that by creating synergy and prominence of a single
> piece of software, that no one will try to write a competing piece of
> software. This is false. You absolutely cannot stop people from
> releasing alternative choices that have merits which draw users to
> them. There is no such thing as "de-fragmenting" the FOSS space. You
> can't make it simpler; you can only make it more complex. The number
> of FOSS projects of any given category grows infinitely with time,
> regardless of how good existing solutions are. This is true at every
> level of the software stack, but some categories have more
> alternatives than others.
>
> Sound traditionally happens to have a large amount of
> actively-maintained, moderately-popular alternatives to the point of
> being annoying, but there is no remedy that will make the others
> irrelevant. As long as there is some moderately-popular application
> being shipped with distributions that uses XYZ sound API / sound
> server, XYZ will have a user base. This leads to the unfortunate fact
> that, as far as I know, there does not currently exist _any_
> arrangement of nested sound servers and APIs that will:
>
> 1. Work for _every_ existing sound-using application (i.e. nobody
> crashes, few or no drop-outs, no assertions or incompatibilities or
> limitations, etc.)
> 2. Permit concurrent access to the soundcard by multiple applications
> at the same time
> 3. Allow all the features of every API to work at the same time
>
Missed the worst avoid lag  2 sound servers like dmix and pulse
operating on top of each other equals lag.  Goal has to be to get to 1
sound server only.

Remember ALSA name clearly.  Advanced Linux Sound Architecture

This is a Architecture single API s not a Architecture.  If all the
needed features to run ESD Pulse and so on there API can be directly
wrapped down to ALSA removing the need for sound servers other than
ALSA's.   Those API's just become part of the Architecture and can be
deprecated out of existence over time.  We also get broader ideas and
more developers focused in a single place.  Its a simple case why
install pulse if its features already work.

Note Pulseaudio is defragmenting.   The more API's it supports the
more it gets threw its central path.  Less important those engines
until they are no longer maintained and dead.   Why are you going to
put something else functional than Pulse on a system.

This method of defragmentation has happened many times over.  It works.

Its a myth that FOSS projects have to keep on growing in numbers in
any give category.  If that was so we would have a extra clone to ALSA
by now.   To be correct if we don't watch it we will.

Its only a matter of time before pulse guys just want to go straight
past the alsa-lib so they get faster interfacing with hardware.
Question is how long.

Note its imposable to get nested sound server to work perfectly.   But
its more than possible to get a single sound server to do all the jobs
of all the other sound servers so giving perfect API coverage.

The issue is we have to reduce to 1 sound server.   Many wrapping
api's.  Its less than 10 API's total.   Not many sound servers
providing single api's.

Only way is for 1 sound server to have all the features of all the
other sound servers.   Perfectively with direct calls to hardware.

Alsa fits the direct calls to hardware bit.   Features and wrappers a
little behind.  First project to 100 percent coverage wins.

Having a single sound server also reduces travel to hardware down.
You don't have to go sound server to sound server to get to hardware.

Only way forward is to end the peace.   Every project targeting to be
last 1 standing.  Even doing merges with each other to be last 1
standing.

Peter Dolding

Re: alsa-lib has anyone looked at taking it cross platform?

[John Rigg]

On Sat, Jul 26, 2008 at 10:48:14PM +1000, Peter Dolding wrote:
> Note its imposable to get nested sound server to work perfectly.   But
> its more than possible to get a single sound server to do all the jobs
> of all the other sound servers so giving perfect API coverage.

Where does JACK fit into this? It's aimed at a completely different
set of users from the other sound servers for Linux.

The requirements for pro audio, eg. music recording, sound for film
etc. are totally different from those of the average desktop user.
A single sound server that tries to do everything for everybody
sounds to me like a potential nightmare of conflicting requirements.

John

Re: alsa-lib has anyone looked at taking it cross platform?

[Peter Dolding]

On Sun, Jul 27, 2008 at 7:24 AM, John Rigg <aldev@sound-man.co.uk> wrote:
> On Sat, Jul 26, 2008 at 10:48:14PM +1000, Peter Dolding wrote:
>> Note its imposable to get nested sound server to work perfectly.   But
>> its more than possible to get a single sound server to do all the jobs
>> of all the other sound servers so giving perfect API coverage.
>
> Where does JACK fit into this? It's aimed at a completely different
> set of users from the other sound servers for Linux.
>
> The requirements for pro audio, eg. music recording, sound for film
> etc. are totally different from those of the average desktop user.
> A single sound server that tries to do everything for everybody
> sounds to me like a potential nightmare of conflicting requirements.
>
> John
>
I need to be more correct.   Only 1 sound server wanting all audio
threw it with only 1 config system.   No point having to fight with
Alsa and pulse, Network Audio System and esd to get sound up.   You
know you are going to have a fight sections are going to conflit with
each other so you cannot have all features of them at once because you
have a few too many sound servers trying to do exactly the same thing.
  Control all audio output.   There is only room for 1 sound server
doing that job.

Jack really does not go after that.   Jack is built as patch table.
Applications say I have these inputs and these output connect me to
something or nothing I don't care.   Commonly called a sound server
but its really not a sound server in the traditional idea.   Its also
like NMM that way gets labeled a Sound Server when people sort them
but really its nothing like it.

Stuff like pulse and esd did one sound server take the api of the
other one in a never ending process until there is only 1 left wanting
to control all audio is the only way forward.

I will layout how I see that pulse should be taken on by alsa and its
way different to current method.

The true driver system of pulse that is unique to it is its transfer
protocol over network.  That needs to be a plugin into alsa for output
as a client.   And a demon to feed into alsa for receiving network
traffic.

This way neither end need pulse to use its protocol.

Mixer of Alsa upgraded to support the new requirement of per
application volume control.

Pulse and ESD API's turned into nothing more than wrappers going
straight into alsa api.

This is basically the end of pulse.  Same for Network Audio System.
These basically need to be killed off duplication on a task that there
can only be 1 thing doing it at a time.   This also sees only 1 mixer
in use.   Alsa design does not make this even restrictive you could
have a PA, Dmix,ESD and NAS mixers as all Alsa mixer plugins.  So we
don't stop development and redesigns we move to a module method of it
as ALSA was designed.   Mistake has been using pulseaudio and other
things like its application input api's from ALSA instead of looking
at where it should be cut into segments so it cannot cause conflicts
with Alsa.

Jackaudio is lower down the list on need to worry about.   Reasons its
specialist they are not aiming to control every and take over ALSA job
of controlling everything.   But still as Advanced Linux Sound
Architecture.  We do need to look at what we can provide jack with and
if Jack should be included and directly promoted as part of the design
of the Linux Sound Architecture for applications to use.

Due to a Architecture having the right to have many api's over time
Jack's features could appear as a segment of ALSA.

Here the thing.  Jack's features of being able to control
interconnects between applications and do it low lag.  Is a feature
Alsa will most likely be need of for containers/cgroup features being
added to linux.   Same with pulseaudio the control of sound on a per
application base or per container base will become needed as part of
the Architecture over time.  Really per process sound control could be
done all the way down into kernel level.  Allowing hardware
acceleration if hardware supported.

Then there are the issues of openal where alsa is not that functional
for 3d sound that needs to be fixed.   Basically lots and lots of work
needs doing correctly.   Cross platform of Alsa-lib would to be to
prevent feature adds like 3d sound having to go threw non alsa api's.
Reason openal was formed for 3d sound is a lot of applications 3d use
opengl that is cross platform so also need cross platform audio.  So
now we don't have the programmers that know exactly what 3d developers
want all here because we have openal in existance.  Going cross
platform is supporting the developers using Alsa to have less work
porting there applications as well as discouraging development of
these extra layers.

Working 3d sound processing chips could also add some interesting
effects to per process sound like taging a process sound to a location
behind you when its hidden and moves forward past to in frount you
when its activated.

We need as many of those skilled developers in alsa or with the
expanding kernel features ALSA will more and more not fit correctly.

Its house cleaning time.  Pulseaudio has started the process.  About
time everyone here takes the hint alsa is lacking because its always
being looked at that alsa cannot rip the other projects into segments
and intergrate.

Peter Dolding