Bug#676167: WARN alsa: can't encode 0-bit Unknown or not applicable

[Bob Proulx]

I was very appreciative of the info in this bug when I hit this
problem too. I am not getting a segfault but I am seeing the warning
message.

$ play -q anything.wav
play WARN alsa: can't encode 0-bit Unknown or not applicable

The suggested workaround of adding "-t alsa" works but shouldn't be
needed.

$ play -q anything.wav -t alsa

Is there any clue as to the root cause of the problem?

Bob

[Ulrich Klauer]

Bob Proulx <b...@proulx.com>:

> Is there any clue as to the root cause of the problem?

Yes. If an audio driver is explicitly specified by the user (via the
AUDIODRIVER environment variable or the -t option), SoX will use this
and there's no problem. Otherwise, SoX will try possible drivers in
this (hard-wired) order: coreaudio (MacOS), pulseaudio, alsa,
waveaudio, sndio, oss, sunau, ao.

Previously (14.4.0-2), it was only checked whether the relevant format
driver was available (compiled in, or as a module). But it is very
much possible that a format, even though present in SoX, isn't
supported by the environment (OS or userland). This led to bug #664301
("insists on using pulseaudio even when not available").

14.4.0-3 tries to remedy this by opening a dummy output for each
format driver, and only choosing this driver if the open succeeded. As
it seems, though, not all format drivers can handle this dummy open.
Depending on which options are available, SoX will get down more or
less far on its list and hit different problems (or none).


Until someone gets around fixing the dummy-open for all drivers, we
should probably restrict the try-and-open method to pulseaudio.

Ulrich


--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Bob Proulx]

Ulrich Klauer wrote:
> Yes. If an audio driver is explicitly specified by the user (via the
> AUDIODRIVER environment variable or the -t option), SoX will use
> this and there's no problem. Otherwise, SoX will try possible
> drivers in this (hard-wired) order: coreaudio (MacOS), pulseaudio,
> alsa, waveaudio, sndio, oss, sunau, ao.

That list seems like a reasonable list. Although I don't know about
coreaudio it probably doesn't hurt. (shrug)

> Previously (14.4.0-2), it was only checked whether the relevant
> format driver was available (compiled in, or as a module). But it is
> very much possible that a format, even though present in SoX, isn't
> supported by the environment (OS or userland). This led to bug
> #664301 ("insists on using pulseaudio even when not available").

I may also be suffering from Bug#664301 then since I do not have
pulseaudio on my system. I removed it because it wasn't working
right.

> 14.4.0-3 tries to remedy this by opening a dummy output for each
> format driver, and only choosing this driver if the open succeeded.
> As it seems, though, not all format drivers can handle this dummy
> open. Depending on which options are available, SoX will get down
> more or less far on its list and hit different problems (or none).

Good information. Thank you for explaining this.

Opening what driver produces the "WARN alsa: can't encode 0-bit
Unknown or not applicable" message? By the above and my case it must
be either coreaudio or pulseaudio because alsa works fine and I do not
have pulseaudio installed.

> Until someone gets around fixing the dummy-open for all drivers, we
> should probably restrict the try-and-open method to pulseaudio.

Seems reasonable. Assuming that the dummy open of pulseaudio isn't
the producer of that warning message.

Thanks,
Bob

[Ulrich Klauer]

Bob Proulx <b...@proulx.com>:

> Although I don't know about
> coreaudio it probably doesn't hurt. (shrug)

No, it isn't supposed to be compiled in at all on platforms other than MacOS.

> Opening what driver produces the "WARN alsa: can't encode 0-bit
> Unknown or not applicable" message? By the above and my case it must
> be either coreaudio or pulseaudio because alsa works fine and I do not
> have pulseaudio installed.

It is alsa, I think. It gives this warning, but is identified as working nonetheless. It'd be interesting to know which driver causes the segfault on platforms without ALSA support; it might be alsa there too, or one of the following.

Ulrich

[Ulrich Klauer]

tags 676167 + patch
thanks

> It'd be interesting to know which driver causes the segfault on
> platforms without ALSA support; it might be alsa there too, or one
> of the following.

Apparently it is the oss format itself, which passes NULL to fileno().

I've attached a patch to replace the
01_default_audio_driver_fallback.patch file introduced in 14.4.0-3. It
restricts using the new try_device() to pulseaudio, where it seems to
work well and solves the original problem (bug #664301). It's not
ideal of course, as users of OSS still have to manually uninstall
libsox-fmt-alsa or set AUDIODRIVER.

Pascal, would you consider replacing the original patch with this one?

Ulrich

[Pascal Giard]

Wow, somehow that one went totally fell through.

I will surely do soon (hopefully this evening).

I'm currently working on moving to format 3.0 quilt but I'm facing few
issues still (will post about this on the upstream ML).
I'll probably just push a 14.4.0-5 with it (14.4.0-4 went to experimental).

Cheers,

-Pascal
--
Homepage (http://organact.mine.nu)
Debian GNU/Linux (http://www.debian.org)
COMunité/LACIME: École de technologie supérieure (http://www.comunite.ca)
Integrated Microsystems Laboratory: McGill (http://www.iml.ece.mcgill.ca)

[Ulrich Klauer]

Pascal Giard <evil...@gmail.com>:

> I'll probably just push a 14.4.0-5 with it (14.4.0-4 went to
> experimental).

The change is also in 14.4.1 (which will be out in two weeks' time), so a 14.4.0-5 isn't really necessary. Won't hurt either, of course.

Ulrich