Bug#578720: vorbis-tools: Sends invalid argument to ALSA when playing some files

[Martin Steghöfer]

Hi Ron!

Thank you for your quick and comprehensive answer! :-)

Unfortunately, I think I should have pasted more information into my 
previous mail. Most of your answer tries to argue away a point that I 
actually already ruled out in a message I posted earlier to this bug 
report: It looks like we both agree that doing the upmixing is out of 
the scope of both ogg123 and libao. I didn't suggest to do that. I 
thought the snippet I pasted into my message to you made that clear. But 
apparently it didn't, I'm sorry for not having made that more clear and 
therefore having wasted your time. I have a very compact way of writing 
things, but I try to be more verbose this time.

After upmixing is ruled out, the only thing left is to (maybe) improve 
the error message, if that's possible.

In ogg123 we don't have the information that would be necessary in order 
to tell what's going on. The only thing ogg123 knows is that for some 
reason the ALSA output couldn't be opened. And that's what ogg123 
reports to the user ("Error: Cannot open device alsa."). I don't see any 
way to improve this.

So, if anything, we can only improve the *other* message. And that one 
"comes" from ALSA (the error code and its translation into a string) and 
is "emitted" (converted to string, composed and printed) by libao, like 
I tried to explain in my previous message:

>> The string "invalid argument" comes from ALSA ("snd_strerror")
>> and it's printed by libao (in "ao_plugin_open"). So either of
>> them could improve the wording.

Since you were doubting this...

> The second to last line appears to have come from alsa-lib itself,
> I don't see anything in libao that would emit that.

...let me be more specific: The line in which libao emits this is 
located in ao_alsa09.c:391 in version 0.8.8 (which is the one the bug 
reporter used). In the most recent version (1.1.0) a similar output 
would be emitted by ao_alsa.c:521.

> It [the error message] might be a little counter-intuitive
> until you realise some hardware simply can't handle mono output

Exactly, *that* is the (only) point where I see potential for 
improvement. The function name "snd_pcm_hw_params_set_channels" probably 
doesn't mean much to the user. And "invalid parameters" sounds more like 
an internal software problem (one of those illegal function parameters 
that you try to detect with assertions) than like a lack of hardware 
features.

> but it's not clear to me that anything
> above the level of alsa-lib can really
> second-guess (or report) why it
> failed in any more detailed way.

Not clear to me, either. That's why I'm coming to you because you know 
libao better. An idea from my side: libao *can* know what's going on by 
combining the following information: The fact that the error happened, 
when setting the output device parameters, and the return code (an 
integer value that means "invalid parameters"). The information in 
"internal->cmd" could even tell *which* parameter couldn't be set (in 
this case the number of channels).

I'm not saying that anything *has* to be done, neither am I saying that 
libao is the right place to do say. I'm just saying that *if* we want to 
do anything to improve this, the only places that occur to me for doing 
this in a reasonable way are libao or ALSA. That's why I came to you, to 
hear your opinion, if you think this should be done in libao, in ALSA or 
not at all.

> So sorry, I don't really see an easy out that just lets you punt this
> one to someone else :)

I wasn't trying to. This is not about *who* does things (I'd be glad to 
contribute, be the "issue" in vorbis-tools or in libao; reassigning 
doesn't mean that I'm out), but *where* things are done. Since it was 
clear to me that the issue couldn't be helped in vorbis-tools, instead 
of just closing the issue I tried a final shot: Searching an external 
place, where the issue might be mitigated. And I still see a slight 
chance for this to happen in libao.

Thank you for your help! :-)

Cheers,
Martin