[Pkg-alsa-devel] Bug#709106: Bug#709106: [alsa-utils] speaker-test, aplay fail cryptically ("unable to open slave")

Filipus Klutiero chealer at gmail.com
Tue May 28 02:57:02 UTC 2013


On 2013-05-27 05:24, Elimar Riesebieter wrote:
> * Filipus Klutiero<chealer at gmail.com>  [2013-05-26 18:02 -0400]:
>
>> reopen 709106
>> thanks
>>
>> Hi Elimar,
> [...]
>
>> A bug report should only be closed when the bug has been resolved.
> To be honest, which bug? I cant figure out a bug in alsa-utils.

speaker-test should either test speakers or explain that this is not possible. Without the previously mentioned workaround, it does neither here. It rather fails with obscure errors, which is certainly a bug. As I said, other programs work well, which makes me think this bug belongs to alsa-utils. However, as I said, alsa-utils programs are not the only ones to display this problem, which makes me think that this bug belongs to software supporting alsa-utils. I suspect alsa-utils is at fault anyway, but I am not an expert, the only thing I know for sure is that something is broken. I do not know how alsa-utils interacts with lower-level software and am not in a position to report the problem if it is lies there, but it might be that the only thing alsa-utils maintainers can do is to reassign the ticket explaining what the fundamental problem is.
>
> [...]
>> In this case, there are apparently 2 ways to make progress:
>>
>> 1. If, as your reply implies, the chip is not supported, support
>> can be introduced.
> As an experienced Open Source user you must know that package
> mainatiners are not responsible for writíng new drivers. You must
> ask alsa-devel when and in which kernel version the mentioned chip
> will be supported. I can support you if you let me know which chip
> type is affected. I can then give you some hints on how to ask
> alsa-devel when support will be available. As it is a driver problem
> we can reassign "your bug" to Debian kernel package as a whishlist
> item but that won't force the development of a driver.

I haven't requested anyone to write a driver. I suggested point 1 because you apparently didn't know how to change the default chip. But 1. is just one possible way of fixing this. I assume changing the default would be much easier.
>
>> 2. In my case, where the problematic chip is
>> not the only one and another chip works fine, another chip can be
>> made the default.
> How to do that is briefly described in the Debian documentaion of
> the alsa-base package which was pointed out 2 times in the past.
The default chip in question here is the one in a default install. What the documentation describes is what I was forced to do in my install.

-- 
Filipus Klutiero
http://www.philippecloutier.com



More information about the Pkg-alsa-devel mailing list