the mixer interface is a problem. OSS glosses over this by hiding 90% of the capabilities of most hardware mixers and stuffing it into an incredibly simplified model that then prevents users from doing things that they can do under Windows. ALSA messes it up by exporting 90% of the capabilities of most hardware mixers into user space and leaving the complexity for someone else to deal with :) takashi and jaroslav are working on the issues. i think their approach is correct (export the hardware capabilities, wrap them in alsa-lib to provide a simple interface for most apps and users) but it requires significant amounts of coding and won't emerge in a few days. assuming that your requirements are met by OSS's incredibly simplistic model of an audio device driver. need to control xrun detection? want to avoid starting the device until you've got enough data ready? want to use non-interleaved access? want to use a sample rate or sample format not supported by OSS? well, it won't take 5 lines, or 50 lines or 500 lines of code: you simply can't do any of this in OSS. JACK is explicitly NOT more flexible than OSS. its vastly LESS flexible. that's the whole point. 90% of audio apps don't need to concern themselves with the details of interacting with audio interface hardware. so JACK removes all of that: you get one sample format, a predefined sample rate and a somewhat inflexible buffer size. the tradeoff: your code gets much simpler, and you can forget about the hardware, which is good because it might not even be running or in use! plus you're running in a way that is well suited for the fundamentally real-time nature of audio. OTOH, JACK requires less lines of code than OSS to get up and running :) --p

On Wed, 2003-10-15 at 04:51, Paul Davis wrote: It took a long while before I found out how to disable the default stop-at-xrun behavior. My app needs to be running 24/7/365 no matter how many xruns there are, without needing to restart the interface every time. Minimal dataloss required when xrun happens. -- Jussi Laako <jussi.laako(a)pp.inet.fi>

On Wed, 2003-10-15 at 23:33, Paul Davis wrote: Unless hardware provides xrun detection.. It was back in 2001/10/6 when I started ALSA 0.9 support, documentation was absent at the time. I was able to fix it at 2002/9/29, quite a long time to figure it out. Biggest problem of ALSA is difficulty of installation to the end user. And difficulty to figure out which channel in ALSA is which input channel on card (M-Audio Delta1010 in this case). This is way much easier in OSS (/dev/sndstat). This is why I recommend OSS to the end users. ALSA still lacks the "./install" -> [OK] -> [OK] -> [Exit and save] -> "soundon" -installation. SuSE is doing OK on the installation area, but their biggest problem is hacking the ALSA into their kernel, making it pretty difficult to change the kernel while keeping ALSA stuff in their distro working. -- Jussi Laako <jussi.laako(a)pp.inet.fi>

At 16 Oct 2003 21:04:01 +0300, Jussi Laako wrote: did you try alsaconf script? it's as easy as you wrote above. well, the same is true for 2.6 kernel, so far. the build of alsa-driver tree doesn't work well if the kernel has already ALSA supports. it will be fixed soon later. but you forgot one thing: if you use the commercial OSS, you have no chance to modify it by yourself. it's a fate of binary-only stuffs. Takashi

I believe fully in ALSA & JACK, but I code in what is the best for the time being. At present, it's best to code for both ALSA and OSS. is JACK fully functional and ready for commercial programs? no. does JACK or ALSA work in other unixen? no. If you have good coding practices and use good, modular design, changing the audio API is easy, so there's no need to look 3 years down the road! If you designed your program well, it will be ready when JACK is. __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

not yet... but tying the success of your product to the progress of a relitavely new open source project is a bad idea in some cases. It depends on the timeframe and situation. Say you have 3 months to deliver an audio app for both windows and linux. If you take longer than that, you'll have to start going to work again or get evicted (I swear, this is a hypothetical situation ;P) JACK may or may not be ready by then, but if you use agile programming practices and an abstraction layer, your app will be ready for JACK or whatever new pops up, even at the last minute! Good. I'd code my app for OS X too if I could afford a mac.. mayhaps my next big purchase? Any plans for other unixen? I know VST is avail for SGI... <snip> rhetorical answer: Reason Project 5 Reaktor Buzz VAZ Modular hehehe, no need to go further. My conclusion before I shut up on this matter: in real life relationships, put all your eggs in one basket, have faith in said person, yadda yadda. In APIs & OSen, be like a distrustful whore! put your eggs in every basket you can find! jump ship at the first sign of new opportunity. I'd make an exception though that I generally want linux to be sucessful, so I'll write for linux even though there isn't much of a market for linux audio apps... yet ;) __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com

On Tue, Oct 14, 2003 at 09:26:07PM -0700, Thomas Webb wrote: This abstraction layer already exists and it's called PortAudio. Under those constraints I think you'd be nuts not to use it. -- Paul Winkler http://www.slinkp.com