Martin Stransky (stransky(a)redhat.com) said:
>The sound test failed when I had rhythmbox running.
Do you think it's a bug?
Depends. Opening up a gst pipleine to play the test sound may be
overkill.
>1) I'm supposed to pick a PCM device and know what the
difference is
> between:
>
> Intel 82801DB-ICH4
> Intel 82801DB-ICH4 - MIC ADC
> Intel 82801DB-ICH4 - MIC2 ADC
> Intel 82801DB-ICH4 - ADC2
> Intel 82801DB-ICH4 - IEC958
>
> intuitively? (Moreover, I'm asked to do this in two different places.)
These names depend on driver writer, if you don't know just use the
default. Optionally I can move it to some "advanced" settings.
What situations would someone logically wan to suggest a non-default?
Using SPDIF? Something else?
>3) How is the user supposed to know whether to use kudzu, /proc,
or HAL
> detection? Why are they even *given* a choice???
>
>I'm failing to see what sort of usage case this is solving. Surely this
>should all just work?
It's because:
kudzu detects only internal cards (kudzu doesn't detect USB cards well),
but it works even if you don't have loaded drivers. So you can reload
drivers for your card if something bad happens, you have ISA card and so on.
But this isn't something the user can fix, so why are we handling it here?
I guess my concern is, why are we giving the user a 'test if it works ->
ok, it didn't -> punt' algorithm? Generally, they would get the same
result if they started up their sound app and noticed it didn't work -
what specific cases is this tool able to fix for them?
>(I note we have a completely different Sound preference anyway,
which is
>somewhat simpler.)
I've never heard anything about "Sound preference", so if there is
something like that can I read it somewhere?
System->Prefereces->Sound under GNOME. KDE may have something else entirely.
Bill