[alsa-devel] Guide to Linux Sound APIs
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 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.
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.
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
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
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
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
participants (4)
-
Aaron J. Grier -
Ben Finney -
Lennart Poettering -
Takashi Iwai