At Tue, 21 Oct 2008 23:51:30 -0400,
Sean McNamara wrote:
>
> On Tue, Oct 21, 2008 at 4:55 PM, Eliot Blennerhassett
> <linux@xxxxxxxxxxxxxxxx> 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.
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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
