On Wed, Mar 26, 2008 at 12:13 PM, Janina Sajka <janina(a)rednote.net> wrote:
We really need something more friendly than that steady state sine
wave
for
this test sound. We also need more understandable device designations,
imho. It's just not very consumer friendly as it stands.
I'm not arguing that its optimal.. but my point is... its meets the
requirements for hardware testing. I'm really not sure why it needs to be
something other than a tone for testing, but I'm not going to argue against
it.
So far its been a much better interface for me to test individual devices
when I needed to, alsa,oss,pulse layers are all exposed seperately. The
detected hardware is exposed separately. From a troubleshooting pov it
helps me narrow down problems much more precisely than s-c-soundcard.
I'd rather see the pref dialog enhanced to play a pleasant sound or to do
things like stereo speaker testing...than continue to see s-c-soundcard held
on to for pretty trivial enhancements.
It's nice having the capibility to direct audio by application class,
but I'd still like more control, myself. I'd like to be able to direct
audio application byh application--I have four audio devices on one
system and three on another--but I still have no finite control of what
device my Orca plus Espeak will use. I make great use of these kinds of
arguments in the cli, and I'm frustrated when apps (like timidity) don't
support specific direction.
This is beyond the issue of whether or not s-c-soundcard still has any
relevance at all compared to functionality exposed elsewhere. This issue at
hand is whether or not we can nuke s-c-soundcard as a codebase. I think we
can.
-jef