[alsa-devel] 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 at 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 at poettering.net>
> Reply-to: General PulseAudio Discussion
> <pulseaudio-discuss at mail.0pointer.de>
> To: pulseaudio-discuss at 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 at 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 at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>