Alsa plugin unable to be loaded by Pulseaudio

Alsa plugin unable to be loaded by Pulseaudio

[Ng Oon-Ee]

Hello, please find below an issue I had with loading plugins into
pulseaudio. The pulse dev has sent this mail on his list concerning
alsa's interaction with pulse, indicating that there is something buggy
with how it works. Details below. I'd be willing to post something to
the bugtracker, if I only knew what the below means...

-------- Forwarded Message --------
From: Lennart Poettering <lennart@poettering.net>
Reply-to: General PulseAudio Discussion
<pulseaudio-discuss@mail.0pointer.de>
To: pulseaudio-discuss@mail.0pointer.de
Subject: Re: [pulseaudio-discuss] Alsa output devices, able to use alsa
plugin?
Date: Fri, 4 Sep 2009 01:20:15 +0200

On Wed, 26.08.09 12:27, Tanu Kaskinen (tanuk@iki.fi) wrote:

> D: alsa-util.c: Trying test with SND_PCM_NO_AUTO_FORMAT ...
> D: alsa-util.c: Managed to open test
> D: alsa-util.c: Maximum hw buffer size is 371 ms
> I: alsa-util.c: snd_pcm_hw_params_set_periods_near() failed: Tiedostoa tai hakemistoa ei ole
> I: alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed: Tiedostoa tai hakemistoa ei ole
> D: alsa-util.c: Trying test without SND_PCM_NO_AUTO_FORMAT ...
> D: alsa-util.c: Managed to open test
> D: alsa-util.c: Maximum hw buffer size is 371 ms
> I: alsa-util.c: snd_pcm_hw_params_set_periods_near() failed: Tiedostoa tai hakemistoa ei ole
> I: alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed: Tiedostoa tai hakemistoa ei ole
> D: alsa-util.c: Trying plug:test with SND_PCM_NO_AUTO_FORMAT ...
> D: alsa-util.c: Managed to open plug:test
> D: alsa-util.c: Maximum hw buffer size is 371 ms
> I: alsa-util.c: snd_pcm_hw_params_set_periods_near() failed: Tiedostoa tai hakemistoa ei ole
> I: alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed: Tiedostoa tai hakemistoa ei ole
> D: alsa-util.c: Trying plug:test without SND_PCM_NO_AUTO_FORMAT ...
> D: alsa-util.c: Managed to open plug:test
> D: alsa-util.c: Maximum hw buffer size is 371 ms
> I: alsa-util.c: snd_pcm_hw_params_set_periods_near() failed: Tiedostoa tai hakemistoa ei ole
> I: alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed: Tiedostoa tai hakemistoa ei ole
> I: alsa-util.c: Failed to set hardware parameters on plug:test: Tiedostoa tai hakemistoa ei ole
> E: module.c: Failed to load  module "module-alsa-sink" (argument: "device=test"): initialization failed.
> 
> That "Tiedostoa tai hakemistoa ei ole" error means "No such file or
> directory". I tried also with device=hw:0,0 and device=plughw:0,0 and
> the first worked while the latter gave the same errors. Since the failed
> function calls pertain to buffering, I also tried with tsched=0. It
> worked. So, maybe this is a bug in the "plug" alsa plugin, ie. it
> doesn't implement the *_near() functions properly.
> 
> Lennart, any insights?

I am pretty sure that ALSA is broken here. We nowadays first try to
set the number of periods, and then set the buffer size in the
hwparams struct. If this fails we print a warning message (the ones
you see above with all the vowels regarding
snd_pcm_hw_params_set_periods_near()
resp. snd_pcm_hw_params_set_buffer_size_near()), but we do not
consider this fatal.

After doing this we call snd_pcm_hw_params() to activate our
settings -- and if this fails then we consider this a fatal problem.

Now the brokeness in ALSA is that after refusing our parameters it
still fails to configure our settings, i.e. calling the two functions
that fail breaks the hwparams setup: if we wouldn't call them, no breakage
happens at all. 

The two functions in question should either succeed or fail, but if
they fail they should not modify hwparams in a way that it
subsequently becomes unusable for snd_pcm_hw_params().

This issue needs to be fixed in ALSA. 

Lennart

Re: Alsa plugin unable to be loaded by Pulseaudio

[Raymond Yau]

use those functions snd_pcm_hw_params_test_xxxxxx()


2009/9/8 Ng Oon-Ee <ngoonee@gmail.com>

> Hello, please find below an issue I had with loading plugins into
> pulseaudio. The pulse dev has sent this mail on his list concerning
> alsa's interaction with pulse, indicating that there is something buggy
> with how it works. Details below. I'd be willing to post something to
> the bugtracker, if I only knew what the below means...
>
> -------- Forwarded Message --------
> From: Lennart Poettering <lennart@poettering.net>
> Reply-to: General PulseAudio Discussion
> <pulseaudio-discuss@mail.0pointer.de>
> To: pulseaudio-discuss@mail.0pointer.de
> Subject: Re: [pulseaudio-discuss] Alsa output devices, able to use alsa
> plugin?
> Date: Fri, 4 Sep 2009 01:20:15 +0200
>
> On Wed, 26.08.09 12:27, Tanu Kaskinen (tanuk@iki.fi) wrote:
>
> > D: alsa-util.c: Trying test with SND_PCM_NO_AUTO_FORMAT ...
> > D: alsa-util.c: Managed to open test
> > D: alsa-util.c: Maximum hw buffer size is 371 ms
> > I: alsa-util.c: snd_pcm_hw_params_set_periods_near() failed: Tiedostoa
> tai hakemistoa ei ole
> > I: alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed:
> Tiedostoa tai hakemistoa ei ole
> > D: alsa-util.c: Trying test without SND_PCM_NO_AUTO_FORMAT ...
> > D: alsa-util.c: Managed to open test
> > D: alsa-util.c: Maximum hw buffer size is 371 ms
> > I: alsa-util.c: snd_pcm_hw_params_set_periods_near() failed: Tiedostoa
> tai hakemistoa ei ole
> > I: alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed:
> Tiedostoa tai hakemistoa ei ole
> > D: alsa-util.c: Trying plug:test with SND_PCM_NO_AUTO_FORMAT ...
> > D: alsa-util.c: Managed to open plug:test
> > D: alsa-util.c: Maximum hw buffer size is 371 ms
> > I: alsa-util.c: snd_pcm_hw_params_set_periods_near() failed: Tiedostoa
> tai hakemistoa ei ole
> > I: alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed:
> Tiedostoa tai hakemistoa ei ole
> > D: alsa-util.c: Trying plug:test without SND_PCM_NO_AUTO_FORMAT ...
> > D: alsa-util.c: Managed to open plug:test
> > D: alsa-util.c: Maximum hw buffer size is 371 ms
> > I: alsa-util.c: snd_pcm_hw_params_set_periods_near() failed: Tiedostoa
> tai hakemistoa ei ole
> > I: alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed:
> Tiedostoa tai hakemistoa ei ole
> > I: alsa-util.c: Failed to set hardware parameters on plug:test: Tiedostoa
> tai hakemistoa ei ole
> > E: module.c: Failed to load  module "module-alsa-sink" (argument:
> "device=test"): initialization failed.
> >
> > That "Tiedostoa tai hakemistoa ei ole" error means "No such file or
> > directory". I tried also with device=hw:0,0 and device=plughw:0,0 and
> > the first worked while the latter gave the same errors. Since the failed
> > function calls pertain to buffering, I also tried with tsched=0. It
> > worked. So, maybe this is a bug in the "plug" alsa plugin, ie. it
> > doesn't implement the *_near() functions properly.
> >
> > Lennart, any insights?
>
> I am pretty sure that ALSA is broken here. We nowadays first try to
> set the number of periods, and then set the buffer size in the
> hwparams struct. If this fails we print a warning message (the ones
> you see above with all the vowels regarding
> snd_pcm_hw_params_set_periods_near()
> resp. snd_pcm_hw_params_set_buffer_size_near()), but we do not
> consider this fatal.
>
> After doing this we call snd_pcm_hw_params() to activate our
> settings -- and if this fails then we consider this a fatal problem.
>
> Now the brokeness in ALSA is that after refusing our parameters it
> still fails to configure our settings, i.e. calling the two functions
> that fail breaks the hwparams setup: if we wouldn't call them, no breakage
> happens at all.
>
> The two functions in question should either succeed or fail, but if
> they fail they should not modify hwparams in a way that it
> subsequently becomes unusable for snd_pcm_hw_params().
>
> This issue needs to be fixed in ALSA.
>
> Lennart
>
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

Re: Alsa plugin unable to be loaded by Pulseaudio

[Lennart Poettering]

On Tue, 08.09.09 07:45, Raymond Yau (superquad.vortex2@gmail.com) wrote:

> use those functions snd_pcm_hw_params_test_xxxxxx()

Why?

That sounds like a dirty workaround if that even works.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Alsa plugin unable to be loaded by Pulseaudio

[Raymond Yau]

what is the "test" device ?

The slave "plug" plugin usually is "hw" device

Do the following work

aplay -v -Dtest any.wav

aplay -v -M -Dtest any.wav

Why do you need the "plug" plugin ?
do you mean that pulseaudio server cannot use the exact access , format ,
rate , channels and route which required by the "test" device

aplay -v -Dplug:test any.wav

aplay -v -M -Dplug:test any.wav


2009/9/8 Ng Oon-Ee <ngoonee@gmail.com>

> Hello, please find below an issue I had with loading plugins into
> pulseaudio. The pulse dev has sent this mail on his list concerning
> alsa's interaction with pulse, indicating that there is something buggy
> with how it works. Details below. I'd be willing to post something to
> the bugtracker, if I only knew what the below means...
>
> -------- Forwarded Message --------
> From: Lennart Poettering <lennart@poettering.net>
> Reply-to: General PulseAudio Discussion
> <pulseaudio-discuss@mail.0pointer.de>
> To: pulseaudio-discuss@mail.0pointer.de
> Subject: Re: [pulseaudio-discuss] Alsa output devices, able to use alsa
> plugin?
> Date: Fri, 4 Sep 2009 01:20:15 +0200
>
> On Wed, 26.08.09 12:27, Tanu Kaskinen (tanuk@iki.fi) wrote:
>
> > D: alsa-util.c: Trying test with SND_PCM_NO_AUTO_FORMAT ...
> > D: alsa-util.c: Managed to open test
> > D: alsa-util.c: Maximum hw buffer size is 371 ms
> > I: alsa-util.c: snd_pcm_hw_params_set_periods_near() failed: Tiedostoa
> tai hakemistoa ei ole
> > I: alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed:
> Tiedostoa tai hakemistoa ei ole
> > D: alsa-util.c: Trying test without SND_PCM_NO_AUTO_FORMAT ...
> > D: alsa-util.c: Managed to open test
> > D: alsa-util.c: Maximum hw buffer size is 371 ms
> > I: alsa-util.c: snd_pcm_hw_params_set_periods_near() failed: Tiedostoa
> tai hakemistoa ei ole
> > I: alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed:
> Tiedostoa tai hakemistoa ei ole
> > D: alsa-util.c: Trying plug:test with SND_PCM_NO_AUTO_FORMAT ...
> > D: alsa-util.c: Managed to open plug:test
> > D: alsa-util.c: Maximum hw buffer size is 371 ms
> > I: alsa-util.c: snd_pcm_hw_params_set_periods_near() failed: Tiedostoa
> tai hakemistoa ei ole
> > I: alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed:
> Tiedostoa tai hakemistoa ei ole
> > D: alsa-util.c: Trying plug:test without SND_PCM_NO_AUTO_FORMAT ...
> > D: alsa-util.c: Managed to open plug:test
> > D: alsa-util.c: Maximum hw buffer size is 371 ms
> > I: alsa-util.c: snd_pcm_hw_params_set_periods_near() failed: Tiedostoa
> tai hakemistoa ei ole
> > I: alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed:
> Tiedostoa tai hakemistoa ei ole
> > I: alsa-util.c: Failed to set hardware parameters on plug:test: Tiedostoa
> tai hakemistoa ei ole
> > E: module.c: Failed to load  module "module-alsa-sink" (argument:
> "device=test"): initialization failed.
> >
> > That "Tiedostoa tai hakemistoa ei ole" error means "No such file or
> > directory". I tried also with device=hw:0,0 and device=plughw:0,0 and
> > the first worked while the latter gave the same errors. Since the failed
> > function calls pertain to buffering, I also tried with tsched=0. It
> > worked. So, maybe this is a bug in the "plug" alsa plugin, ie. it
> > doesn't implement the *_near() functions properly.
> >
> > Lennart, any insights?
>
> I am pretty sure that ALSA is broken here. We nowadays first try to
> set the number of periods, and then set the buffer size in the
> hwparams struct. If this fails we print a warning message (the ones
> you see above with all the vowels regarding
> snd_pcm_hw_params_set_periods_near()
> resp. snd_pcm_hw_params_set_buffer_size_near()), but we do not
> consider this fatal.
>
> After doing this we call snd_pcm_hw_params() to activate our
> settings -- and if this fails then we consider this a fatal problem.
>
> Now the brokeness in ALSA is that after refusing our parameters it
> still fails to configure our settings, i.e. calling the two functions
> that fail breaks the hwparams setup: if we wouldn't call them, no breakage
> happens at all.
>
> The two functions in question should either succeed or fail, but if
> they fail they should not modify hwparams in a way that it
> subsequently becomes unusable for snd_pcm_hw_params().
>
> This issue needs to be fixed in ALSA.
>
> Lennart
>
>
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>

Re: Alsa plugin unable to be loaded by Pulseaudio

[Ng Oon-Ee]

Hi, if top-posting is frowned upon here I apologize, please let me know
and I won't repeat it.

The "test" device is defined as follows (should have put it in
initially).

pcm.test {
 type plug
 slave { pcm "hw:0,0" }
}

It works with aplay. My issue is that the pulseaudio server cannot load
alsa plugins since 1.0.20 (as far as I can tell, ubuntuforums has a
thread which suggested as such). When I queried the pulse ML, Lennart
posted the below reply, which I've forwarded here to alsa-devel.

Basically, the issue as Lennart sees it is summarized by his last 3
paragraphs (bottom of this mail). He specifies the difference between
the way alsa is reacting to pulse and the way it 'should'.

On Wed, 2009-09-09 at 16:10 +0800, Raymond Yau wrote:
> what is the "test" device ?
> 
> The slave "plug" plugin usually is "hw" device
> 
> Do the following work
> 
> aplay -v -Dtest any.wav
> 
> aplay -v -M -Dtest any.wav
> 
> Why do you need the "plug" plugin ?
> do you mean that pulseaudio server cannot use the exact access , format ,
> rate , channels and route which required by the "test" device
> 
> aplay -v -Dplug:test any.wav
> 
> aplay -v -M -Dplug:test any.wav
> 
> 
> 2009/9/8 Ng Oon-Ee <ngoonee@gmail.com>
> 
> > Hello, please find below an issue I had with loading plugins into
> > pulseaudio. The pulse dev has sent this mail on his list concerning
> > alsa's interaction with pulse, indicating that there is something buggy
> > with how it works. Details below. I'd be willing to post something to
> > the bugtracker, if I only knew what the below means...
> >
> > -------- Forwarded Message --------
> > From: Lennart Poettering <lennart@poettering.net>
> > Reply-to: General PulseAudio Discussion
> > <pulseaudio-discuss@mail.0pointer.de>
> > To: pulseaudio-discuss@mail.0pointer.de
> > Subject: Re: [pulseaudio-discuss] Alsa output devices, able to use alsa
> > plugin?
> > Date: Fri, 4 Sep 2009 01:20:15 +0200
> >
> > On Wed, 26.08.09 12:27, Tanu Kaskinen (tanuk@iki.fi) wrote:
> >
> > > D: alsa-util.c: Trying test with SND_PCM_NO_AUTO_FORMAT ...
> > > D: alsa-util.c: Managed to open test
> > > D: alsa-util.c: Maximum hw buffer size is 371 ms
> > > I: alsa-util.c: snd_pcm_hw_params_set_periods_near() failed: Tiedostoa
> > tai hakemistoa ei ole
> > > I: alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed:
> > Tiedostoa tai hakemistoa ei ole
> > > D: alsa-util.c: Trying test without SND_PCM_NO_AUTO_FORMAT ...
> > > D: alsa-util.c: Managed to open test
> > > D: alsa-util.c: Maximum hw buffer size is 371 ms
> > > I: alsa-util.c: snd_pcm_hw_params_set_periods_near() failed: Tiedostoa
> > tai hakemistoa ei ole
> > > I: alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed:
> > Tiedostoa tai hakemistoa ei ole
> > > D: alsa-util.c: Trying plug:test with SND_PCM_NO_AUTO_FORMAT ...
> > > D: alsa-util.c: Managed to open plug:test
> > > D: alsa-util.c: Maximum hw buffer size is 371 ms
> > > I: alsa-util.c: snd_pcm_hw_params_set_periods_near() failed: Tiedostoa
> > tai hakemistoa ei ole
> > > I: alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed:
> > Tiedostoa tai hakemistoa ei ole
> > > D: alsa-util.c: Trying plug:test without SND_PCM_NO_AUTO_FORMAT ...
> > > D: alsa-util.c: Managed to open plug:test
> > > D: alsa-util.c: Maximum hw buffer size is 371 ms
> > > I: alsa-util.c: snd_pcm_hw_params_set_periods_near() failed: Tiedostoa
> > tai hakemistoa ei ole
> > > I: alsa-util.c: snd_pcm_hw_params_set_buffer_size_near() failed:
> > Tiedostoa tai hakemistoa ei ole
> > > I: alsa-util.c: Failed to set hardware parameters on plug:test: Tiedostoa
> > tai hakemistoa ei ole
> > > E: module.c: Failed to load  module "module-alsa-sink" (argument:
> > "device=test"): initialization failed.
> > >
> > > That "Tiedostoa tai hakemistoa ei ole" error means "No such file or
> > > directory". I tried also with device=hw:0,0 and device=plughw:0,0 and
> > > the first worked while the latter gave the same errors. Since the failed
> > > function calls pertain to buffering, I also tried with tsched=0. It
> > > worked. So, maybe this is a bug in the "plug" alsa plugin, ie. it
> > > doesn't implement the *_near() functions properly.
> > >
> > > Lennart, any insights?
> >
> > I am pretty sure that ALSA is broken here. We nowadays first try to
> > set the number of periods, and then set the buffer size in the
> > hwparams struct. If this fails we print a warning message (the ones
> > you see above with all the vowels regarding
> > snd_pcm_hw_params_set_periods_near()
> > resp. snd_pcm_hw_params_set_buffer_size_near()), but we do not
> > consider this fatal.
> >
> > After doing this we call snd_pcm_hw_params() to activate our
> > settings -- and if this fails then we consider this a fatal problem.
> >
> > Now the brokeness in ALSA is that after refusing our parameters it
> > still fails to configure our settings, i.e. calling the two functions
> > that fail breaks the hwparams setup: if we wouldn't call them, no breakage
> > happens at all.
> >
> > The two functions in question should either succeed or fail, but if
> > they fail they should not modify hwparams in a way that it
> > subsequently becomes unusable for snd_pcm_hw_params().
> >
> > This issue needs to be fixed in ALSA.
> >
> > Lennart
> >
> >
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Alsa plugin unable to be loaded by Pulseaudio

[Lennart Poettering]

On Wed, 09.09.09 21:16, Ng Oon-Ee (ngoonee@gmail.com) wrote:

> The "test" device is defined as follows (should have put it in
> initially).
> 
> pcm.test {
>  type plug
>  slave { pcm "hw:0,0" }
> }
> 
> It works with aplay. My issue is that the pulseaudio server cannot load
> alsa plugins since 1.0.20 (as far as I can tell, ubuntuforums has a
> thread which suggested as such). When I queried the pulse ML, Lennart
> posted the below reply, which I've forwarded here to alsa-devel.
> 
> Basically, the issue as Lennart sees it is summarized by his last 3
> paragraphs (bottom of this mail). He specifies the difference between
> the way alsa is reacting to pulse and the way it 'should'.

After the discussion we had on alsa-devel about the ordering how buffer
size and period size are initialized i have now changed PA git to try
harder to initialize those values. Would be good if you could check if
that actually makes your problem go away.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4

Re: Alsa plugin unable to be loaded by Pulseaudio

[Ng Oon-Ee]

On Wed, 2009-09-09 at 15:59 +0200, Lennart Poettering wrote:
> On Wed, 09.09.09 21:16, Ng Oon-Ee (ngoonee@gmail.com) wrote:
> 
> > The "test" device is defined as follows (should have put it in
> > initially).
> > 
> > pcm.test {
> >  type plug
> >  slave { pcm "hw:0,0" }
> > }
> > 
> > It works with aplay. My issue is that the pulseaudio server cannot load
> > alsa plugins since 1.0.20 (as far as I can tell, ubuntuforums has a
> > thread which suggested as such). When I queried the pulse ML, Lennart
> > posted the below reply, which I've forwarded here to alsa-devel.
> > 
> > Basically, the issue as Lennart sees it is summarized by his last 3
> > paragraphs (bottom of this mail). He specifies the difference between
> > the way alsa is reacting to pulse and the way it 'should'.
> 
> After the discussion we had on alsa-devel about the ordering how buffer
> size and period size are initialized i have now changed PA git to try
> harder to initialize those values. Would be good if you could check if
> that actually makes your problem go away.
> 
> Lennart
> 

Thanks Lennart. Gonna try it out now.

Re: Alsa plugin unable to be loaded by Pulseaudio

[Ng Oon-Ee]

On Wed, 2009-09-09 at 22:16 +0800, Ng Oon-Ee wrote:
> On Wed, 2009-09-09 at 15:59 +0200, Lennart Poettering wrote:
> > On Wed, 09.09.09 21:16, Ng Oon-Ee (ngoonee@gmail.com) wrote:
> > 
> > > The "test" device is defined as follows (should have put it in
> > > initially).
> > > 
> > > pcm.test {
> > >  type plug
> > >  slave { pcm "hw:0,0" }
> > > }
> > > 
> > > It works with aplay. My issue is that the pulseaudio server cannot load
> > > alsa plugins since 1.0.20 (as far as I can tell, ubuntuforums has a
> > > thread which suggested as such). When I queried the pulse ML, Lennart
> > > posted the below reply, which I've forwarded here to alsa-devel.
> > > 
> > > Basically, the issue as Lennart sees it is summarized by his last 3
> > > paragraphs (bottom of this mail). He specifies the difference between
> > > the way alsa is reacting to pulse and the way it 'should'.
> > 
> > After the discussion we had on alsa-devel about the ordering how buffer
> > size and period size are initialized i have now changed PA git to try
> > harder to initialize those values. Would be good if you could check if
> > that actually makes your problem go away.
> > 
> > Lennart
> > 
> 
> Thanks Lennart. Gonna try it out now.
> 
Ah, the git download was quicker than I expected. I've tested it out,
and the 'test' case shown above does work now, thanks.

Unfortunately the main root of my question was to use the 'alsaequal'
plugin from http://www.thedigitalmachine.net/alsaequal.html which still
does not work. Same error as previously.

Re: Alsa plugin unable to be loaded by Pulseaudio

[Raymond Yau]

Post the output of

aplay -v -Dplug:plugequal any.wav

AFAIK , ladspa plugin use float as Input and output


2009/9/9 Ng Oon-Ee <ngoonee@gmail.com>

>
> Ah, the git download was quicker than I expected. I've tested it out,
> and the 'test' case shown above does work now, thanks.
>
> Unfortunately the main root of my question was to use the 'alsaequal'
> plugin from http://www.thedigitalmachine.net/alsaequal.html which still
> does not work. Same error as previously.
>
>

Re: Alsa plugin unable to be loaded by Pulseaudio

[Ng Oon-Ee]

Hi Raymond,

Thanks for your assistance. I have mentioned previously that aplay works
fine with alsaequal, my problem all along was getting it to load in
Pulseaudio. Lennart took this discussion off-list, when a solution is
forthcoming, or more info requirements, we'll bring it back here.

On Thu, 2009-09-10 at 14:40 +0800, Raymond Yau wrote:
> Post the output of
> 
> aplay -v -Dplug:plugequal any.wav
> 
> AFAIK , ladspa plugin use float as Input and output
> 
> 
> 2009/9/9 Ng Oon-Ee <ngoonee@gmail.com>
> 
> >
> > Ah, the git download was quicker than I expected. I've tested it out,
> > and the 'test' case shown above does work now, thanks.
> >
> > Unfortunately the main root of my question was to use the 'alsaequal'
> > plugin from http://www.thedigitalmachine.net/alsaequal.html which still
> > does not work. Same error as previously.
> >