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