[alsa-devel] Alsa plugin unable to be loaded by Pulseaudio
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
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
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
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
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
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
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.
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.
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.
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.
participants (3)
-
Lennart Poettering -
Ng Oon-Ee -
Raymond Yau