Hi,
On Mon, Dec 20, 2010 at 1:14 PM, Carsten Breuer
<carstenbreuer...@textwork.de> wrote:
> Hi all,
>
>
> i'm using mpd for almost a decade now and it always
> works great. I had used the oss output drivers, because
> it was very easy to get mpd installed and configured
> with in in 5 minutes. I had only to look for
> what /dev/dsp are available and point mpd to the right one.
>
> These days and OSS are gone now and configuring of mpd
> is IMO a nightmare. We not only have to deal with the
> pulseaudio crap, but also with the undocumented alsa
> configuration.
>
> The funny thing is, that i can write any garbage
> in the device section of audio_output:
>
> audio_output {
> type "alsa"
> name "Audigy"
> device "mpd_with_alsa_sucks"
>
> MPD forwards anything under device to the function
> snd_pcm_open. MPD even don't check if there is something
> valid in there. With the config line above, mpd
> starts without errors. If i try to play something,
> then the following lines is reported in mpd.log:
>
> output: Failed to open "Audigy" [alsa]: Failed to open ALSA device
> "mpd_with_alsa_sucks": No such file or directory
>
> Of course, it fails!
>
> We should IMO update the documentation to point users in
> the right direction to configure MPD. I think, that we have
> enough experts that understand alsa enough to write something
> that helps other users:
>
> 1. How do i get a list of the available channels in
> MPD/Alsa notation (hw:x,x or plughw:x,x)?
Device enumeration in ALSA is a non-trivial problem. To be honest, the
one piece of software I know of that does this really well is
PulseAudio. It uses udev or HAL to enumerate your soundcards, and then
provides a user-friendly string indicating the type of the card (e.g.
Internal Audio, USB Headphones, etc) in most user-visible apps.
We *could* add support for device enumeration from one source or
another to mpd, but if you're using the ALSA backend, chances are high
that you don't *want* to use a raw device. Unless you have hardware
mixing, which is less and less common, you will want to use a virtual
device such as dmix for software mixing. Otherwise, mpd's audio will
"hog" your soundcard, preventing other apps from using it.
Unfortunately, virtual devices (i.e. ALSA software plugins) can not be
enumerated with udev or HAL, because they're just defined in a
configuration file, such as /etc/asound.conf, ~/.asoundrc, or
/usr/share/alsa/alsa.conf.
The only way to be aware of all the ALSA soft devices that exist on
your system is to examine the configuration files I just listed, or
write a program that parses them. This is a more challenging and
volatile problem than even the hardware enumeration case, because you
can't fall back on the convenience of udev or HAL, you have to fully
understand how to parse all possible versions of the config files,
etc.
> 2. How can if configure that channel (SPDIF, volume)?
Well, if you knew the ALSA device number in hw:x,y format, you could
configure it with your favorite ALSA mixing app, be it alsamixer,
gnome-volume-control, or dozens of others both graphical and CLI. So
this boils down to a trivial user task after solving the first
problem.
> 3. How do i get diagnostic information and how can
> i track problems down if mpd doesn't work?
Run mpd without daemonizing, so that you can see the full console
output as it happens, and of course turn on verbose. If you've been
using mpd that long, then you're probably a Linux/UNIX old hand, yeah?
"No such file or directory" is common parlance for any number of
things, such as "That device doesn't exist", or "That device is
configured incorrectly." The other common system errno you might see
from ALSA is "Device or resource busy" -- which means that some other
app is using the soundcard. To find the app, you'd have to run the
`fuser' program on /dev/snd/* to get a list of processes using sound
devices, then match them up and figure out which one is using the
sound device you care about.
Everything I have written here comes as common knowledge to anyone who
is serious about using "raw" ALSA for any program, not just mpd. ALSA
itself is extremely finnicky and complex; it is not user-friendly, and
it is almost impossible to *make* it user-friendly. I said _almost_
impossible, though: PulseAudio is currently the best tool we have for,
in short, bringing order to the chaos that is ALSA. Pulse isn't
perfect, but it smooths over a lot of these issues by taking care of
them for you. It does require some measure of integration into the
distro, but in 2010 the most popular distros integrate PulseAudio
rather well.
If you're using an up-to-date distribution with a recent version of
PulseAudio and ALSA, I expect that your user experience would be quite
good, barring any remaining driver bugs in ALSA's Audigy support (it's
been one of the more notorious drivers for many years). Fedora 14,
OpenSUSE 11.3, or Ubuntu 10.10 come to mind as particularly good
candidates.
If you want to play audio with a specific output of specific soundcard
with the PulseAudio backend to mpd, you have two options. The first
option is to designate that soundcard as the default sink in PA. The
default sink is what you get if you don't specify anything in
particular for the sink name at the application level. Mpd is capable
of using the default sink, if you omit the "server" and "sink" options
for the pulse output; see http://mpd.wikia.com/wiki/PulseAudio for
details. To designate a soundcard as default sink, you can use a
graphical PA client, or the CLI as you prefer. In recent versions of
Gnome, gnome-volume-control-applet is tightly integrated with PA, and
it even lets you select your default source and sink. An older app,
with some known flaws (but still gets the job done), is padevchooser.
Use gnome-volume-control-applet or the CLI as your first choices,
though.
The second option for specifying your sink to mpd is to discover the
sink name using `pactl list'. Fortunately, unlike ALSA, this name
should be stable for each distinct hardware device, across reboots. So
unless you swap out soundcards every day, you should be able to
discover this name _once_, plunk it in mpd.conf, and you're good to
go.
The reasons not to use PA are being eroded day by day, due to a bunch
of hackers from all walks of life continually improving PA's
functionality, as well as fixing bugs in ALSA that are known to
trigger problems in PA. Yes, you have to learn something new after
using OSS for 10 years, but you would also have to learn something new
if you use raw ALSA. And I think that it would be easier for you to
learn PA than to learn ALSA.
Of course, you could always use an ancient distro that still supports
OSS, and run it until the end of time... no one requires you to learn
something new. :)
-Sean
>
> In my case, i have two soundcards installed and trying to
> get mpd using the SPDIF output of a Audigy 1.
>
> Any help is welcome.
>
>
>
> Best Regards,
>
>
>
> Carsten
>
> ------------------------------------------------------------------------------
> Lotusphere 2011
> Register now for Lotusphere 2011 and learn how
> to connect the dots, take your collaborative environment
> to the next level, and enter the era of Social Business.
> http://p.sf.net/sfu/lotusphere-d2d
> _______________________________________________
> Musicpd-dev-team mailing list
> Musicpd-dev-team@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
>
------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Musicpd-dev-team mailing list
Musicpd-dev-team@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
