[pulseaudio-discuss] Alsa output devices, able to use alsa plugin?

Discussion:

Ng Oon-Ee

2009-08-26 04:10:24 UTC

Hi all,

I know back in March there was a conversation about alsa devices to be
used with load-module module-alsa-sink. Basically, Lennart mentioned
NEVER to use device=hw:0,0 (I do that, though, as I don't use
module-hal-detect so that I can choose which modules I want through a
script). However, I don't see any discussion on how to choose another
device. So, two questions:-

1. Instead of "load-module module-alsa-sink device=hw:0,0", what should
I be using to load the appropriate device? Assuming I'm not using
module-hal-detect.

2. I'm interested in using an alsa plugin to modify pulse's output
before it hits my card. Specifically the alsaequal plugin. I have
specified it in my .asoundrc as below:-

ctl.equal {
type equal;
}
pcm.plugequal {
type equal;
slave { pcm "plughw:0,0" }
}
pcm.equal {
type plug;
slave.pcm plugequal;
}

This works properly with aplay -D equal, of course. How do I modify my
device string in load-module module-alsa-sink to use the 'equal' output,
so that I can dynamically equalize the output before it hits the
speakers? Is this even possible?

Thanks all.

Tanu Kaskinen

2009-08-26 07:22:16 UTC

Permalink

Post by Ng Oon-Ee
Hi all,
I know back in March there was a conversation about alsa devices to be
used with load-module module-alsa-sink. Basically, Lennart mentioned
NEVER to use device=hw:0,0 (I do that, though, as I don't use
module-hal-detect so that I can choose which modules I want through a
script). However, I don't see any discussion on how to choose another
device. So, two questions:-
1. Instead of "load-module module-alsa-sink device=hw:0,0", what should
I be using to load the appropriate device? Assuming I'm not using
module-hal-detect.

http://www.opensubscriber.com/message/fedora-devel-list at redhat.com/12018387.html

Post by Ng Oon-Ee
2. I'm interested in using an alsa plugin to modify pulse's output
before it hits my card. Specifically the alsaequal plugin. I have
specified it in my .asoundrc as below:-
ctl.equal {
type equal;
}
pcm.plugequal {
type equal;
slave { pcm "plughw:0,0" }
}
pcm.equal {
type plug;
slave.pcm plugequal;
}
This works properly with aplay -D equal, of course. How do I modify my
device string in load-module module-alsa-sink to use the 'equal' output,
so that I can dynamically equalize the output before it hits the
speakers? Is this even possible?

load-module module-alsa-sink device=equal

You might also want to change the

slave { pcm "plughw:0,0" }

line to

slave { pcm "plug:front:0" }

just to reduce ugliness (= unneeded assumptions). I'm not 100% sure that
works, though. If it doesn't, just revert to the old version. Hmm...
since pcm.equal is already of type plug, I think the line can be
simplified to

slave { pcm "front:0" }

I'm not totally sure about this either (fiddling with alsa config isn't
one of my hobbies).

There are other approaches to equalization, but I don't feel like going
in the details of those if this works for you. If you're interested, I
just point you to this:
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-August/004730.html

--
Tanu Kaskinen

Ng Oon-Ee

2009-08-26 07:39:34 UTC

Permalink

Hi Tanu, and thanks...

Post by Tanu Kaskinen

Post by Ng Oon-Ee
1. Instead of "load-module module-alsa-sink device=hw:0,0", what should
I be using to load the appropriate device? Assuming I'm not using
module-hal-detect.

http://www.opensubscriber.com/message/fedora-devel-list at redhat.com/12018387.html

Thank you.

Post by Tanu Kaskinen

First off, front:0 doesn't work with aplay -D equal.

Post by Tanu Kaskinen
I'm not totally sure about this either (fiddling with alsa config isn't
one of my hobbies).
There are other approaches to equalization, but I don't feel like going
in the details of those if this works for you. If you're interested, I
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-August/004730.html

Anyway, I have the above (with slave changed to plug:front:0 as
suggested) in my .asoundrc. Once again, aplay -D equal works fine. When
I try load-module module-alsa-sink device=equal:-

[ngoonee at ngoonee-laptop ~]$ pactl load-module module-alsa-sink
device=equal
Failure: Module initalization failed

Besides the typo there (initialization, not initalization), somehow it
doesn't want to load my device. Any ideas? Am on alsa 1.0.20 and Pulse
0.9.15 (will be getting 0.9.16 soon, when the final release is done).

Tanu Kaskinen

2009-08-26 08:39:51 UTC

Permalink

Post by Ng Oon-Ee
Anyway, I have the above (with slave changed to plug:front:0 as
suggested) in my .asoundrc. Once again, aplay -D equal works fine. When
I try load-module module-alsa-sink device=equal:-
[ngoonee at ngoonee-laptop ~]$ pactl load-module module-alsa-sink
device=equal
Failure: Module initalization failed
Besides the typo there (initialization, not initalization), somehow it
doesn't want to load my device. Any ideas? Am on alsa 1.0.20 and Pulse
0.9.15 (will be getting 0.9.16 soon, when the final release is done).

There should be more error messages about loading the module in the
daemon log. They might be informative enough to tell what went wrong.
See /var/log/syslog.

--
Tanu Kaskinen

Ng Oon-Ee

2009-08-26 08:48:23 UTC

Permalink

Post by Tanu Kaskinen

There should be more error messages about loading the module in the
daemon log. They might be informative enough to tell what went wrong.
See /var/log/syslog.

My syslog is empty.

errors.log gives
Aug 26 16:41:54 ngoonee-laptop pulseaudio[7739]: module.c: Failed to
load module "module-alsa-sink" (argument: "device=equal"):
initialization failed.

Post by Tanu Kaskinen

Post by Ng Oon-Ee
Ah, forgot the last bit.

Post by Tanu Kaskinen
There are other approaches to equalization, but I don't feel like going
in the details of those if this works for you. If you're interested, I
https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-August/004730.html

I read about this when it was posted, but my impression was that this
was similar to the ladspa plugin for alsa, meaning its a fixed equalizer
and not a runtime-modifiable one. Is this correct, or was I just making
nonsense assumptions?

It is runtime-modifiable. The GUI (qpaeq) that is mentioned in the mail
is used to control the equalization parameters in realtime.

That's interesting, and I'll look into it in future perhaps. For now,
I'm more interested to find out why this doesn't work on my system. It
may be a more general problem, as I was trying such outputs as:-

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

Which should work, since it doesn't even do anything. I get the same
error message trying to load it up though. Could somebody test this out
(just have the above in your .asoundrc and try to use 'test' as the
device for module-alsa-sink.

Tanu Kaskinen

2009-08-26 09:27:49 UTC

Permalink

Post by Ng Oon-Ee
That's interesting, and I'll look into it in future perhaps. For now,
I'm more interested to find out why this doesn't work on my system. It
may be a more general problem, as I was trying such outputs as:-
pcm.test {
type plug
slave { pcm "hw:0,0" }
}
Which should work, since it doesn't even do anything. I get the same
error message trying to load it up though. Could somebody test this out
(just have the above in your .asoundrc and try to use 'test' as the
device for module-alsa-sink.

Indeed, it doesn't work. This is the log output:

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?

--
Tanu Kaskinen

Ng Oon-Ee

2009-08-26 09:33:22 UTC

Permalink

Post by Tanu Kaskinen

Post by Ng Oon-Ee
pcm.test {
type plug
slave { pcm "hw:0,0" }
}
Which should work, since it doesn't even do anything. I get the same
error message trying to load it up though. Could somebody test this out
(just have the above in your .asoundrc and try to use 'test' as the
device for module-alsa-sink.

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?

Just to add a bit to this (nice thread here for Lennart to read when he
wakes up, i think), I've seen oblique references to this being an issue
with latest Alsa. Specifically there's this giant Pulseaudio with
system-wide equalizer thread on ubuntuforums.org where the latests posts
seem to indicate that the users of the latest versions of Ubuntu
(Karmic, the current alpha/beta due October) aren't able to use the
system-wide equalizer, which relies on the alsa ladspa plugin.

So it does seem as if there's something in latest alsa (.20?) which is
causing this. If I have time over the weekend I may downgrade to .19 and
see if that fixes it.

Ng Oon-Ee

2009-08-28 05:35:32 UTC

Permalink

Post by Ng Oon-Ee

Post by Tanu Kaskinen

Just to add a bit to this (nice thread here for Lennart to read when he
wakes up, i think), I've seen oblique references to this being an issue
with latest Alsa. Specifically there's this giant Pulseaudio with
system-wide equalizer thread on ubuntuforums.org where the latests posts
seem to indicate that the users of the latest versions of Ubuntu
(Karmic, the current alpha/beta due October) aren't able to use the
system-wide equalizer, which relies on the alsa ladspa plugin.
So it does seem as if there's something in latest alsa (.20?) which is
causing this. If I have time over the weekend I may downgrade to .19 and
see if that fixes it.

Update: I tried downgrading alsa to .19 today, but couldn't due to a
large number of packages on my distro (Arch) which depend on .20
(gstreamer, libcanberra, the works). So no new information as of yet.

Lennart Poettering

2009-09-03 23:20:15 UTC

Permalink

Post by Tanu Kaskinen
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

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

Ng Oon-Ee

2009-09-07 22:49:32 UTC

Permalink

Post by Lennart Poettering

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

I will report this, then. How active are ALSA devs on their IRC?

Lennart Poettering

2009-09-07 22:52:41 UTC

Permalink

Post by Ng Oon-Ee

Post by Lennart Poettering
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

I will report this, then. How active are ALSA devs on their IRC?

To my knowledge they do not hang out on a public IRC channels. #alsa
is useless.

Try the alsa-devel ML. That's your best chance.

Lennart

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

Ng Oon-Ee

2009-08-26 07:42:06 UTC

Permalink

Ah, forgot the last bit.

Tanu Kaskinen

2009-08-26 08:41:48 UTC

Permalink

Post by Ng Oon-Ee
Ah, forgot the last bit.

It is runtime-modifiable. The GUI (qpaeq) that is mentioned in the mail
is used to control the equalization parameters in realtime.

--
Tanu Kaskinen