<div class="gmail_quote">On Wed, Mar 26, 2008 at 12:13 PM, Janina Sajka <<a href="mailto:janina@rednote.net">janina@rednote.net</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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. </blockquote><div> 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. </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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. </blockquote></div> 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