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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
