Linux Audio Development
JulesVD writes "There is an article from Linux Journal about the latest plans for Linux audio functionality from the first developer's conference in Germany. Developers from more than a dozen countries attended this successful conference, representing organizations such as SuSE, Linux Audio Systems, Stanford University, IRCAM and Centro Tempo Reale. Topic discussions included in-depth presentations of the rapidly evolving Linux sound system, a look at the details of programming for professional audio standards and a survey of recent applications and audio-centric Linux distributions." Mmm...interesting reading (blantant plug for cool program), but I think the most important question is will it make Scrubby happy?
The only company that I know is producing commerical drivers for linux is 4Front Technologies. No idea on the quality though
Rus
Cheap UK and US VPS
Isn't the largest issue with any support on Linux still the fact that very few companies are willing to put in the time to create Linux drivers let alone have have the decency to release the information on the chipsets to the public to allow 3rd party drivers to be created?
It's not like they're jerks about it. They dont make money from drivers, after all, so it's really in their best interests to create linux drivers.
But here's the rub.
#1) Releasing specs on chips like the EMU101k (for example) hurts their market position. That stuff is trade secrets, and patents and whatnot. nVidia doesnt just give out schematics for their new FX chips, after all. Nor does creative (or whomever) want to hand out their fancy-dancy sound chips.
#2) Creating drivers for linux is different from say, windows. To do so for windows, you get the Windows DDK (driver development kit), and create your driver. You need not interact with MSFT, unless you want the drivers signed when finished. There are rules set up for a windows driver, specs and all that. It's basically a matter of filling in the gaps with your code.
Contrast with the monolithic kernel that linux has. Creative would need to participate and coordinate with linus et al from start to finish. It's all still uncharted waters, largely, and just takes more man hours, and more expensive hours, as they pay higher-up engineers to deal with the whole thing.
If the linux kernel crew can nail down a 'spec' of sorts for drivers, and not require hardware manufacturers to deal with the kernel hackers to get their stuff directly supported, then they'd have no problem at all churning out a linux driver.
In short, the monolithic kernel is an albatross around linux' neck when it comes to wanting hardware support from the manufacturers.
I don't need no instructions to know how to rock!!!!
Contrast with the monolithic kernel that linux has. Creative would need to participate and coordinate with linus et al from start to finish.
Erh no! Most, if not all drivers in ALSA were written without any interaction from the kernel folks. ALSA is now integrated in the 2.5.x kernel, but that doesn't mean driver developers will have to deal with Linus et al. They just deal with Jaroslav, the ALSA maintainer. All mainstream cards are already supported by ALSA. If a company doesn't want to provide docs it can always choose to write and distribute their driver on their own.
In short, the monolithic kernel is an albatross around linux' neck when it comes to wanting hardware support from the manufacturers.
Nonsense.
-adnans
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
That's a good conspiracy theory. Another theory is that linux cant dynamically add/remove display devices in userland at run time the way windows can.
You'd either have TV out enabled all the time, or CRT all the time, or both, but you wouldnt be able to switch at will.
It could also be because of the MODELINE nonsense in your xf89config. TV out has some pretty specific frequency requirements, and perhaps the ability to tweak those while enabled would damage the card, and then void the warranty - but if you voided the warranty with a matrox driver, you dont void the warranty, so they have to continually replace cards for all the 'tweakers' out there.
Or it could be that you're looking a gift horse in the mouth. Want all the features of the vid card to work? Fire up emacs and get a-crackin'.
BTW, IIRC macrovision is a hardware feature, not a software one. There is no 'linux support' to be written, save flipping it on via a hardware register. They're only required that it be present, it can be disabled as easily under windows (a registry tweak for most cards) as it could be under linux.
I don't need no instructions to know how to rock!!!!
-Simon
Conversion Rate Optimisation French / English consultant
And ALSA is the way every card will work from now on? Or will it change to something else with kernel 2.6?
:-).
The ALSA API in kernel 2.5.x will be the same one in kernel 2.6.
Vendors like standards and specifications. They dont like researchers and academics and expiriments.
Vendors look at the bottom line. If there's enough incentive they will write against any API (*cough* Windows *cough*
-adnans
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
If anyone knows about any open source Sequencer with planned VST support, let me know, I would love to help. I searched Sourceforge for Linux VST.. and found nothing.
i s-month/0020.html
http://boudicca.tux.org/hypermail/jackit-devel/th
Google around for details...
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
0x0d0a (568518) wrote:
> ALSA's biggest drawback is the project policy that software mixing should be done in userspace (presumably by a separate project).
Since 0.9.1 ALSA can do mixing itself, with the so called dmix-plugin. You can throw away soundservers now, except of course JACK which is a lot more than a simple mixing sound server.
-- fbar
LSA's biggest drawback is the project policy that software mixing should be done in userspace (presumably by a separate project)
This just is not true. ALSA now has the dmix plugin that handles software mixing in user space all by itself. Its very, very efficient and has no impact on latency (though it can't offer JACK-style sample-synchronous execution). dmix makes regular software mixing "servers" irrelevant, and JACK fills the remaining needs.
Not only do they create drivers for their chips (SBLive! and Audigy series, OpenAL), they release the code as Open Source. The driver sin the Linux kernel came from Creative, not some 3rd party. Another reason to support Creative (as if having the best stuff wasn't enough of a reason)
http://opensource.creative.com
CoolEdit 2000 - great all-round mono/stereo editor
CoolEdit pro v2 - very good multitrack audio editor
http://www.syntrillium.com
Sound Forge
Vegas
http://www.sonicfoundry.com/
nTrack - surprisingly good multitrack editor for $60. I like it.
http://www.ntrack.com
SAWStudio - if you're really pro and want the leading edge plus ultra stability. $1200 to $2500. It's not for kids.
http://www.sawstudio.com/
The previous SAW product (SAWPro) is discontinued, but solid as a brick if you can find it.
No, they are no longer available, and haven't been for a while either.
The SoundBlaster Live is an example of a cheap soundcard that does hardware mixing.
ASIO is a Windows specific hack around the lack of low latency audio on that OS I think, so it doesn't apply to Linux/ALSA which has some of the lowest latencies around with the right kernel patches.
If you want to develop audio applications for Linux please join the linux-audio-dev mailing list
If you are an user of audio applications for Linux please join the linux-audio-user mailing list
A guy called Austin Acton has put together the Mandrake Audio Workstation HowTo for Mandrake 9.1.
It uses packages contributed to Mandrake 9.1 to build an audio workstation (including a low-latency "multimedia" kernel) - using URPMI to simplify package dependency issues.
Quote from the HowTo: "You can setup a professional quality audio workstation in an afternoon or less, with Mandrake Linux. No compiling. No text editing. No dependencies. It's this easy.".
I don't know enough about computer audio to comment further, but you might be interested in checking it out.
I can do TV out on a plain vanilla Geforce 2MX 400 - no TV out at all. The RGB cable is simple - just connect the VGA RGB to the SCART RGB then mix the HSync and VSync signals and feed them into the SCART composite in.
There is a special modeline you need, which puts it into a 704x256 mode (really!) scanning at the required 25Hz. It would be pretty simple to adapt this for 30Hz for USian TVs.
As for switching modes on-the-fly, this has been possible for a very, very long time. Try pressing to switch modes...
I ran into this same problem often with Ardour and others. I gave up, and installed Gentoo. Although it takes a bit of "geek eliteness" to get Gentoo installed (knowing how to compile a kernel, mount filesystems, work with Grub, etc.), it's worth the effort.
Once Gentoo is installed, installing Ardour is a one-liner:
# ACCEPT_KEYWORDS="~x86" emerge ardour-cvs
If your system is slower than 1GHz, check on it every few hours. You needn't do much else while it builds Ardour and all the dependencies to get there. I recommend starting this right before you go to bed, by morning it might be done. Gentoo is a bit like baking a turkey. Yeah, it takes a very long time to cook, but if you took the time to prepare it right, the result is beautiful and tasty. Unless, of course, you're a vegetarian...
That's really what it broiled down to with me. I'm far more patient with allowing stuff to build automatically over hours/days and not using my main PC (lucky me, I have three) for hours/days than with sitting in front of the console for hours working out dependencies by hand.
Matthew P. Barnson
I learn what I think when I read what I write