Find the answer to your Linux question:
Page 1 of 3 1 2 3 LastLast
Results 1 to 10 of 29
Obviously the audio part of the Linux is the worst part of the entire system. I'm trying to have a real audio experience on Linux since 4 years, but I ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Linux Enthusiast minthaka's Avatar
    Join Date
    May 2006
    Location
    Mol, Vojvodina
    Posts
    556

    Thumbs down Linux Audio Disaster


    Obviously the audio part of the Linux is the worst part of the entire system.
    I'm trying to have a real audio experience on Linux since 4 years, but I think that day will never dawn. Why there's no possibility to have an all in one kernel for all purposes? I'm using a wide range of applications. My favorite would be Ardour. But it is based on a farting called jack. I had to see how people are putting their efforts into developing something like PulseAudio, which is 0% needed and useful and at the same time leaving xruns from kernels untouched. I'm getting convinced that a Linux kernel is the worst piece of software ever written. I love Linux, but how on earth can it happen, that a crippled OS like Windows has a perfect audio system, with no real-time issues, no overruns, and other ********s so characteristic for Linux. What is the point in monolithic kernel, if we have to bow before the PC if its audio system works normally? Can somebody explain me why is audio so bad?
    Please, don't tell me "You should use UbuntuStudio, ..." for audio purposes. This answer is simply not acceptable. Should I install for each task a separate OS?
    A Linux for graphics, another for music creation, a third one for office...
    I even would help develop some applications, but it seems to me, that the kernel itself is sick. Any Linux audio professional here?

    Intel Celeron-D 2.66 GHz
    1.5 GB RAM
    Audigy 2

    That would make rock'n roll on Windows!
    If you need a CD/DVD catalogizer, give a try to my program:
    http://www.kde-apps.org/content/show...content=100682
    Linux Usert#430188

  2. #2
    Linux Guru coopstah13's Avatar
    Join Date
    Nov 2007
    Location
    NH, USA
    Posts
    3,149
    Hardware vendors who know the specifications of their hardware put out the driver for windows, which is why it works so well. They leave it up to us to figure it out for linux.

  3. #3
    Linux Newbie
    Join Date
    Nov 2007
    Location
    Planet Earth
    Posts
    152
    Free Software World: If something don't like to you, there are two options (1) help to improve it or (2) don't use it ... If you say that you can help with some hacks, you're welcome.
    EOF

  4. #4
    Just Joined!
    Join Date
    Jun 2008
    Location
    Juneau AK
    Posts
    8
    It sounds like the problem is not whether these applications *can* work flawlessly on Linux, but it's more a question of whether they *do* by default. If you were manning a professional studio, you would be either:
    A) Invest your money in proprietary products based on Mac or Windows.
    B) Invest your money in a consultant or support company to configure a production machine running Linux and Open Source & free software. This person (or company) would start with hardware that is well supported by Linux, and likely compile a custom Kernel with a real-time patch.
    C) Invest your time in accomplishing B by yourself.
    D) Wait until people who are doing B and C to release the fruits of their efforts to the FOSS community.

    I think people who complain about FOSS don't have any right to be using it, because they aren't contributing anything helpful to the community of developers who make it better.

    I personally think Jack is a superior application to the Mac and Windows low latency solutions. I am using Debian Lenny on a PPC (ibook G4), 1G RAM, 1.33GHz processor. With stock Debian Kernel, I can get less than 5ms latency without Xruns. I only get Xruns when I'm trying to do too much at once, particularly with gui applications. This principle is true regardless of the operating system.

    What you say is true, that by default, Linux is not an optimal Realtime operating system. As time goes on, I speculate real-time capability may be built into a stock distribution kernel, but doing this is much larger than satisfying a few disgruntled audio users. The same OS is the foundation of many enterprise servers. Kernel hacks are not acceptable defaults.

    The postitive side of Linux is that you, the user, have full control to apply your own kernel patches, and configure the system for a very specialized purpose with performance that exceeds that of the proprietary counterpart.

    However, this level of configuration requires a lot of time and/or a lot of money, so it's not free as in free beer, but very much free as in freedom.

    This is just my 2 cents. I am no kernel expert, and more a dabbler in Linux and computing.

    I happen to be guitarist/hobbyist and find Linux to be excellent for my needs. I have read news posts and such about Linux being a success for professionals, but have no personal experience in the professional music industry. Please weigh my comments with that disclaimer

  5. #5
    Just Joined!
    Join Date
    Oct 2009
    Posts
    17
    Hardware vendors who know the specifications of their hardware put out the driver for windows, which is why it works so well. They leave it up to us to figure it out for linux.
    Just an idea. If drivers are the main problem, maybe what's needed is a wrapper for Windows drivers in Linux?

  6. #6
    Linux Enthusiast minthaka's Avatar
    Join Date
    May 2006
    Location
    Mol, Vojvodina
    Posts
    556
    I don't think the problem is with the soundcard's drivers. The basic conception of Linux Audio is a failure. If I knew how Windows audio is projected, I'd start cloning it to Linux at the same moment. Jack, PulseAudio, all these are lame patches of something that should be called as audio system. In my opinion, an audio system:
    1. Should be able to gain low-latency without any voodoo tricks, any servers and all the bastards.
    2. Should be easy to use: turn it on and it simply works.
    3. Should spare system's resources: if I could reach 12 stereo tracks without clicks, xruns and all the impossibilities, on WinXP with my Audigy2 + 512MB+2.66GHzCPU, why can I have at least the same thing with Audigy2 + 1.5GB+2.66GHzCPU on Linux?
    4. Should everything be included in ONE normal kernel: the Window's kerne must be done very well, much more better than its Linux counterparts, if it is good for everything. Window's weakness is it's principle of registries, but as kernel, it's a starship Enterprise!
    I'm calling all the Linux audio developers to rethink their concepts!
    If you need a CD/DVD catalogizer, give a try to my program:
    http://www.kde-apps.org/content/show...content=100682
    Linux Usert#430188

  7. #7
    Just Joined!
    Join Date
    Oct 2009
    Posts
    17
    As a potential target user of Linux music distros I agree with your points 1 through 4. A UNIX kernel itself is a viable host for audio; the music industry's mainstay, (Mac) OSX is based upon the Mach kernel, with certain parts from FreeBSD's and NetBSD's UNIX implementation in a POSIX compliant core. My hunch says, if you peak under XP/Win7's hood real good past the Microsoft smoke (and mirrors), you'll probably also discover a similar UNIX core. So a UNIX core itself works, it's just what gets piled on top of it.

    Apple, which could have coded anything it wanted into OSX did not include JACK even though an OSX implementation is avaiable at jackosx.com. Having dealt with JACK on nearly dozen of Linux distros by now, I can say Apple was right. The pro music industry is doing real fine without JACK's current incarnation. You want to route audio from app to app in OSX or Windows? Here's the four steps to it with ReWire: 1. select any track in source app, 2. click menu which other app to send it to, 3. select any track in destination app, 4. pick the source from menu. Done! There 's none of this 'start ALSA and JACK manually, check a screenful of parameters in JACK, click Connect, click Add for every source and destination, draw Bezier curves between modules to be connected, watch for xruns, broken pipes, add the Challenger's lubar orbit in hex...' stuff. Yeah, sure you can get 5ms latency with JACK instead of OSX's 10. Who cares? So far, only a single person on Earth. And it's not me.

    Of course, (let's follow this thread to the end too...) if thousands of Linux volunteers, through blood, sweat and tears do transform JACK into something practical and elegant one day - then Apple will grandly include it in OSX. And Microsoft will copy it from Apple. And they'll both boast how inventive they are. And Linux users, saddled with the next non-working musical innovation by then, will post angry questions, why *that* is a failure. This is how Apple and Microsoft implemented the latest R&D cost-cutting measure: they simply outsourced R&D to Linux. A brilliant business tactic. Lure millions to a semi-functional free OS, let them fix and innovate all they can, copy successful results for free, (long live the common UNIX core!) and sell them to own user base for money. Why outsource research to India for cents an hour, if you can outsource to the whole world for free through Linux? If I'm wrong, why is the gist of Linux coding efforts so deftly channeled into JACK, PulseAudio and similar high-flight audio esoterica benefiting more audio-savvy OSX and Windows potentially (if they succeed) than writing a badly needed decent basic Linux audio/MIDI implementation, a "Linux CoreMIDI and CoreAudio" to cover the Linux community's own need?

  8. #8
    Just Joined!
    Join Date
    Jan 2010
    Posts
    3
    Quote Originally Posted by mrdelurk View Post
    Apple, which could have coded anything it wanted into OSX did not include JACK even though an OSX implementation is avaiable at jackosx.com. Having dealt with JACK on nearly dozen of Linux distros by now, I can say Apple was right.
    Apple does not include ASIO, Rewire or Soundflower either, so that means nothing. Coreaudio is the default sound server on a fresh OSX install.

    The pro music industry is doing real fine without JACK's current incarnation. You want to route audio from app to app in OSX or Windows? Here's the four steps to it with ReWire: 1. select any track in source app, 2. click menu which other app to send it to, 3. select any track in destination app, 4. pick the source from menu. Done!
    That won't work half the time in Rewire, as audio can only travel one way, from a client app to a server app. Most of the time it will not work at all, as client apps cannot Rewire to each other. Also, you have to start the apps in the right order and there is no session management etc. This is why Rewire is little used outside of using one application as a 'plugin' in one single server application. This is what it is intended for, and it does it fine, but it's not an equivalent to Jack.

    There 's none of this 'start ALSA and JACK manually, check a screenful of parameters in JACK, click Connect, click Add for every source and destination, draw Bezier curves between modules to be connected, watch for xruns, broken pipes, add the Challenger's lubar orbit in hex...' stuff. Yeah, sure you can get 5ms latency with JACK instead of OSX's 10. Who cares? So far, only a single person on Earth. And it's not me.
    Here's the two steps to do it with Ardour and Jack: 1 Click on a tracks input. 2 Select the output from the other app.

    Of course, (let's follow this thread to the end too...) if thousands of Linux volunteers, through blood, sweat and tears do transform JACK into something practical and elegant one day - then Apple will grandly include it in OSX. And Microsoft will copy it from Apple. And they'll both boast how inventive they are.
    Apple has coreaudio, which combined with apps like Soundflower, is it's version of Jack. Windows has no equivalent, but people manage to get it working by installing third party applications/drivers like Rewire and ASIO, Virtual audio cable, ASIO4ALL, FXT etc.

    If I'm wrong, why is the gist of Linux coding efforts so deftly channeled into JACK, PulseAudio and similar high-flight audio esoterica benefiting more audio-savvy OSX and Windows potentially (if they succeed) than writing a badly needed decent basic Linux audio/MIDI implementation, a "Linux CoreMIDI and CoreAudio" to cover the Linux community's own need?
    Pulseaudio is the equivalent of the Windows sound mixing/implementation (MME/DIRECTX/KMIX etc). It works, but like the built in Windows version, it is not suitable for professional use. Larger latencies, hidden sample rate conversion and bit depth reduction are acceptable and hidden from the user. This is what most people who are not recording music want.

    Jack is the equivalent of ASIO+Rewire+coreaudio+Soundflower. It is sample accurate, synchronous and suitable for professional use. There is no hidden sample rate conversion or bit depth reduction. This is what people who are recording music professionally want.

    I hope that clears things up a little.

  9. #9
    Just Joined!
    Join Date
    Oct 2009
    Posts
    17
    Quote Originally Posted by argosy View Post
    Apple does not include ASIO, Rewire or Soundflower either, so that means nothing. Coreaudio is the default sound server on a fresh OSX install.
    It means, ASIO, Rewire or Soundflower weren't in a major demand, either. If Apple's focus group (made by pro audio users) wanted these, the code would have made it into CoreAudio. It didn't. If ReWire stopped working in my studio, I probably wouldn't even notice for half a year. Would I want now something 12x more complicated, like JACK? If it installed and ran as transparently as ReWire, it'd probably end up here (like every other music product in the universe seem to... but I'd hardly loose much sleep over whether I have it or not.

    Pursuing such an esoteric audio routing capability, while even basic MIDI failed to work reliably on 18 of 20 tested music distros is a bit like building a star observatory wearing pants from which one's butt shows naked, IMHO. Basic necessities should precede space travel.

  10. #10
    Just Joined!
    Join Date
    Jan 2010
    Posts
    3
    Quote Originally Posted by mrdelurk View Post
    It means, ASIO, Rewire or Soundflower weren't in a major demand, either. If Apple's focus group (made by pro audio users) wanted these, the code would have made it into CoreAudio. It didn't.
    No, they are not in major demand, and Coreaudio is fine for most everyday applications out of the box. With Linux, only very few people use it as a DAW, so sadly Jack is not installed by default.

    If ReWire stopped working in my studio, I probably wouldn't even notice for half a year.
    Jack is a somewhat more fundamental system component than Rewire. As well as doing inter-application communication, it also talks to the sound card, sets the sample rate, bit depth and buffer size etc.

    So, it's really doing the jobs of Coreaudio and Rewire at the same time. You'd notice if it was not working as most audio apps would have no sound at all.

    Would I want now something 12x more complicated, like JACK?
    Jack is not really much more complex to use. It is as hard to configure as setting the audio preferences in any professional Windows DAW, and you only need to do it once.

    That said... You need to install and start it at the moment, which is harder than OSX. It is a dependency of most audio apps though, so a package manager will install it automatically at the same time. There is room for improvement here, as Jack would be better run on boot as a daemon, as opposed to clicking 'start' in Qjackctl.

    If it installed and ran as transparently as ReWire, it'd probably end up here (like every other music product in the universe seem to... but I'd hardly loose much sleep over whether I have it or not.

    Pursuing such an esoteric audio routing capability, while even basic MIDI failed to work reliably on 18 of 20 tested music distros is a bit like building a star observatory in a pant with one's butt showing naked, IMHO. Basic necessities should come before space travel.
    I don't think Jack was created to just do the routing. There are a number of problems it solves for Linux audio, one being that it simplifies writing audio apps.

    In systems where features like routing have been added later as patches (ReWire,Soundflower), routing is seen as something esoteric. This is because it is generally semi functional, with weird limitations you have to remember, and difficult to configure. If it's built in from the start though, then it can be quite transparent.

Page 1 of 3 1 2 3 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •