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