[Pkg-pulseaudio-devel] Bug#486132: closed by CJ van den Berg <cj at vdbonline.com> (Re: Bug#486132: [pulseaudio] Pulseaudio: fails with dmix, idle devices and suspend-on-idle)

[brian m. carlson]

On Thu, Sep 04, 2008 at 12:02:39AM +0200, CJ van den Berg wrote:
>On Wed, Sep 03, 2008 at 09:25:16PM +0000, brian m. carlson wrote:
>> At the very least, you need to document this in README.Debian.  dmix is
>> the standard way to support multiple programs using ALSA, and if
>> pulseaudio is going to break otherwise working setups, then that needs
>> to be clearly documented.
>
>Pulseaudio explicitly disables dmix when opening ALSA devices. The only
>way to get pulseaudio to ever use dmix is to manually force it to by
>using a non-standard configuration. I don’t see any reason to explicitly
>document this one unusable configuration (of possibly many).

Because it's the obvious one.  Without pulseaudio, using dmix works for
all programs, whether they use plain ALSA or ESD (or artsd, or any of
the other myriad sound servers).  The fact that pulseaudio is meant to
be a replacement for ESD means that things that worked with ESD but
don't with pulseaudio need to be documented.

Another reason that dmix is the obvious option is because pulseaudio
monopolizes the sound card, meaning that programs that used to use ALSA
(and implicitly, dmix) stop working.

Adding one program on top of an already-working stack should not
necessitate changing the entire stack.  Unfortunately, upstream thinks
it should.  So you need to document that, or you need to fix it.  I'd
prefer the latter (because it's simple and correct), but you don't seem
eager to do that.

>> A bug is already opened about the 32-bitness issue.
>
>Great! So why are you re-opening this one then?

I'm reopening this bug because there's no documentation that an obvious
configuration is incorrect.  You can't simply say something is
unsupported without documenting that.  It's the first time that I've
ever heard that using dmix is not supported.  If there are
configurations that are incorrect, they must either fail immediately, or
be documented.  Neither happens now, so people end up with broken
configurations.

Also, upstream's solution also requires 32-bit versions of libpulse0 and
libasyncns0 on amd64, assuming that they can talk to a 64-bit daemon.
So you also need to do that, so that lib32asound2-plugins can link
against them.

So, in summary, either:

* pulseaudio needs to work nicely with dmix; or
* lib32pulse0, lib32asyncns0, and lib32asound2-plugins need to exist on
   amd64, as does documentation about the proper way to use pulseaudio
   with multiple ALSA-using packages.

My preference is for the former, but either is acceptable.  Feel free to
clone or retitle this bug as necessary to implement either solution.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-pulseaudio-devel/attachments/20080903/81f5a60b/attachment.pgp