This was solved once already
This was solved once already
Posted Apr 29, 2009 23:24 UTC (Wed) by ikm (guest, #493)In reply to: This was solved once already by jmitchel
Parent article: Can you hear me now?
I think the root of the problem is in Alsa. It doesn't try to differentiate between different types of controls. Whoever was designing this haven't thought that through, I guess. And also the fact that driver writers don't all eat the same dog food -- if you develop a driver under Windows, you've got that mixer app already and you'll surely check if it looks alright or not. Under Linux, well, no UI's a standard. I think it is some kind of a Linux immaturity stereotype -- there are always too many options, and no one's good enough. Or, returning to the initial topic: either have just one control, or whole hundreds of them. No middle options :)
Posted Apr 30, 2009 0:24 UTC (Thu)
by drag (guest, #31333)
[Link]
With Windows 2000/XP they introduced Kmix, which is a mixer for the Win32 sound system. Thus everything you do in Windows is software mixed, from the beginning. Then, I beleive, it's up to the sound card makers to provide their own applications and mixer controls for situations were they have features that can't be controlled via the bog-standard Windows stuff.
Which is why you end up with people bitching and moaning about creative drivers and their bloated apps and stuff in Windows. They need all that because the functionality they need are not provided for by the operating system.
And on top that you have huge latency issues and other things that affect Windows users. Similar to what people are running into with PulseAudio. (of course PA is not nearly as mature right now, as the Kmix stuff that was introduced with Windows NT-based desktops)
Of course for the needs of psuedo-professional purposes.. like doing high quality recordings, running low-latency recording, multiple I/O streams and such things.. then any sort of functionality provided for Windows is a complete wasteland.
The audio industry for the longest time stuck with Windows 9x systems and Mac OS systems due to the performance latency issues that newer versions of Windows introduced.. but since Microsoft is the dominate force in PCs and everybody uses them people eventually relented and created their own audio and driver stack for Windows XP called ASIO.
In order to use ASIO, of course, you need special hardware that supports is and you need to use special drivers. This, of course, conflicts with the normal operation of Windows audio.
All in all Windows audio in XP is quite a bit of a cluster-fsck. The only reason it works as well as it does is becuase of the huge amount of money and effort poured into it by the industry and individual card manufacturers providing their own sane default settings and so on and so forth.
The nice thing about Alsa is that it avoids all that stuff.. the drivers are suitable for high performance as well, with the addition and growing maturity of Pulse-Audio, is gaining usefulness as the desktop.
I know that the Windows interface may seem simple and attractive, but it's actually quite a bit more confusing then at first blush. Getting high quality mic results out of it is actually kinda confusing and can take a long time to get set just right.
Which is probably why Microsoft scrapped the whole thing for Vista.
Of course that is nothing compared to the current state of Linux audio confusion.. but what can you do?
----------------------------
Probably the most correct approach is a policy-driven or profile-driven way to setup the drivers.
Does the user want... Stereo out? Digital out to a receiver? 5.1 Surround sound? 7.1 surround sound? Quadraphonic sound? Ac3 or DTS pass-thru? etc etc.
The user selects the profile and the UI adjusts accordingly, hiding all the little weird tweaks that needs to be done on Alsa's low-level. Doing that will easily surpass what you can get in Windows in terms of user friendliness.
Having a 'Expert Mode' is just admitting failure and is a fundamentally broken design.. but it may be necessary for the time being.
What is ultimately needed is a 'sound card tweak database' that can be used to answer such questions as "What low-level settings on the card can lead to working digital output?" and "What low-level settings lead to the Mic being useful". Then tie that into udev or hal or devicekit or whatever then hell is going to be used to keep track of driver settings.
Of course the difficult part is gathering that sort of information...
This was solved once already
----------------------------