Re: [alsa-devel] Alsa-devel Digest, Vol 17, Issue 128
Peter,
Two assumptions you make are problematic:
- 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.
- 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:
- 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
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
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
participants (2)
-
John Rigg -
Peter Dolding