[Pkg-alsa-devel] Bug#305189: gstreamer0.8-alsa: ALSA plugin isn't working

[Loïc Minier]

reassign 305189 libasound2
retitle 305189 [VIA 8237 with ALC850] doesn't offer a working "default"
thanks

        Hi,

On Tue, May 10, 2005, Anders Boström wrote:
> But why isn't alsasink working with the default alsa configuration?
> All other alsa applications I've tested work fine with the default
> config.

 This is an ALSA bug, there are ways to work around it -- which other
 applications do -- but it's best to solve it at the ALSA level.

 The following gets technical.

 The ALSA API is split in a number of sub-APIs, the problematic API here
 is the PCM API which is available at:
    <http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html>

 From a discussion with GStreamer maintainers, a first class of problems
 concerns this API and seems to be the following:
 - ALSA offers application writers some guarantee that a special ALSA
   device named "default" exists and works
 - sometimes, I presume for some ALSA modules / drivers, the "default"
   devices either doesn't exists or doesn't work
 - a workaround is to try the ALSA device named "hw:0" (which refers to
   the first sound card), this is ugly as ALSA is always offering a
   "default" which should be used; GStreamer folks don't want to
   implement that workaround in the alsasink plugin, but you saw it is
   possible to force the ALSA device yourself as an alsasink parameter
 - another workaround is to change the user or system configuration so
   that "default" is "hw:0", this is what the .asoundrc snipset I gave
   you does

 From the same discussion with GStreamer maintainers, a second class of
 problems appears with respect to a second API, the control API which is
 available at:
    <http://www.alsa-project.org/alsa-doc/alsa-lib/control_8c.html>

 In this case, the problem seems to be the following (you're not
 experiencing this problem):
 - ALSA offers application writers a mean of retrieving information on a
   PCM device
 - GStreamer can adapt an input stream to a set of output capabilities
   if necessary, but if for example the PCM device seems to accept
   anything, GStreamer doesn't adapt the stream
 - in some cases, I presume for some modules / drivers, ALSA reports
   that the PCM device supports all kinf od streams while it doesn't,
   and this leads to a failure
 - a workaround is to try to change the format after failure, but
   GStreamer folks don't want to do this


 I'm reassigning this bug to libasound2, the ALSA library.  I hope
 information about your hardware will be enough to diagnose this problem
 further.

   Regards,

-- 
Loïc Minier <lool at dooz.org>
"Neutral President: I have no strong feelings one way or the other."