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