View alsa-lib plugins setup for any app?

View alsa-lib plugins setup for any app?

[Eliot Blennerhassett]

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

Re: View alsa-lib plugins setup for any app?

[Takashi Iwai]

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

Re: View alsa-lib plugins setup for any app?

[Eliot Blennerhassett]

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

Re: View alsa-lib plugins setup for any app?

[Sean McNamara]

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
>

Re: View alsa-lib plugins setup for any app?

[Takashi Iwai]

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

Re: View alsa-lib plugins setup for any app?

[Takashi Iwai]

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
> 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

Re: View alsa-lib plugins setup for any app?

[Takashi Iwai]

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;
 }

Re: View alsa-lib plugins setup for any app?

[Eliot Blennerhassett]

On Wednesday 22 October 2008 19:39:34 Takashi Iwai wrote:
> ... like the patch below.

Thanks Takashi, that does just what I want!

Re: [alsa-devel] View alsa-lib plugins setup for any app?

[fatmanvincent]

FreeCine APK tornou se uma das aplicações de streaming mais procuradas graças ao seu conjunto de funcionalidades que oferecem aos utilizadores uma forma simples e rápida de aceder aos seus filmes e séries favoritos. O grande destaque da aplicação está na forma como combina praticidade qualidade de imagem e uma navegação fluida criando uma experiência de entretenimento completa para qualquer dispositivo Android - https://freecine.com.br/