Bug#568588: mpd: MPD default config doesn't allow multiple programs to share audio output via ALSA
I completely agree with Konstantin Khomoutov. All the apps like web browsers and vlc are able to use dmix without any noticeable loss of sound quality. Also, vlc with dmix for some reason still uses less CPU than mpd without dmix. With firefox there's another problem: when a video (html5 or flash) has been played, the program still sits on the audio device until the browser is restarted. This is definitely not a good behavior but it is a problem if something like MPD wants to have exclusive access to the hardware. I believe that only realtime production-critical programs like jackd should use hw:0 by default. MPD is just another media player like vlc or mplayer. Alsa developers decided to enable dmix by default, and why we are reverting their decision on a per-program basis? Why ALSA has a default device at all then? Isn't it actually designed to be used by default? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568588: [Pkg-mpd-maintainers] Bug#568588: mpd: MPD default config doesn't allow multiple programs to share audio output via ALSA
Yury Bulka schrieb am Monday, den 17. December 2012: I completely agree with Konstantin Khomoutov. All the apps like web browsers and vlc are able to use dmix without any noticeable loss of sound quality. Also, vlc with dmix for some reason still uses less CPU than mpd without dmix. With firefox there's another problem: when a video (html5 or flash) has been played, the program still sits on the audio device until the browser is restarted. This is definitely not a good behavior but it is a problem if something like MPD wants to have exclusive access to the hardware. I believe that only realtime production-critical programs like jackd should use hw:0 by default. MPD is just another media player like vlc or mplayer. Alsa developers decided to enable dmix by default, and why we are reverting their decision on a per-program basis? Why ALSA has a default device at all then? Isn't it actually designed to be used by default? I plan to orphan mpd soon. Feel free to take over. Alex -- Alexander Wirt, formo...@formorer.de CC99 2DDD D39E 75B0 B0AA B25C D35B BC99 BC7D 020A -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568588: mpd: MPD default config doesn't allow multiple programs to share audio output via ALSA
On 2012/12/17 11:42, Yury Bulka yurk...@gmail.com wrote: I completely agree with Konstantin Khomoutov. All the apps like web browsers and vlc are able to use dmix without any noticeable loss of sound quality. That depends on your quality requirements. dmix defaults to 48 kHz and 16 bit. Most music (all music ripped from CDs) is 44.1 kHz. You could argue that you don't hear a quality loss from resampling, but quality is definitely lost, and more CPU is consumed for the resampler. Now if you're listening to high-quality 24 bit FLAC files, you're in trouble: dmix will force you to throw away the additional 8 bits. Maybe you can't hear that either, well ok, then that's your personal requirement for audio quality. Also, vlc with dmix for some reason still uses less CPU than mpd without dmix. If (the latest) MPD uses more CPU than *any* other software music player, then this is either a configuration error, a different (more expensive) resampler that MPD defaults to (can be configured), or a bug. If you think it's the latter, I'm very interested in fixing this problem and optimizing MPD to make it faster again than the other software. Post your repeatable benchmark numbers comparing vlc/MPD and a perf report of MPD to bugs.musicpd.org and I'll take care of it. However, this bug report is about MPD 0.15.8. Much has changed, much has been optimized since 0.15. I will not opimize MPD 0.15, because I have done that already, and it's called MPD 0.17.2. Let's not beat a dead horse. I believe that only realtime production-critical programs like jackd should use hw:0 by default. MPD is just another media player like vlc or mplayer. Alsa developers decided to enable dmix by default, and why we are reverting their decision on a per-program basis? Why ALSA has a default device at all then? Isn't it actually designed to be used by default? dmix is per-user, but MPD usually runs as a different user (repeating myself). Given the severe disadvantages of dmix and its uselessness when used by MPD, disabling it is a reasonable choice for me. That's just my opinion, and everybody can put his opinion in his mpd.conf. Max -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568588: mpd: MPD default config doesn't allow multiple, programs to share audio output via ALSA
I did not measure if dmix really eats up CPU, but I'm more concerned with this problem: MPD, being a daemon is usually ordered to play some playlist or stream in the background. Now I suddenly want to, say, watch a youtube video. Now what? With the current setup my attempt will fail, I then need to recall why this happens, then I had to fire an MPD front-end and order MPD to stop, then re-start whatever I wanted to watch/hear (and what failed due to the busy sound subsystem) then get back to MPD front-end and continue listening. The problem is that this does really set MPD apart from the other sound-aware software as if it was special in some kind, but it's not! Conversely, it's very idea is to not get in the way. Since crappy single-channel audio hardware is ubiquituous and I'm not aware of another A/V player packaged for Debian which behaved like MPD by monopolising the audio device, I urge you to rethink the default configuration. Also I wonder what happens to the users who enable sound notifications in their software (say, in IM clients, which is a quite common setup). May be it would be possible to make this setting tunable via debconf? Say, you could provide a template of mpd.conf with some sort of tokens (akin to those used by autoconf) which would be then expanded based on what settings the user selected using debconf? The relevant debconf setting could then be presented as an alteration between the I have a single-channel audio card/I don't know (the default) and I have a multi-channel audio card. P.S. Also I don't quite get what is so bad about dmix? I stumbled upon this bug in MPD when I was forced to switch to laptop (from a normal desktop computer which had an SB Live! card with 32 HW channels), and so I had to tweak the configuration. I had Lenny on this laptop and now I have upgraded to Squeeze -- no single problem with dmix. MPD works OK, all other A/V software works OK and even the three games I happen to touch from time to time (Doom, Descent and Warzone 2100) work OK with it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568588: mpd: MPD default config doesn't allow multiple, programs to share audio output via ALSA
On 2010/04/23 05:27, Delirium delir...@hackish.org wrote: I had a different problem with this default setup. My audio worked fine, but MPD had a broken volume knob. The problem appears to be this pair of lines: device hw:0,0 mixer_control PCM On my card, hw:0,0 isn't the PCM channel, so this results in mpd fiddling a different volume knob than the one it's playing through. Commenting these lines back out, or replacing hw:0,0 with default, made it work. That used to be the default, but it caused so many headaches and support nightmares, it was changed. In addition to actual problems, dmix works only for the same uid, severely degrades the sound quality and increases CPU usage. You're free to activate it if you wish. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568588: mpd: MPD default config doesn't allow multiple, programs to share audio output via ALSA
Excerpts from Max Kellermann's message of Fri Apr 23 02:52:13 -0400 2010: On my card, hw:0,0 isn't the PCM channel, so this results in mpd fiddling a different volume knob than the one it's playing through. Commenting these lines back out, or replacing hw:0,0 with default, made it work. That used to be the default, but it caused so many headaches and support nightmares, it was changed. In addition to actual problems, dmix works only for the same uid, severely degrades the sound quality and increases CPU usage. You're free to activate it if you wish. What do you think about leaving the device at hw:0,0 as it is but allowing the mixer to be determined automatically (i.e. just comment out PCM in the config file I ship)? I agree about dmix but maybe that would be a good compromise. -- things change. deck...@red-bean.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568588: mpd: MPD default config doesn't allow multiple, programs to share audio output via ALSA
I had a different problem with this default setup. My audio worked fine, but MPD had a broken volume knob. The problem appears to be this pair of lines: device hw:0,0 mixer_control PCM On my card, hw:0,0 isn't the PCM channel, so this results in mpd fiddling a different volume knob than the one it's playing through. Commenting these lines back out, or replacing hw:0,0 with default, made it work. Since the ALSA config already has a way of specifying a default device, shouldn't the default mpd.conf just use that one, instead of overriding it with hw:0,0? -Mark
Bug#568588: mpd: MPD default config doesn't allow multiple programs to share audio output via ALSA
On 2010/02/06 01:13, Lutz Herting webmas...@phatsonic.de wrote: Are these optional lines included in the MPD config by default for a good reason? Otherwise it may be a good idea to comment them by default, since they seem to produce a serious problem for some users. The problems with enabling dmix (very bad sound quality, high CPU usage, random crashes due to ALSA bugs) usually outweigh the problems of two applications accessing the same hardware device. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568588: mpd: MPD default config doesn't allow multiple programs to share audio output via ALSA
Max Kellermann schrieb:
The problems with enabling dmix (very bad sound quality, high CPU
usage, random crashes due to ALSA bugs) usually outweigh the problems
of two applications accessing the same hardware device.
In the meantime I've read some more and learned that MPD falls back to
using dmix, since it's activated by default in ALSA now. Didn't know
that before.
So there IS a good reason for these options. ;)
The worse sound quality and the higher CPU usage happen due to the
resampling to 48 kHz, that dmix does in the background. It can be
addressed by forcing dmix to resample everything to 44.1 kHz instead.
Since most music uses that there's nothing to do for dmix most of the
time when listening to music (meaning no decrease in quality and no CPU
usage).
But of course after that the same problems are there e.g. when watching
DVDs (that use 48 kHz).
So unsetting the options mentioned above by default isn't the best option.
I don't know enough about the possibilities of deb packages (yet), but
would it be possible to have these options enabled or disabled according
to the computers sound chipset? Something like if (manufacturer ==
'intel') { echo 'Your sound hardware sucks.'; enable_demix(); } ?
I guess my next reading will be about pulseaudio... ;)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568588: mpd: MPD default config doesn't allow multiple programs to share audio output via ALSA
Package: mpd
Version: 0.15.8-1+b1
Severity: important
Tags: patch
I'm new to Debian and this is my first bug report, so tell me if something is
wrong or missing. ;)
After trying out MPD for the first time everything worked great, but then I
realized that other apps stopped playing sound (I realized it with flash).
So I stopped MPD playback, restarted the browser and tried again. This time
flash had sound, but MPD couldn't play and the logfile showed:
Feb 05 23:48 : output: Failed to open My ALSA Device [alsa]: Failed to open
ALSA device hw:0,0: Device or resource busy
Feb 05 23:48 : player_thread: problems opening audio device while playing
free/stockfinster/sunset/stockfinster. - verge.mp3
After more abusing of Google (the first one was to find out how to use the damn
thing in the first place and finding a nice client ;) ) I endet up in some
Ubuntu Forum and found the following fix.
In MPD conf I uncommented all optional lines from the ALSA output config like
this:
audio_output {
typealsa
nameMy ALSA Device
# device hw:0,0# optional
# format 44100:16:2# optional
# mixer_devicedefault # optional
# mixer_control PCM # optional
# mixer_index 0 # optional
}
Now all apps, including MPD, play with each other without anyone trying to play
king of the hill.
I'm not sure why that worked - but since it did I'll put that question on my
todo-list for later...
My system is a Fujitsu/Siemens laptop with onboard intel sound:
$ lspci | grep Audio
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio
Controller (rev 03)
Are these optional lines included in the MPD config by default for a good
reason?
Otherwise it may be a good idea to comment them by default, since they seem to
produce a serious problem for some users.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages mpd depends on:
ii adduser 3.112 add and remove users and groups
ii libao2 0.8.8-5 Cross Platform Audio Output Librar
ii libasound2 1.0.21a-1 shared library for ALSA applicatio
ii libaudiofile00.2.6-8 Open-source version of SGI's audio
ii libavcodec52 4:0.5+svn20090706-5 ffmpeg codec library
ii libavformat524:0.5+svn20090706-5 ffmpeg file format library
ii libavutil49 4:0.5+svn20090706-5 ffmpeg utility library
ii libc62.10.2-2GNU C Library: Shared libraries
ii libcue1 1.3.0-1 CUE Sheet Parser Library
ii libcurl3-gnutls 7.19.7-1Multi-protocol file transfer libra
ii libfaad2 2.7-4 freeware Advanced Audio Decoder -
ii libflac8 1.2.1-2+b1 Free Lossless Audio Codec - runtim
ii libgcc1 1:4.4.2-9 GCC support library
ii libglib2.0-0 2.22.4-1The GLib library of C routines
ii libid3tag0 0.15.1b-10 ID3 tag reading library from the M
ii libjack0 0.118+svn3796-2 JACK Audio Connection Kit (librari
ii libmad0 0.15.1b-4 MPEG audio decoder library
ii libmms0 0.4-2 MMS stream protocol library - shar
ii libmpcdec6 2:0.1~r453-1MusePack decoder - library
ii libogg0 1.1.4~dfsg-2Ogg bitstream library
ii libpulse00.9.21-1PulseAudio client libraries
ii libresid-builder0c2a 2.1.1-8 SID chip emulation class based on
ii libsamplerate0 0.1.7-3 Audio sample rate conversion libra
ii libshout32.2.2-5+b1 MP3/Ogg Vorbis broadcast streaming
ii libsidplay2 2.1.1-8 SID (MOS 6581) emulation library
ii libsqlite3-0 3.6.21-2SQLite 3 shared library
ii libstdc++6 4.4.2-9 The GNU Standard C++ Library v3
ii libvorbis0a 1.2.3-3 The Vorbis General Audio Compressi
ii libvorbisenc21.2.3-3 The Vorbis General Audio Compressi
ii libvorbisfile3 1.2.3-3 The Vorbis General Audio Compressi
ii libwavpack1 4.60.1-1an audio codec (lossy and lossless
mpd recommends no packages.
Versions of packages mpd suggests:
ii avahi-daemon 0.6.25-3 Avahi mDNS/DNS-SD daemon
ii gmpc [mpd-client] 0.19.1-1 Gnome Music Player Client (graphic
pn icecast2 none (no description available)
ii mpdscribble [mpd-client] 0.19-1 Last.fm reporting client for mpd
pn pulseaudionone
