Guide to Linux Sound APIs

Guide to Linux Sound APIs

[Lennart Poettering]

Heya!

At the audio microconf at the Linux plumbers conference one thing
became very clear: it is very difficult for programmers to figure out
which audio API to use for which purpose and which API not to use when
doing audio programming on Linux. Someone needed to sit down and write
up a small guide. And that's what I just finished doing.

I'd thus like to draw your attention to this new (long) blog story of
mine containing this guide:

http://0pointer.de/blog/projects/guide-to-sound-apis

I'd be very thankful for comments, especially from you Takashi and
Jaroslav since it contains quite some details about the "safe" subset
of the ALSA API!

I'm thankful for all kinds of input!

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Guide to Linux Sound APIs

[Ben Finney]

Lennart Poettering <mznyfn@0pointer.de> writes:

> http://0pointer.de/blog/projects/guide-to-sound-apis
> 
> I'd be very thankful for comments, especially from you Takashi and
> Jaroslav since it contains quite some details about the "safe" subset
> of the ALSA API!
> 
> I'm thankful for all kinds of input!

I'm very thankful that you've made this positive contribution. It is
sorely needed, and I hope it will spur greater collaboration.

-- 
 \            “Technology is neither good nor bad; nor is it neutral.” |
  `\                       —Melvin Kranzberg's First Law of Technology |
_o__)                                                                  |
Ben Finney

_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss

Re: Guide to Linux Sound APIs

[Aaron J. Grier]

On Thu, Sep 25, 2008 at 09:05:14AM +1000, Ben Finney wrote:
> Lennart Poettering <mznyfn@0pointer.de> writes:
> 
> > http://0pointer.de/blog/projects/guide-to-sound-apis
> > 
> > I'd be very thankful for comments, especially from you Takashi and
> > Jaroslav since it contains quite some details about the "safe" subset
> > of the ALSA API!
> > 
> > I'm thankful for all kinds of input!
> 
> I'm very thankful that you've made this positive contribution. It is
> sorely needed, and I hope it will spur greater collaboration.

how finalized is the "safe ALSA subset" to mention it in the ALSA docs?
I am an embedded developer new to ALSA and am still a bit bewildered on
best-practices.

-- 
  Aaron J. Grier | "Not your ordinary poofy goof." | agrier@poofygoof.com

Re: Guide to Linux Sound APIs

[Lennart Poettering]

On Wed, 24.09.08 17:17, Aaron J. Grier (agrier@poofygoof.com) wrote:

> 
> On Thu, Sep 25, 2008 at 09:05:14AM +1000, Ben Finney wrote:
> > Lennart Poettering <mznyfn@0pointer.de> writes:
> > 
> > > http://0pointer.de/blog/projects/guide-to-sound-apis
> > > 
> > > I'd be very thankful for comments, especially from you Takashi and
> > > Jaroslav since it contains quite some details about the "safe" subset
> > > of the ALSA API!
> > > 
> > > I'm thankful for all kinds of input!
> > 
> > I'm very thankful that you've made this positive contribution. It is
> > sorely needed, and I hope it will spur greater collaboration.
> 
> how finalized is the "safe ALSA subset" to mention it in the ALSA docs?
> I am an embedded developer new to ALSA and am still a bit bewildered on
> best-practices.

Dunno. This guide is just something I wrote up as someone who knows
the ALSA API quite well I think. However, I am mostly just a developer
*using* the API, not a developer *writing* the API.

If you want some reliable, "official" opinions, then wait until Takashi
and Jaroslav commented on this. They are certainly the ones whose
endorsing or not-endorsing of this guide matters the most.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Guide to Linux Sound APIs

[Takashi Iwai]

At Thu, 25 Sep 2008 00:48:33 +0200,
Lennart Poettering wrote:
> 
> Heya!
> 
> At the audio microconf at the Linux plumbers conference one thing
> became very clear: it is very difficult for programmers to figure out
> which audio API to use for which purpose and which API not to use when
> doing audio programming on Linux. Someone needed to sit down and write
> up a small guide. And that's what I just finished doing.
> 
> I'd thus like to draw your attention to this new (long) blog story of
> mine containing this guide:
> 
> http://0pointer.de/blog/projects/guide-to-sound-apis
> 
> I'd be very thankful for comments, especially from you Takashi and
> Jaroslav since it contains quite some details about the "safe" subset
> of the ALSA API!

Thanks for pushing this up.  I enjoyed this reading a lot, especially
about many DONTS that reminds me of your past screams.

The items listed there regarding ALSA API are correct as far as I
read.  I think this should be in the official document.  Well, maybe
better to reorganize the whole section of ALSA API reference first...

Anyway, I'd like to mark async stuff as obsolete in a future version.
This is a broken design, and should rest in piece.
Meanwhile, I'm not in favor of adding deprecated link warning.  A
compile warning is fine, but link warning is way too annoying.  And
there are programs right now using async, we are responsible to keep
them running as they are.


Takashi

Re: Guide to Linux Sound APIs

[Lennart Poettering]

On Thu, 25.09.08 12:15, Takashi Iwai (tiwai@suse.de) wrote:

> > I'd be very thankful for comments, especially from you Takashi and
> > Jaroslav since it contains quite some details about the "safe" subset
> > of the ALSA API!
> 
> Thanks for pushing this up.  I enjoyed this reading a lot, especially
> about many DONTS that reminds me of your past screams.

Thanks!

> Anyway, I'd like to mark async stuff as obsolete in a future version.
> This is a broken design, and should rest in piece.
> Meanwhile, I'm not in favor of adding deprecated link warning.  A
> compile warning is fine, but link warning is way too annoying.  And
> there are programs right now using async, we are responsible to keep
> them running as they are.

You are aware that the linking warnings are only shown during build-time --
not during runtime when dynamic linking happens. So basically the
difference between compiler and linker warnings are not that big. Link
time warnings just appear a little bit later during build time than
compile time warnings.

The big advantage of linker warnings is that you can add arbitrary
warning strings when a symbol is used. Doing that with just the compiler is
impossible to my knowledge.

I.e. just define this:

#ifdef __GNUC__
#define WARN_REFERENCE(sym, msg)                     \
    __asm__(".section .gnu.warning." #sym);          \
    __asm__(".asciz \"" msg "\"");                   \
    __asm__(".previous")
#else
#define WARN_REFERENCE(sym, msg)
#endif

And then put a line like this next to the implementations of the symbols
you want to warn the developer about:

WARN_REFERENCE(snd_async_add_pcm_handler, "Please do not use async handlers anymore. For more details, read http://mailman.alsa-project.org/pipermail/alsa-devel/2008-May/008030.html");

or

WARN_REFERENCE(snd_pcm_sw_params_set_xfer_align, "You are using snd_pcm_sw_params_set_xfer_align() which is obsolete and a NOP. You may safely remove it from your sources.");

and so on.

And everytime someone builds a piece of software that uses a symbol
like this he gets are very clear explanation what is going and what he
should be fixing. The end user won't see anything about this.

Does that sound acceptable to you?

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Guide to Linux Sound APIs

[Takashi Iwai]

At Thu, 25 Sep 2008 21:40:28 +0200,
Lennart Poettering wrote:
> 
> On Thu, 25.09.08 12:15, Takashi Iwai (tiwai@suse.de) wrote:
> 
> > Anyway, I'd like to mark async stuff as obsolete in a future version.
> > This is a broken design, and should rest in piece.
> > Meanwhile, I'm not in favor of adding deprecated link warning.  A
> > compile warning is fine, but link warning is way too annoying.  And
> > there are programs right now using async, we are responsible to keep
> > them running as they are.
> 
> You are aware that the linking warnings are only shown during build-time --
> not during runtime when dynamic linking happens. So basically the
> difference between compiler and linker warnings are not that big. Link
> time warnings just appear a little bit later during build time than
> compile time warnings.

OK, then I must have misunderstood that.  I thought I did see link
warning message some time ago, so the idea was stuck to my head.

> The big advantage of linker warnings is that you can add arbitrary
> warning strings when a symbol is used. Doing that with just the compiler is
> impossible to my knowledge.
> 
> I.e. just define this:
> 
> #ifdef __GNUC__
> #define WARN_REFERENCE(sym, msg)                     \
>     __asm__(".section .gnu.warning." #sym);          \
>     __asm__(".asciz \"" msg "\"");                   \
>     __asm__(".previous")
> #else
> #define WARN_REFERENCE(sym, msg)
> #endif

We have already a similar macro link_warning() in alsa-lib/include/local.h.

However, I still prefer deprecated warning at compile time, not at
link time.  Regardless we like or not, we must keep supporting the old
API.  In that sense, warning at compile time looks saner to me.


Takashi