Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
|
| |||||||||||
Not my desktop.Not my desktop.Posted Dec 16, 2006 0:12 UTC (Sat) by AJWM (subscriber, #15888)In reply to: Not my desktop. by sjj Parent article: Linux desktop architects map out plans for 2007 (Linux.com)
> Which proprietary Unix is used as a desktop workstation today?
Arguably, MacOS-X. (Sure, based on BSD, but it isn't BSD.)
Not to take away from your main point, though.
(Log in to post comments)
Not my desktop. Posted Dec 16, 2006 1:11 UTC (Sat) by sjj (guest, #2020) [Link] Yes, but Apple will most likely do their own thing. Not that I actually know what their sound system is based on.
I do have some fresh scars from wrestling with sound on Linux, as I'm trying to revive music making as a hobby...
But I'd also like to thank everybody who works on this stuff. It really is getting better all the time. Thanks!
Not my desktop. Posted Dec 16, 2006 11:21 UTC (Sat) by drag (subscriber, #31333) [Link] How sound works in Windows is that you have the standard win32 api with kmix software mixer. The drivers take care of setting the hardware devices and mapping them to the stardard (and rather limited) mixer controls and options that are aviable to Windows users.
This is nice because it abstracts away the differences in sound cards so that users are presented by something that is completely standard and familar.
This is bad because it makes the default Windows audio system worthless for audio production. People selling audio cards for professional use and people selling audio production software had to come up with their own sound API for windows to bypass all the kmix stuff and that turned into the ASIO drivers from Steinburg.
----
So the buggery thing about Alsa and such is that it's designed to already allow low-level direct access to sound systems. It has the advantage of the asoundrc and plugins architecture to make it more flexible, but for the end user this is just additional complexity which is not well documented and even harder to deal with.
So you get all this confusion over doing basic mixer controls and setting up just regular desktop recording because it depends on what sound card your using... Each sound card demands a unique setup.
This makes it very difficult to develop documentation and directions and default GUI controls.
I think that if the sound desktop architectures want something then they are going to have to agree on a sound server, so that
I vote for PulseAudio.
I like Jackd, but it's designed specificly for audio production. It should concetrate on that. What your going to end up with if you standardize around jack is a similar situation to Alsa. It's to geared towards sound people and normal people are going to have a tough time dealing with it. Plus normal applications and games don't interface with it. It's something that programs have to specificly adapted to use.
Pulseaudio on the other hand is designed specificly for desktop use. It has a number of attractive features:
This means that you have no ackward wrapper scripts for the majority of Linux audio applications, like you had to do with artsd. (you need one for oss compat) No need to reprogram libraries or applications to use it and gain the nice following features...
- Network transparency for X terminals.
- Jack module for tying pulseaudio into a jack daemon. This can allow audio professionals flexible choices in playback applications and being able to route sound from normal applications and games into their recordings.
See for more details:
BTW the pulseaudio is not new software. Many people may be familar with it's previous incarnation, which was Polypaudio, which itself was designed to solve the limitations presented by esound.
of course the nice thing about it from my perspective is that it's already aviable on my Debian setup.
|
|||||||||||