[lsb-discuss] lsb-discuss Digest, Vol 39, Issue 2

[Peter Dolding]

> From: Jeff Licquia <jeff at licquia.org>
> Subject: [lsb-discuss] LSB conf call notes for 2009-07-29
> To: lsb-discuss at lists.linux-foundation.org
> Message-ID: <4A799926.2040603 at licquia.org>
> Content-Type: text/plain; charset=UTF-8
>
>
> LSB 4.1.  Jeff: what's been done?  Mats: we've figured out the stuff for
> OpenJDK.  Other than that, nothing visible seems to have happened.  ALSA
> is about tests, which hasn't made any progress.  Jeff: elephant in the
> room; any ideas on moving ALSA forward?  Alan: from the silence, maybe
> just take it as it is.  Ted: or, at least, no magic resource is going to
> appear.  Are we willing to lower our standards for ALSA?  Russ: same
> issue as Java: not free.  Ted: the idea is to make an LSB-compliant
> OpenJDK.  When will we get the list of interfaces, and when will we be
> able to review?  ALSA comes up because we know that OpenJDK will need.
> Dennis: is ALSA going away?  Jeff: other APIs are around, but no leading
> contender.  Plus, ALSA is the only common denominator.  Ted: asked
> another way, will ALSA be going away?  Dennis: think the limited
> PulseAudio implementation will be all in enterprise distros in a few
> years.  Ted: if we were to standardize only the subset?  Dennis:
> Fedora's JDK works with PulseAudio.  Jeff: also, will they truly be
> going away or just de-emphasized?  Ted: if we believe that ALSA will
> continue to work whether through direct access or via a compatibility
> layer, isn't that OK?  Dennis: in theory, the Pulse compat layer could
> go away.  Ted: api compatibility.  Jeff: is sydney further along?
> Dennis: checking recent changes in Fedora, should be further along.
> Jeff: ALSA is still the lowest common denominator, should keep an eye
> out for a better common denominator.  Ted: is there a place where we
> should discuss this?  Dennis: maybe need to speak with the JACK and
> PulseAudio upstream.  The site says that the API is release-worthy.
> Should maintain ALSA support for quite a while, most likely.  Ted: can
> we shrink the list of interfaces to those that are supported by
> PulseAudio?  Jeff: we may be able to.
>
You missed the options completely.

1 battle with PulseAudio  Jack and Alsa
2 Go gstreamer.

Alsa is not really the lowest common denominator.

Gstreamer is a common denominator point.  KDE has a gstreamer output.
Gnome has a gstreamer output.

Gstreamer is a lib system so can be shipped with applications if
required.   Also due to being a lib system more than one could be
placed on a system without causing conflict.

Gstreamer has support for Jack Pulse alsa oss basically all the back
ends you could find on any distribution out there.

Try finding a desktop distribution these days that does not have
Gstreamer.   Answer is you will not find one.

Lets think of it this way the idea that alsa is the lowest common
denominator is wrong thing to be looking for.

Gstreamer matches the requirements.   Can it operate on all
distributions and installs out there that need audio answer is yes.
Can it be added as a LSB part in case of issue with distrobution
provided part ans again is yes.

Alsa can it operate on all distributions and installs sorry answer is
no.   Causes are poor emulation by Pulse audio and other redirection
systems.  Then anyone using OSS drivers for some reason ....

Pulse audio can it operate on all.  Again answer is no.  Its designed
to take control of the audio stack.  Same issue that all sound servers
suffer from applications don't work if sound server is not operating.

Gstreamer would allow ISV in case of problems with particular
distributions to release a unified patch version to get there
applications all working on that distribution.

 Pulse audio is badly broken.  Reducing interfaces to only what
Pulseaudio supports alsa applications using is crippling ISV
applications.   This should not be classed as a suitable out come.

Now Gstreamer path also means you don't have to limit features ISV's
can use to the same extream as Pulseaudio will require.  Gstreamer has
a way of asking what features are on offer.

Gstreamer also gives codec support so items like closed source codecs
could be produced.

Lets be truthful here its not just playing sound that is a bug bear to
end users.   Lack of means to get codecs is another major issue.  Alsa
and Pulse are not full audio systems providing all the needs of end
users.

Big important thing to remember.   We don't have to be compatible with
every existing Linux application.   We just have to provide a stable
interface across all Linux distributions that future developers can
build on.  Sooner the better.

Gstreamer to give application developers a framework in standard to
build audio applications of all forms would be a good enough outcome
let us sit back and wait for the lower levels to sort themselves out.

Really we don't have every single Linux kernel feature documented in
the standard.   So leaving another gap should not be classed as a
problem as long as it meets ISV needs.

I ask a serious question.  Can anyone list something gstreamer in the
form of audio cannot provide to a ISV that they would need so there
application works?

If there is nothing we should just take gstreamer as the common
denominator so ending the audio issue.

Peter Dolding