[alsa-devel] View alsa-lib plugins setup for any app?
Greetings,
running aplay -v will show the plugin chain setup.
/proc/asound/card/pcm/* shows hw and sw params for the card driver when in use by any app
Is there any way to show the alsa-lib plugin settings a-la aplay for an arbitrary application?
thanks
-- Eliot
At Tue, 21 Oct 2008 14:29:20 +1300, Eliot Blennerhassett wrote:
Greetings,
running aplay -v will show the plugin chain setup.
/proc/asound/card/pcm/* shows hw and sw params for the card driver when in use by any app
Is there any way to show the alsa-lib plugin settings a-la aplay for an arbitrary application?
Sorry, I don't understand well your question. Do you want to see the alsa-plugin chain of a running application from the outside, or do you ask an API to show the alsa-plugin chains, or a way to show hw_params/sw_params for plugins?
Takashi
On Tuesday 21 October 2008 19:34:49 Takashi Iwai wrote:
Sorry, I don't understand well your question. Do you want to see the alsa-plugin chain of a running application from the outside,
Yes. Basically see something that looks like the result of "aplay -v", but for a running app from the outside.
E.g. to see if the app is using dmix, plughw etc, what parameters the app sees vs how the card is accessed.
Best if this info was available like the proc files for the driver, but if it required running the app in a special context (debugger-like or LD_PRELOAD) that would probably still be useful.
The app should not have to be recompiled.
or do you ask an API to show the alsa-plugin chains,
no. Now I see that you are thinking of snd_pcm_*_dump() family.
or a way to show hw_params/sw_params for plugins?
I this is included in my first "yes"
regards
Eliot
On Tue, Oct 21, 2008 at 4:55 PM, Eliot Blennerhassett linux@audioscience.com wrote:
On Tuesday 21 October 2008 19:34:49 Takashi Iwai wrote:
Sorry, I don't understand well your question. Do you want to see the alsa-plugin chain of a running application from the outside,
Yes. Basically see something that looks like the result of "aplay -v", but for a running app from the outside.
E.g. to see if the app is using dmix, plughw etc, what parameters the app sees vs how the card is accessed.
Best if this info was available like the proc files for the driver, but if it required running the app in a special context (debugger-like or LD_PRELOAD) that would probably still be useful.
If LD_PRELOAD is acceptable, then write a simple library that 1. Causes the linker to call _your_ snd_pcm_open() function when the app calls snd_pcm_open(). 2. Captures the second parameter to snd_pcm_open -- namely, the specified device string. 3. You can call snd_pcm_dump using the result of snd_pcm_open; or, you can just print out the device string and do your own diagnostics on it manually, like run an aplay -v --device=${devstring} /blah.wav and see what it produces. It's pretty much the same result though. 4. Call into the normal snd_pcm_open, passing its arguments on.
Quintessential examples of C function "overloading" (in the object-oriented sense) using the LD_PRELOAD hack can be found in things such as the aoss program (which just LD_PRELOADs libalsa-oss.so), padsp, and so on.
If a tracing tool (of which the simplest I can think of is gdb) is acceptable, then gdb ./some_compiled_binary
and in gdb: break snd_pcm_open [y] start continue x/s name
Note that you'll have to build ALSA with debugging symbols (or install an alsa-lib debugging symbols package from your distro, if available) to do this, but you won't have to have the debugging symbols of your main binary or any of its other (non-ALSA) libraries.
Other than (1) modifying the ALSA source to provide some out-of-process runtime access, (2) debugging, or (3) LD_PRELOAD, there's not really much you can do to take a precompiled arbitrary binary (with or without debugging symbols, with or without source code) and introspect which device string it's trying to open, and what the resulting plugins/devices end up being based on the device string that's been specified. Any useful information on this currently comes from within the ALSA client process, so you need to get into its execution flow somehow; gdb and LD_PRELOAD are the swiss army knives of doing just that.
HTH,
Sean
The app should not have to be recompiled.
or do you ask an API to show the alsa-plugin chains,
no. Now I see that you are thinking of snd_pcm_*_dump() family.
or a way to show hw_params/sw_params for plugins?
I this is included in my first "yes"
regards
Eliot _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
At Tue, 21 Oct 2008 23:51:30 -0400, Sean McNamara wrote:
On Tue, Oct 21, 2008 at 4:55 PM, Eliot Blennerhassett linux@audioscience.com wrote:
On Tuesday 21 October 2008 19:34:49 Takashi Iwai wrote:
Sorry, I don't understand well your question. Do you want to see the alsa-plugin chain of a running application from the outside,
Yes. Basically see something that looks like the result of "aplay -v", but for a running app from the outside.
E.g. to see if the app is using dmix, plughw etc, what parameters the app sees vs how the card is accessed.
Best if this info was available like the proc files for the driver, but if it required running the app in a special context (debugger-like or LD_PRELOAD) that would probably still be useful.
If LD_PRELOAD is acceptable, then write a simple library that
- Causes the linker to call _your_ snd_pcm_open() function when the
app calls snd_pcm_open(). 2. Captures the second parameter to snd_pcm_open -- namely, the specified device string. 3. You can call snd_pcm_dump using the result of snd_pcm_open; or, you can just print out the device string and do your own diagnostics on it manually, like run an aplay -v --device=${devstring} /blah.wav and see what it produces. It's pretty much the same result though. 4. Call into the normal snd_pcm_open, passing its arguments on.
This is an option, too. But, I guess it's overkill for the case like alsa-lib that you can change the code freely :)
Quintessential examples of C function "overloading" (in the object-oriented sense) using the LD_PRELOAD hack can be found in things such as the aoss program (which just LD_PRELOADs libalsa-oss.so), padsp, and so on.
If a tracing tool (of which the simplest I can think of is gdb) is acceptable, then gdb ./some_compiled_binary
and in gdb: break snd_pcm_open [y] start continue x/s name
Note that you'll have to build ALSA with debugging symbols (or install an alsa-lib debugging symbols package from your distro, if available) to do this, but you won't have to have the debugging symbols of your main binary or any of its other (non-ALSA) libraries.
Ah, this is a good point, and I forgot that at all.
You can try even the library without any changes. Set the breakpoint such as snd_pcm_hw_params, and check the parameters there. You can call even a function at the break point, such as snd_pcm_dump(). But, snd_pcm_dump() requires snd_output_t pointer, and you can't pass NULL there, so it's not easy as it should be. (Well, it sounds like a good idea to handle NULL as stdout in snd_pcm_dump(). I'm going to change the code.)
thanks,
Takashi
At Wed, 22 Oct 2008 09:55:01 +1300, Eliot Blennerhassett wrote:
On Tuesday 21 October 2008 19:34:49 Takashi Iwai wrote:
Sorry, I don't understand well your question. Do you want to see the alsa-plugin chain of a running application from the outside,
Yes. Basically see something that looks like the result of "aplay -v", but for a running app from the outside.
E.g. to see if the app is using dmix, plughw etc, what parameters the app sees vs how the card is accessed.
Best if this info was available like the proc files for the driver, but if it required running the app in a special context (debugger-like or LD_PRELOAD) that would probably still be useful.
The app should not have to be recompiled.
Well, right now it's almost impossible because the alsa-lib stuff is purely a user-space thing and not exposed to anywhere else.
An easy hack is to add snd_pcm_dump() to snd_pcm_hw_params() in alsa-lib (better with a conditional check, such as a certain environment variable). But this function may be called recursively, it should have a certain re-entrace check.
Takashi
At Wed, 22 Oct 2008 07:58:45 +0200, I wrote:
At Wed, 22 Oct 2008 09:55:01 +1300, Eliot Blennerhassett wrote:
On Tuesday 21 October 2008 19:34:49 Takashi Iwai wrote:
Sorry, I don't understand well your question. Do you want to see the alsa-plugin chain of a running application from the outside,
Yes. Basically see something that looks like the result of "aplay -v", but for a running app from the outside.
E.g. to see if the app is using dmix, plughw etc, what parameters the app sees vs how the card is accessed.
Best if this info was available like the proc files for the driver, but if it required running the app in a special context (debugger-like or LD_PRELOAD) that would probably still be useful.
The app should not have to be recompiled.
Well, right now it's almost impossible because the alsa-lib stuff is purely a user-space thing and not exposed to anywhere else.
An easy hack is to add snd_pcm_dump() to snd_pcm_hw_params() in alsa-lib (better with a conditional check, such as a certain environment variable). But this function may be called recursively, it should have a certain re-entrace check.
... like the patch below.
Takashi
diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c index 59e433f..1c89d7e 100644 --- a/src/pcm/pcm.c +++ b/src/pcm/pcm.c @@ -814,11 +814,27 @@ int snd_pcm_hw_params_current(snd_pcm_t *pcm, snd_pcm_hw_params_t *params) int snd_pcm_hw_params(snd_pcm_t *pcm, snd_pcm_hw_params_t *params) { int err; + static int enter; + assert(pcm && params); + enter++; err = _snd_pcm_hw_params(pcm, params); if (err < 0) - return err; + goto out; err = snd_pcm_prepare(pcm); + out: + enter--; + if (!err && !enter) { + const char *v = getenv("ALSA_PCM_DUMP"); + if (v && *v) { + snd_output_t *log; + err = snd_output_stdio_attach(&log, stderr, 0); + if (!err) { + snd_pcm_dump(pcm, log); + snd_output_close(log); + } + } + } return err; }
participants (3)
-
Eliot Blennerhassett -
Sean McNamara -
Takashi Iwai