Le 13 juin 05 à 17:22, Paul Davis a écrit : An API becomes 'official' ... when its uses but most of the developers. Remember the old days of OS9 when the 'official' MIDI API was Opcode OMS.... when MidiShare was already in the field. The official is not always the 'best' one, but the one pushed by powerful people... and/or at the right time. Stephane

On Mon, Jun 13, 2005 at 11:22:57AM -0400, Paul Davis wrote: And the benefits, of course. Actually, I find it difficult to find anything in ALSA to confirm the idea that the requirements from the pro-audio users have had a negative impact on the system as a whole. For professional use, you probably want to get as close as possible to the original data with nothing in between (i.e. the hw: devices). Now the main problem I see with ALSA for the 'desktop' users are in the control interfaces. Maybe the idea of the driver providing a sort of description of the card (e.g. a list of control elements) and having this info interpreted by a generic mixer application was not the best one. It works in some cases, but breaks down easily when a card has different 'modes', in particular for surround. For example it seems to be quite difficult to get a single volume control for all channels in a 5.1 setup, something a desktop audio user would take for granted. -- FA

Yes and no. The Desktop users usually choose a Distro which is able to set up ALSA just fine (I personally dislike distro dependent config tools, regardless if their name was YAST or DrakConf). After that they most often feel happy by controlling the master volume via a mixer applet like kmix. I agree that alsamixer needs a replacement. I tried to write one, but failed in an early stage due to my ignorance :) . Or day two, yes, I absolutely agree. I still think it's very difficult to create a really good mixer interface. Best regards ce

Right. But did we have another chance? No. ALSA tries to drive different cards, maybe based on a certain chip, with one driver (e.g. AC '97). Or different cards based on a certain bus (USB via snd_usb_audio). ALSA doesn't know anything about the jacks that are actually available to the user via the computer's or card's chassis. This led to the generic mixer interfaces which cannot reflect what the user expects, that's true. But I still think generic mixer interfaces have been the right way to go in the past - due to the limited manpower of the ALSA project. It was better to concentrate on the drivers. I'm simply impressed how many cards are supported by the usb_audio-driver. Maybe it will be possible to add an interface to ALSA so users can easily contribute card/computer specific mixer information. But still there will be some disadvantages: * I do not expect that too many users will contribute. See the instrument definition files in sequencers * Even if there were many and good user contributed mixer interfaces it will still be difficult for "normal" Desktop users to understand and use it. The signal flow in a soundcard still is a black boxed thing for common users. What does monitoring mean? Why does the CD slider not affect the volume of a CD I play via xmms? What the heck does PCM mean? Let's be honest: Let a "normal" desktop user look into the mixer panel on a WXP driven notebook. He will be disappointed as much as looking into todays alsamixer ;-) . Thanks for the thoughts & best regards ce

well, even after all-years use of Linux, and many, many years worth of audio hacking, i don't personally see ALSA as good for anything than an 'also-ran', yet. i mean, give me a break. musicians using windows still jam waaaaay more than the LAD crowd. this isn't to say that linux-audio jamming isn't -FUN- .. just that not as many 'privileged' are up to the task .. yet .. professionals 'use what works', reliably. it doesn't matter whats underneath, as long as it works. linux audio has the bonus that, once it works, it works freakin' well. just, try very hard not to keep it to yourself, if you think thats worth anythin' .. :) this isn't a linux situation, its an industry-wide situation. all musical instruments are 'about control'. ALSA won't progress beyond its current clique, until it recongizes this fact, embraces it, implements it, extends it .. i tell you what, from my standpoint as a pro-audio type, i don't see -ANYTHING- wrong with this, and perhaps this irony is what you're getting hung up on: it just doesn't do this _ENOUGH_ to make it worthwhile. on one hand. on the other hand, there =are= excellent ALSA-app examples out there. just not well sync'ed-enough promoted. the 'language' of the situation is what counts. i don't care if i have to iteratively read /dev/asound, or 'clean a linked list full of items', as long as, either way, the description is **standardized** .. seems to me the ALSA crowd have 99% of the work done, if only they'd get a bit more pimp about things and get the APP writers subscribed... actually, the average desktop user right now wouldn't give a crap what audio-rate it is, as long as it sounded good and didn't interrupt the jam. the average mac or pc user falls in this category, as do the rock and roll stars. ALSA, as do all API's, needs to step up to the promotion plate, else it'll all be ignored and forgotten. don't ever forget that audio also means rock 'n roll, and silent stderr just ain't rock 'n roll, yo... -- ; Jay Vaughan

right. so we've already established that the actual nature of the problem on linux is different, and much closer to the windows situation - a huge variation in hardware types and configurations. jwz solved his "problem" by throwing the problem away, and moving into a domain where the problem he had wasn't solved, it was eliminated. the competing APIs is definitely a problem. the OSS guys continue to refuse to accept ALSA, and continue to promote the benefits of their API and libraries. The layers that have been built on top of them (PortAudio, JACK, the arts audio api, gnome-sound, etc) continue to compete with each other in various ways. what is happening on linux is similar to the windows world: multiple audio APIs each of which serve a different purpose (windows own MM api, ASIO, GSIF). OS X has a head start here because they forced everyone, even the email client writers, to use a callback model for audio I/O via CoreAudio. if we could do that on linux, the biggest headaches could be solved quickly. but as you note, we can't. jwz would have refused to buy the equipment from that vendor. he would have insisted that it should work on the gear he already has, since ALSA says that its supported. "and now they tell me i have to buy a machine from this Linux Audio Systems people just to play music at the same time as making a skype call. wtf?" there are millions more people doing audio on windows than on osx, and yet windows requires *at least* as much work to get setup for pro-audio as linux. so what conclusion do we draw from that? --p

That's not a problem, that's the usual evolution as seen may times in the free software world. The problem is that an audio developer these days has less chances to choose the "right" system. That's why commercial software (Realplayer, Skype) often still uses OSS - it's easy to do and works on many un*x machines. What's missing is a clear guideline for (newbie) programmers of audio applications and maybe an example client or library which is able to autodetect the audio subsystem. [...] Lat's do it better :) ? Thanks & kind regards ce

I'm glad that even people who are that deeply involved in system development as you are can have such thoughts. I also hope that a linux audio system will be easier to handle some day. I'd like to add: * I dislike the comparison "Should work as smooth as on Mac/Win". I really hope it will soon work _better_ as on any known system. * Am I willing to spend nights configuring my system? No, I'm not :) . I'd also prefer a system which works out of the box. But as I have chosen that I prefer using free software (because I feel free and do not want to depend on any company), I save some money and pay for it in terms of spending time in learning system details, helping to make the system better and helping others where I can. I think we all know about the weak points of the linux audio system. But as the communities resources are limited, we'll still need some time to get to the point where everything is working just out of the box. Best regards ce

yes, we have established the actual nature of the problem. on linux. the problem is: not enough apps, and what few apps they are: 'not-standard' and 'not-synced' with the distro's world view of things. the lesson of jwz is this, and its a hard one: if the user even has to -think- about setting up their audio system, even just a tiny little bit, _BEFORE_ using an app (but not necessarily during or after), then linux will be 'behind the big guys'. when i multi-track on OSX, i don't even think about the 10 channels of digital i/o i'm getting from my firepod, nor do i care about the megahertz, nor do i have to set a damn iota of it up. i just use the app (cubase/logic/intuem) the way it wants me to use it and i feel good about it. the OS handles the bullshit. accept this config/usability challenge, or don't. (y'know, maybe make the linux ISO boot CD the solution to ALSA, not the problem...) WHAT OSS guys, and why aren't they paying attention to linux-audio-dev if they're such great OSS guys? i mean, c'mon. its weak to draw such lines in the sand, yo. show me a great OSS app, and then show me 10 ALSA apps, before you make such conundrums out to be the excuses they aren't!!! yeah, and this sucks ass. to multitrack, depending on my app, i could go one of 3 different ways, and only and all because some developer decided that writing a few honky lines of code was worth more than an e-mail or two to someone else who had already done 'the glory work'. bah! if you want to see a community using honky-ass technology, look no further than the VST/ASIO crowd. man, its wonky, but whatever: they're using it. or didn't you notice? actually, what i like about the MidiShare effort is that it seems to have been written by people who don't really give a shit what the model is, they bend it to their own model until its sexy. in other words, the french. umm.. i think the -only- reason you and i are even talking about jwz is the fact that its so -freaking controversial- that he 'switched to mac' (and even after the intel thing, what a bone-head) in the first place. because its obvious. just get a fucking mac, jwz, if audio is so important to you. who gives a shit, mr. million-dollar dark-and-lonely-place? macs have been good for audio since the beginning, or didn't you know that? linux guys giving the 'jwz should just by an sb-live' argument are weaker than piss. i mentioned jwz in the first place because you should know: linux audio needs to be a pop star. until it is, it won't be working well enough. sorry, but no. i set up my firepod, a wonderful audio i/o interface, and from that point on it just worked. setting it up consisted of a bit of humble-pie windows driver-.exe downloading, exactly *one* 'confirm that you want to do this' step, and from that point on it was magic. perhaps what the ALSA crowd need is a crash-course on making AUTOPACKAGE shell scripts which leave the stupidity of entering the root password up to the user, and from that point on just provide what everyone wants: a working AUDIO subsystem. -- ; Jay Vaughan

On Tue, Jun 14, 2005 at 02:20:13AM +0200, Jay Vaughan wrote: The guys that wrote it. http://www.opensound.com/ -- Paul Winkler http://www.slinkp.com

On Mon, 13 Jun 2005, Jay Vaughan wrote: I must admit, I had to double-check that I really am reading the year-2005 folder of linux-audio-dev, and not some old mails from the archives. ;) Now that SuSE, Mandrake, Fedora and others have started to use dmix as the default output plugin, basic desktop sound stuff should finally start to work, as people expect, out of the box. If anything, rants like the recent one from jwz, are a wake-up call for desktop/workstation-oriented distros that sound is important. Details like configuring dmix and other plugins, making sure the aoss-wrapper is used with OSS apps, etc are important... As for the API-jungle, yup, that's a problem, but it's something really, really hard to avoid in the FOSS world. Just look at the amount of options for video output when you type "mplayer -vo help" -- no unified API there either. That's not to say that we should give up, but getting majority of developers behind a single API will not be easy... But, but, this is just part of the whole package developers and users see. Fortunately there are other areas where FOSS systems have strengths over the closed competitors. And at least for me, FOSS systems still provide better overall value... (also for desktop use). -- http://www.eca.cx Audio software for Linux!

On Tue, 2005-14-06 at 10:50 +0200, Jay Vaughan wrote: I think we should take it for what it is: a whiney rant from someone who is famous for whining about anything and everything. Why should we care what jwz thinks? Let him publicly cry and run to OSX - see if I care. Addressing the concerns of people looking for help on this list is a million times more important than some nonsense PR campaign to counter the rant of a whiney dotcom washout that happened to get slashdotted. -DR-

On Tue, 2005-06-14 at 11:27 +0200, Jay Vaughan wrote: Who in the hell is this jwz, and why does everyone care what he thinks so much? Can someone at least post a link to this rant of his? Lee

On Tue, 14 Jun 2005, Jan Weil wrote: Hmmm... interesting... still, who is this guy? I've been using Linux audio since like 1997, yeah, I ran into a few issues back then (I had a Turtle Beach San Tropez card), but have used several varieties of SB through OSS and ALSA, and currently have one machine using SBLive! + ALSA (my graphics workstation) and another machine using M-Audio 2496 + ALSA + Jack + realtime patches (my DAW), and audio has always "just worked". I build my own kernels and ALSA drivers, so maybe that's it? *shrug* I've had audio issues on Windows plenty of times also, including one machine that dual-booted Linux & Windows... Red Hat detected my video and sound on first installation and everything "just worked" and on Windows (same machine), I had to install some drivers manually because the autodetection failed. Oh well. -- Brett

Lee Revell <rlrevell(a)joe-job.com> writes: People seem to be fooled by the fact that jwz has done many open source contributions. However, he has a history of ranting, last instance I remember was a hate-parade against the Debian X Windows System maintainers. Just ignore him, my 2 cents. -- CYa, Mario

Isn't it too early? I think 2005 is a break point for linux audio, but first of all we need some more users before promoting linux as the best audio desktop to the world. We all know that we still have to go several steps. Looking back the past three years I think we'll be there in two or three years. Best regards ce

he writes simply this: he shouldn't have to freakin' care. maybe this is linus' fault for not putting in all the kernel patches needed to make ALSA "just work", eh? i remember discussing the founding of linux-sound.org with you at NAMM, almost ten years ago, Dave. its sound, why shouldn't it just work, the same way that the mouse just works? don't answer that with technical reasons, answer it with emotional ones, please, just for a change ... i do hope you're taking the dates of a: his rant, and b: your current xine build timestamp, into account.. -- ; Jay Vaughan

There is no question whatsoever that the ALSA's documentation at this point is sufficient. However, I cannot shake the feeling that we may be missing one of jwz's valid and perhaps most important points for the success of Linux on the desktop: When I install just about any current distro, my video in most cases "just works." Granted, I may need to install the proprietary driver from Nvidia or ATI for good 3D performance (and in some cases not even that, i.e. Intel integrated chipsets), but that's about it (although I am sure some of you may object to this analogy, generally I find that in most cases xorg automagically configures itself and stuff simply works). Now, software mixing (which imho is what jwz was ultimately hinting at despite some confusion between hw and sw mixing) at least imho should be a part of the default desktop experience. Please note that us, LAD/LAU members, are but a small percentage of the overall Linux community, and as such our ALSA needs cannot be observed as the "benchmark" of the overall Linux desktop needs. Quite the contrary, as pointed in jwz's blog, most users simply want to play Quake3 while having Xmms or Amarok or whatever play in the background, coupled with various "you got mail" desktop dings and possibly voice-over-net apps. Now, it is true that most of such concerns should be distro makers' responsibility but ALSA project could certainly help further such endeavors by providing default bindings in the /etc/asoundrc file where first card could be used for these purposes with all the glory of async/dmix/snoop stuff installed by default. Then, for those of us who do not like this kind of behavior we could simply disable such functionality by connecting jackd directly to the hw:0, in effect bypassing the plughw and the problem is solved--default desktop user would have what most OS's have had since early 90's, and us select few who would want to use Linux for specific audio-related tasks would tweak our .asoundrc's (just like we always do). The only difference is that this way the default behavior is tailored towards majority and yet flexible enough to fulfill just about anyone's needs.* The side-effect of such an approach would prove ALSA's dominance over OSS among the average joe user (who are the majority of Linux users, after all) and this would in effect quickly make OSS obsolete, further simplifying the entire matter of audio hw support. Now, is this entirely ALSA's responsibility? Absolutely not. However, could ALSA make some steps to promote these critical technologies (i.e. the aforementioned integration with /etc/asoundrc) and therefore make desktop out-of-box experience more user-friendly? Absolutely! *the only possible concern with this potential solution is how ALSA deals with async plugin when it has some particular process talking to the card and then jackd wants to connect directly to the hw:0. Will jackd be denied or will the async drop what it was doing in order to allow jackd to connect? Best wishes, Ivica Ico Bukvic, composer & multimedia sculptor http://meowing.ccm.uc.edu/~ico/

On Tue, 2005-06-14 at 17:58 +0200, Mario Lang wrote: Well then why doesn't he post some constructive criticism to alsa-devel instead of ranting on his stupid blog? Talk about preaching to the choir... Is it me or are 90% of the people with blogs self-important egomaniacs? Lee

On Tue, 2005-06-14 at 21:09 +0200, Jay Vaughan wrote: Oh, that jwz. I guess he's not an idiot, but I still think his rant was idiotic. If he had posted on alsa-devel with some constructive criticism then it actually would have accomplished something. There are many examples of this in the past. Ranting on his blog just makes him look like an ass. Lee

On Tue, 2005-06-14 at 17:12 +0200, Jan Weil wrote: Also, he seems to be pissed because he bought one of the new "SBLives" that uses the snd-ca0106 driver, and expects to get hardware mixing like a real SBLive. He's just an idiot, and his beef is with Creative, not the ALSA people. Lee

On Tue, 2005-06-14 at 11:50 -0400, Paul Davis wrote: I've said it before and I'll say it again, this is a distro problem. We all know it can be made to work, so it should be a simple matter of automating the process. Don't they test this stuff before they ship? For example dmix has been available for quite some time, but no distro enabled it by default, even though users clearly want it. Now that ALSA uses it by default, all of a sudden, all the distros use it by default, and they're hyping it as some shiny new feature. Aren't the distros supposed to drive the adoption of new features, due to their proximity to users? We're in bad shape if all they do is wait for the developers to respond to user needs. This all tells me that the distro maintainers put a shockingly low priority on having sound work OOTB, otherwise, why didn't they do this a year ago? AFAICT it's just laziness. Lee

i dunno, i don't want to speak for jwz, but i'm pretty sure he's aware just how a few people can get a very great thing done. you may say he's seasoned at it, in fact, and knows the pitfalls 'the mob' go through in order to get themselves organized and avoid stagnancy .. at least, as a reader of his frequent rants for the past 15 years now on the topic of OSS/software development, thats the sense i get. i would like to point out that both ALSA and CoreAudio have similar lifecycles, too. i mean, i don't think CoreAudio got a lot of its heritage from the NextStep days (though NS had bitchin' audio from the beginning, also), but there is a great deal to be thought about in comparing the two approaches. i think a combination of: a) a well-formed strategy to clean up the Linux mess, and b) an [mplayer/skype] patch-fest to bring them in line with that strategy using actual source changes (where possible), and c) far greater advocacy of the success of linux audio by its users and boot-CD makers .. ... would do the job. oh, and i guess it wouldn't hurt to have a macmusic.org-like "linuxaudioapps.org" clone around, too, though i know there are already a few sites perilously qualified for this slot .. -- ; Jay Vaughan

On Tue, 2005-06-14 at 21:16 +0200, Jay Vaughan wrote: Skype is closed source and the mplayer developers are a pain in the ass to deal with due to blatant pro-OSS (as in /dev/dsp) bias. If it were easy these would have been fixed long ago. Lee

On Wed, Jun 15, 2005 at 11:50:11AM +0200, Lars Luthman wrote: never worked right here, end up using the arts backend (and jack backend for arts...and alsa backend for jack...). how many chained APIs does one need? mplayer -ao jack blabla.mp3: AO: [Jack] Initialising library. MPlayer interrupted by signal 11 in module: ao2_init - MPlayer crashed by bad usage of CPU/FPU/RAM. - MPlayer crashed. This shouldn't happen. It can be a bug in the MPlayer code _or_ in your drivers _or_ in your gcc version. If you think it's MPlayer's fault, please read

i don't think thats entirely fair. when jaroslav started ALSA i think he was intent on a set of ideas that looked like the best choices at the time. the goal was to improve lots of issues with OSS, including its requirement for all "functionality" to reside in the kernel. i don't think that, even if we had had fons on board at that time, that the idea of using a DLL rather than interrupts to truly drive the whole system would have occured to anyone in 1996-2000. as for callbacks, this would have been dismissed by almost all commentators because it would require every single existing audio app to be rewritten. it would have been a great idea, yes, but it would never have been accepted. too many developers would have whined to LKML that it was unacceptable to remove the open/read/write/close model from the official linux audio API. apple had good fortune, good people and lots of control on their side. we have smarter people (or at least as smart), lots of good examples, but very little control. --p

true, but i take it you get the way CoreAudio is doing it: it means you can drive audio processing from a different interrupt source (e.g. system timer) because you have very accurate idea of the position of the h/w frame pointer. In CoreAudio, the "callback" is decoupled from any PCI, USB or ieee1394 interrupt. Tasty. you can, true, though JACK doesn't. JACK uses poll and mmap (the OSS driver uses ioctls and select IIRC); expecting regular audio developers to use poll/mmap on a day to day basis creates very bad reactions :) --p

On Thu, Jun 16, 2005 at 10:30:29AM -0400, Paul Davis wrote: Didn't know they were doing that. But what is gained this way ? The interrupt latency (probably less) and scheduling delays are still there. I once had a look at the CoreAudio code in SC3. It's in the same file as the jack interface, and both have similar code to implement some sort of DLL-like smoothing. Any advantage CoreAudio has is certainly not visible in that file. And when the jack version is rewritten to use the second DLL (using OSC time) I'll be proposing, it will be much simpler than the CoreAudio interface. It could even by done using the current (frame time) DLL, with some complications. I know, but would there be much difference between poll()/mmap() and read()/write() if you look at what happens internally ? The read()/write() calls combine the actions of waiting, probably using the same mechanisms as poll(), with a data copy to or from a user provided buffer. The latter you do yourself when using poll()/mmap(). Both systems are the same in the sense that for both, the user waits for the driver. Where are all those real programmers ? ;-) -- FA

On Thu, Jun 16, 2005 at 05:59:09PM +0200, Florian Schmidt wrote: Why should this take a extra period of latency ? -- FA

On Thu, Jun 16, 2005 at 10:57:51PM +0200, Florian Schmidt wrote: Strange... If you would program a timer using the info available from jackd's DLL, it would never generate its interrupt before the HW is ready (i.e. has at least a period available). It would actually trigger just after the interrupt it is derived from (the small average latency that is not compensated). So I wonder what problem CoreAudio has with this. -- FA

coreaudio does dynamic re-sampling of its 'common feed-pool' ring-buffer for audio i/o, so maybe this delay compensation is factored in that calculation? multiple clients with independent sample-rates/bit-formats can be doing their thing in OSX, a nice and good thing in my opinion (means you can have very small soundfiles for very small events while also doing the whole dvd dolby/5.1 thing at the same time) .. and i have not seen latency issues yet, except for maybe poorly written USB-audio drivers, here and there .. of course, there are tons of DAW's on OSX who don't necessarily use CoreAudio extensively yet, but there are a few OSX-native (not a port) apps that can demonstrate CoreAudio doing the work (intuem, etc.) i know its fast for what its doing, this re-sampling business.. at least on my powerbook .. altivec? i've got tons of RAM too, though, maybe thats got at least something to do with it .. ermm, maybe thats not so technical, but i can say that OSX' approach of the kernel doing the monkey business around a common API-bound ring-buffer while all apps are in sync seems to have delivered the goods .. -- ; Jay Vaughan

At Thu, 16 Jun 2005 10:30:29 -0400, Paul Davis wrote: I actually tried to implement a similar feature quite ago (I should still have a piece of half-working code somewhere...), but I didn't merge it simply because it didn't give you better performance, only the waste of codes. Interestingly, now we have dmix and its problem with the irq timing. It might be nice to resurrect this kind of extension... Takashi

ix(a)replic.net writes: Works flawlessly here. -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n

Apples' API docs for CoreAudio can be found here: http://developer.apple.com/audio/pdf/coreaudio.pdf great reading, actually, i thoroughly enjoy their approach to HAL .. -- ; Jay Vaughan

On Fri, 2005-06-17 at 09:57 +0200, Alfons Adriaensen wrote: GNOME & KDE are complete development platforms, so they need to support the development of audio applications. I'm not saying they should develop new libraries. Just that they need to standardize on particular APIs/libraries that all work together OK. (I think both GNOME & KDE are considering switching audio APIs at the moment, so now is a good time for the linux-audio community to get involved.) Damon

Hi, I absolutely agree. But why did they start to use arts/esound/gstreamer? Because they wanted to ensure that multiple applications can play sounds at the same time. What chance did they have to use a commonly accepted soundserver? None. There was no soundserver and no softwaremixing, and less people had (and still have) an audio card with hardwaremixing. Yep. Agreed. arts isn't maintained anymore, so KDE is looking for a replacement (like gstreamer). Because there's no common soundserver for all applications, they will need to make a decicion. Which audio subsystem should they support? ALSA direct access is no choice because it blocks the device. DMIX is a choice, but what if I want to use JACK simultaneously without using DMIX? JACK could become a common audio server but still it isn't. Any recommendation which audio system a programmer should use? Welcome in the Linux audio world ;-) . BTW: Arts has a timeout mode so it'll free the device as soon it isn't needed for more than the entered time. Thanks & best regards ce

On Fri, Jun 17, 2005 at 06:09:52PM +0200, Christoph Eckert wrote: Is that realistic ? Would you do any serious audio work and leave all the desktop toys enabled *on the same card* ? (I don't have any 'desktop' sounds, so for me it's easy :-) For any serious music and audio software there is (for me) just one answer: JACK, and maybe also ALSA. For all the rest I think ALSA's dmix device is the right solution. -- FA

On Fri, 2005-06-17 at 18:09 +0200, Christoph Eckert wrote: This question amounts to "how do I block the device without blocking the device". You can't do this with any OS. Lee

Hallo, Alfons Adriaensen hat gesagt: // Alfons Adriaensen wrote: ... like Ardour, which requires Jack instead of working with Arts or Esound. I think, that you're a bit unfair in regard to desktop environments. What about the role, sound can play in the accessibility of desktops, by giving acoustic feedback? We "pro audio guys" hate these bells and chimes, but to other users they can be important, and somehow you need some way to send these sounds from a Gonme/KDE app using Gnome/KDE libs to the soundcard, preferably in a simple, consistent way for application developers. Or go the other way around: Speech recognition. The users talks, X-Wordoffice writes it down. This is not that uncommon anymore in the Win/Mac world, and it also requires the application developer to deal with sound input *and* you need to get it into the desktop's document layer. Preferably Gnome/KDE make it easy to get to this sound with their own libraries. Sound plays a major role on desktop machines, and Novell/Suse surely is not sponsoring ALSA for us musicians, they want to get sound on desktops. The best of course would be a solution, which works accross all desktops and non-desktops. But this would require all applications to be "broken" in the regard, that all these apps should support at least this solution. Ciao -- Frank Barknecht _ ______footils.org__ _ __latest track: "scans" _ http://footils.org/cms/show/41

Hallo, fons adriaensen hat gesagt: // fons adriaensen wrote: Well, I don't really want to discuss Jack's merits (we all know them). I just wanted to point out, that one might consider Jack to be a kind of "pro audio desktop". It does much of the same things for audio, that Gnome/KDE do for desktops: Provide a common API, abstract concepts from hardware, let applications work together in convenient ways, it provides system configuration and session management hooks (used by things like qjackctl) etc. If one thinks about Gnome/KDE from the perspective of how we benefit of Jack, then some of the choices, the G/KDE developers faced and tried to solve, might become more understandable. They actually are working on a much bigger problem than we, I guess, let alone because they have to support many more users. Ciao -- Frank Barknecht _ ______footils.org__ _ __latest track: "scans" _ http://footils.org/cms/show/41

On Sat, Jun 18, 2005 at 02:34:46AM +0200, Christoph Eckert wrote: I think we can educate users to use a different login for pro-audio work versus their normal desktop. The different logins can use a different audio setup. Personally I have a special runlevel to do audio work, but that would probably be asking too much from your average joe-audio-user. -- Martin

Well I think that there is absolutly no border between "Professional" Audio and "Non-Professional" Audio. Just think about it, today you're using mainly xmms to play some ogg-files, but suddenly you become a little creative, und you want to do some drumming with hydrogen. I see no reason why somebody would screw up his whole configuration just because he suddenly switched from beeing a "consumer" to beeing a "professional". So propably jack is the only way out for the desktop :) -Richard

you're missing the point: you're not a pro, you're someone who becomes a pro. this is a false and blatantly stupid assumption! the 'cheap sound card' should work using the same tech as the 'expensive' one. -- ; Jay Vaughan

I also dislike the idea of dividing the users to pros and amateurs. Am I a pro? Certainly not, I'm just a hobbyist. And I'd be glad if some day I could install any distro, plug in my guitar, fire up jack-rack and start jammin. We all agree that an AC '97 chip is not the best solution to do so, but as soon as its successor HDA will spread (which works at 48000kHz per default), things could change. Even pros tend to buy cheap hardware, and the difference between consumer and pro cards will decrease. Look at me and Frank Barknecht. We're both using a relatively cheap consumer USB card on out notebooks. And furthermore: Even if JACK would be the standard on every desktop distro, this does not prevent a pro user to reconfigure the system and run JACK on an other card. It remembers me the days as softmodems haven't been supported well by linux: "Buy a real modem, softmodem suck because these eat you CPU power". Sorry, but on a desktop machine it's a cool idea to have cheap hardware and let the CPU do as much as possible, because your CPU is bored during you're reading webpages. Therefore, I have no problem running JACK as a default soundserver even if it eats some of my CPU power and to use a cheap card as long as the sound from my speakers doesn't sound crappy. Even when running JACK on top of my AC '97 onboard chip, plugging in my guitar and using some LADSPAs in jack-rack, it sounds much better than my digitech studio quad I still have in my rack and was about 450EUR 7 years ago. [...] At least for the hobbyist (and I can speak for them): disagreed :) . Best regards ce

On Sun, 19 Jun 2005 01:57:27 +0200, fons adriaensen <fons.adriaensen(a)skynet.be> wrote: As a profesional by anybodies standard , a few observations. Setting up a studio with jack and a well supported mutlichannel soundcard is at the moment easier than configuring a multimedia desktop. It is not a big effort, especially compared to the amount of time it takes to attach up your hardware mixer, figuring out the perfect placement of the monitors, the room accoustics, etc. etc. Any problems with proaudio on linux are very minor compared to the problem of proper grounding a studio to avoid ground-loops. The fact is that it is not just the audio part that makes setting up a multimedia desktop hard on linux. Getting your browser to support all the media types, choosing between a zillion players and codecs, proprietary plugins lagging behind their Windows or OSX counterparts etc.etc. And here is where the distributions should get their act together. Less choice, better configurations. Exactly. That is what I do. In the studio I run jack. In the office just KDE with artsd on alsa. No problems. And since when is switching the audio engine to change from reading your email to doing your audio editing a big issue? Prior to osX that is what you would do on the mac. There are a lot of studios still using os9 hardware with ProTools. Gerard

this woud IMHO be the best solution, but it will not happen or at least last very long until * all distros will have JACK running per default * all developers of any audio program have rewritten their code. This is a solution we already can provide. The problem is not that an active audio user cannot learn that he needs to kill the desktop server, to start JACK and then to optionally restart the desktop sondserver on top of JACK. The problem is that so many apps use so many different ways to output audio: arts, esd and gstreamer, ALSA or OSS direct access. I agree. But what still is needed is a common desktop sound server which will be part of each distro. arts is dead, esd will also be dropped and be replaced by anything like polypaudio or gstreamer. What's missing is a commonly accepted soundserver which isn't bound to a particular desktop, and each audio developer should use this (still missing) common soundserver, regardless if you're working shell only (as julien does), on FVWM, IceWM or anything else. So what's missing in my opinion is that the community needs to agree about one common soundserver for all desktops and then any audio application should use it. If the community will not choose JACK then another one needs to be elected or created. Any audio developer should use this soundserver. Direct access to the card should become a nono on multitasking multiuser computers. We as professionals simply could ignore this because most of us kill all soundservers, fire up JACK and we're happy, even using xmms to play some oggs via JACK. OTOH I'd really like to see that the audio experience of a desktop user improves. In my opinion it is not important if this default soundserver will be JACK, another one running on top of JACK or directly on top of ALSA or OSS. It is only important that the community agrees about one solution and starts using it. What have we to do with this? Less. Except for the fact that we have enough knowledge to design an optimal solution. What I want to achieve is not that we're working on this issue by writing the code. None or less of us are interested in such things. But we could create a recommendation. Thanks & best regards ce

because its broken. why not, no matter whether the chipset is on-board, or in an external firewire case, present the -same- configuration of the audio-system, no matter what! *this* would be a pro approach. saying that its okay to have two different audio subsystem configs, because "most likely" (ack, spit!) there will be 'two different cards' involved .. this is so broken. -- ; Jay Vaughan

Frank, are you really talking about our beloved Terratec Aureon?!? Just kidding :) . I'd like the following: * As soon as the USB card is available, use it for all audio output. I'm at home and I have connected my monitor speakers, and I also want to hear my ogg files through it instead of my built in laptop speakers * as soon as the USB card is not available, use the internal card, regardless if I start playing ogg files or I start jack-rack for a quick 6 dirty test because I'm on tour and want to check something in the train or I just want to show a friend what cool audio software linux has to offer. Best regards ce

Similar here. But since I have tried Ardour I'd like to replace my external mixer with a mutliport soundcard and ardour. The ability to include LADSPAs in a mixer strip in ardour is *much* better than my digitech multi effects processor. The only problem is that I have USB 1.1 and firewire isn't supported well, but withour these limitations I'd like to see a USB 2 or firewire card with 10 Stereo ins and 1 stereo out :) . Thanks Paul for Ardour! Best regards ce

right now, just to get the sounds out of all the apps running my setup is something like this: ,______, gstreamer(AOSS)-| CARD | artsd-v | |----Amp jack-^------| | * other ALSA---|______| * one at a time pls luckily the card can mix 8 channels down to 2 in hardware, so everything can connect at once, but wtf? how would a normal user do this? i strongly disagree with 'just use two cards'.. its already a nightmare beacuse gstreamer wants to use OSS emulation on the same channel as mplayer32 (which i could get around by running a second jackd in 32bit mode, connecting to mplayer32 and communicating with the 64bit jackd via UDP over loopback), etc etc. i have to randomly quit apps to free stuff up and keep a mental note of which API each uses even with the additional hardware mixing.. luckily i have one free hwmix port left, to add this "polypsaudio" tumor..

I do not use it but I read that it also has a JACK sink. Best regards ce

AFAIK JACK isn't intended to do samplerate conversion on the fly. To do this, you need something on top of JACK (maybe a soundserver) or between JACK and the actual hardware (maybe DMIX). We're currently discussing this in the other thread ;-) . There are even applications which don't tell you in any way which subsystem these use so you have to guess about it :( . I think so too but there are people who have other opinions. Best regards ce

I think that's not the point we're discussing. Of course, if you're disappointed with your internal card you'll buy a better one. But even the new one: Don't we want to plug it in, fire up [your application here], tell it to use the new one and start making music? Best regards ce

Lee Revell wrote: Interesting. Do you know how they intend to use jack for desktop apps ? using artsd/gstreamer/esd piped into jack or other methods ? Benno

On Sun, 2005-06-19 at 12:44 +0200, Benno Senoner wrote: I think they are actually JACKifying all the apps, I could be wrong though. Lee

This means that some audio applications will suddenly be unable to output sound, and still work is needed to prepare JACK for this special task. I think that the approach of using DMIX between the ALSA driver and JACK can be a pragmatic solution until all apps are jackified. Of course, at the same time, such a system reduces the need to jackify other apps :( . Can somebody confirm that Linspire is using JACK per default? I heard it several times, but I didn't try it out for myself Anyone seen Linspire running? Well, from Wednesday to Saturday the Linuxtag will happen just 500 meters from here. It's europe's biggest event on free software, and as I'm there managing an audio booth, you can be ensured that I'll at least talk to the desktop guys. Furthermore, I was invited to hold two talks about audio, one desktop talk and one "pro" talk. Be ensured that after these talks everyone at least knows what JACK is ;-) . Best regards ce

OK, but I don't think they have jackified all apps (and even if so, give the code because most apps are GPL'ed ;-). Most probably they have used bio2jack a lot, but if this hack helps, there's nothing wrong with it. Best regards ce

I dislike this idea. I'm currently doing so: * Running arts/ogg players on top of AC97 * Running my music stuff on top of my USB card But meanwhile I dislike this behaviour for several reasons. I think we do it mainly this way because it currently can make things easier, but I really do not expect that this will become something that will spread. Best regards ce

I think we can not. Exactly :) . Best regards ce

On Sat, Jun 18, 2005 at 04:06:34PM +0200, Jay Vaughan wrote: You will not have to educate a professional user to do this. He will do it anayway because it makes sense, even ignoring the reasons we are debating here. As a professional user, you may have to give access to your system to employees, customers, etc. You don't want them messing in your private things. As private user, you may give access to you personal things to e.g. family members, but you don't want them screwing up your professional work. You may also have confidentiality requirements imposed by your clients. So even elementary security provides more than enough reason to keep the two well separated. There are not artificial, but very real. If we want any credibility in the professional world, we should not confuse the attitudes taken by 'prosumers' with those of real professionals. -- FA

On Sat, Jun 18, 2005 at 08:49:16PM +0200, Jay Vaughan wrote: Maybe I am stupid, and maybe you are a professional. In that case let me make two remarks: - If ever I have reason, as a customer paying for your services, to suspect that you are careless about the security and confidentiality of the data related to my project, for example if I know that your girlfriend or 12 year old son are using the same login to do their chatting, then I will take my business elsewhere. - If you use the type of language I've seen in your posts to a paying customer, he/she probably won't come back either. Have a nice day. -- FA

Jay Vaughan wrote: Hi Jay: I lied about retiring from this discussion. ;-) I went back and re-read jwz's comments, and I also re-read most of the commentary in this thread. I'm not sure how anyone can reasonably object to your (and jwz's) assertion that things should "just work". Who *wouldn't* love it ?! But as this thread demonstrates there seems to be more of a problem than is at first apparent. I agree that the distinction between pro and consumer should be a non-issue. Historically hardware manufacturers certainly make the distinction, they build some gear for Johnny Stay At Home and other gear for Jimmy On The Road Touring. But I don't think the distinction works so well when it comes to software at the level under discussion. Ideally we'd be rid of artsd, esd, and all the legacy from OSS/Free. We'd have one sound server (JACK?) and software mixing would be enabled by default. The remaining question is how to make this mandatory for at least the mainstream distros. Perhaps an appeal to the LSB ? I really don't know how such decisions are made. I do feel that despite the advances made in Linux audio development the domain is still perceived as something of a weak sister. We have less manufacturer support than any other hardware aspect of Linux, we are probably one of the smallest development communities, and we have inherited an unholy mess of conflicting audio subsystems (ALSA, OSS), sound servers (artsd, esd, JACK), incomplete implementations (lack of software mixing, poor system configuration process), and a dearth of easily accessible and comprehensible documentation. We've seen some amazing development progress, and I don't read any disparagement of these advances in your messages. Am I correct to consider you supportive of Linux audio development ? If I read you correctly it seems you're arguing on these issues: 1) The Linux audio software world is currently too confusing for the novice (or even the experienced user) to quickly and efficiently prepare his system for use. It takes too long to install and configure a working audio system, and the frustration is a real problem if Linux audio wants more adherents. 2) The distros have no guidelines to follow regarding implementation and realization of ALSA's features. This complication adds to the frustration above, and new users should not have to wrestle with such complications. These problems are exactly what the distros were intended to remedy, but their lack of concern for anything more than the most basic audio service screws the pooch for the user who discovers that he loses his system sounds when listening to his MP3s. Also, forgive my ignorance of OSX, but it seems that it's being held up as the Holy Grail for the normal user. I have some very basic questions regarding OSX and its audio system, perhaps you can tell me what I'd like to know: 1) Is OSX open-source and free ? 2) Will OSX run on Intel hardware ? 3) Does OSX have the range of FOSS development tools as is available for Linux ? 4) Is there *any* configuration required for the OSX audio system ? I'll restrict my interest in all of this to only issues regarding usability and transparency. Again, I don't see how anyone can logically argue that installing and configuring Linux audio software deserves to be the trial it is at this time. Ico Bukvic and Christoph Eckert have devoted energy to discussing possible ways of mitigating this toil, but I sense that getting the attention of The Ones Who Matter is no trivial pursuit. I would love to see Linux audio working for everyone as nicely as it does for me, but I know that it does so because I've been at it for a good long while. There's just no good reason to expect other users to have to make the same efforts, there is no special virtue in the thing being difficult. The point of it all is to get to making music as soon as possible, without having to hassle with configuration details at any level. I don't know if such an easy scenario is available to Windozers or OSX, but it's certainly not the standard experience for a lot of (or most?) Linux users. And if it *is* difficult on either of those other systems that's certainly no good reason why it should be difficult for us too. We can and should do better. As advanced users we on this list already know how to make our systems do what we want, but our experience is not being translated for the normal user. I agree that the distros should start fixing things that they ought to fix, including the transparent implementation of various features of ALSA. jwz believes he shouldn't have to make any special effort at getting Linux multimedia software working, and he's right, period. Some good ideas have been presented in this discussion, but no-one has indicated clearly *how* these ideas can be widely adopted. SuSE is likely to show more advanced audio implementation because they have members of the ALSA team working for them, but we shouldn't have to point new users to specific distros just to have what normal users expect from a contemporary working audio system. So who do we lobby at Red Hat or Debian or Slackware or Mandriva or ...? And on that topic: Why aren't the advances made by Planet CCRMA and Demudi integrated into the standard distributions themselves ? Is it really such a great thing to have to point new users to a specific distribution just to get finely working audio ? If the distro manufacturers and maintainers aren't aware of the possibilities already available to them wrt audio, perhaps our community isn't working hard enough to reach them ? Just some rambling thoughts. I wish I had more time to spend on these matters. Unfortunately it's a time-consuming task, worse than setting up a Linux audio subsystem, and with probably even less satisfying results. ;-) Best regards, dp

Hi, much appreciated. You're welcome :) . But first of all we need the "big picture". [...] Forget it. The distros put packages together (that's their first job) and create installers and configuration GUIs. They do not help improving packages. We "simply" need to do the job - independent from any distro. It's like DMIX. It would have been easy to include it some time ago but they didn't. Now DMIX is part of ALSA per default and they say "Buy me I have now softwaremixing included". As if Mandriva or any other had written it... [...] Jep. Jep. But as told by another participiant, the mess is mainly valid for the Multimedia/Consumer desktop. Audio for the active musician is relatively simple. Install JACK, qjackctl and the desired apps and you're done. And desktop audio is a thing which has a minor priority for most of us. BUt I'd like to see that even consumers can benefit from the worthy work already done. [...] Jep. [...] Ithink that there will be no much active help from members of this community. Most people here are interested in software synthesis or similar digital audio work... [...] ...but this community is the right place to collect ideas and hopefully to design the big picture. If this community is not able to do it, noone will do it. [...] I guess that most people here do not want to spend time doing this work, and that's OK. Someone needs to do this work, and ask questions in this forum. That's all. [...] Best regards ce

Takashi once told me that DMIX was a bit buggy for some time, so I guess he didn't push it :) . Best regards ce

On Sun, 2005-06-19 at 11:34 -0400, Dave Phillips wrote: The best place to sort this out is probably http://freedesktop.org/ That is where GNOME & KDE agree on interoperability issues. If you can get GNOME & KDE to agree I'm pretty sure the distros would follow. It's just a matter of coming up with a good solution. (And remember GNOME & KDE are multi-platform - so I don't think GNOME & KDE apps can use ALSA directly.) My own preference would be for a single sound server that handled everything (e.g. by combining Jack and something like polypaudio). But I don't know enough to comment really. This thread from last year on a proposal to replace esd with polypaudio in GNOME may be interesting (especially Alan Cox's comments on security issues etc.): http://mail.gnome.org/archives/desktop-devel-list/2004- October/thread.html#00436 Damon

On Mon, 2005-06-20 at 14:40 +0200, Jens M Andreasen wrote: Of course they can use ALSA, but only indirectly via some cross-platform API (like jack/esd/aRts/polypaudio). Damon

At Mon, 20 Jun 2005 11:33:18 +0100, Damon Chaplin wrote: They don't have to use ALSA directly, but they can use a common library which uses ALSA directly like polypaudio. Takashi

On Tue, 2005-06-21 at 00:10 +0200, Christoph Eckert wrote: Maybe I am stupid and therefore I have to ask: What is the rationale for running KDE (or Gnome?) in an MS Win environment? --

On Tue, 2005-06-21 at 02:16 +0200, Joachim Schiele wrote: No, but honestly. I have friends successfully running their DAW under Win. Why should they change from the MS window-manager to KDE? To Gnome? (and given the choices you mention above, I would go for 'sex') --

It's geeky ;-) . Best regards ce

On Tue, 2005-06-21 at 10:36 +0200, Takashi Iwai wrote: I think he meant to ask "What do people still do that requires Windows at all". For me it used to be MS Office issues and binary only AV codecs, but both those problems have been solved. Lee

At 2:34 +0200 18/6/05, Christoph Eckert wrote: definitely not. there should just be 'working audio', whether your app is a desktop app, a sound-synth, or a DAW. why should there be a difference? -- ; Jay Vaughan

so what this really means, is a mass patch project to get all offending audio apps (OSS) in line with the New Linux Audio Reality. i don't see anything wrong with that. -- ; Jay Vaughan

On Sat, Jun 18, 2005 at 04:04:11PM +0200, Jay Vaughan wrote: Why are the terms 'consumer' and 'professional' used to denote two different worlds ? Because the requirements, expectations, price tags, and potential consequences are different for both types of user. As a professional, I may be inclined to pay some k$ for something that will enhance my business. As a professional I may be prepared to work to imposed quality standards, even if that is less entertaining or practical and requires discipline. Denying that this difference exists is a postmodern trend, but is misguided (IMHO). -- FA

On Sat, Jun 18, 2005 at 07:24:26PM +0200, Tim Goetze wrote: I can assure you that from a POV of a paying customer, the difference is neither obsolete nor arbitrary. It has little to do with equipment, training, skill, or competence. It's all about a different attitude taken to the work, and the consequences thereof. This means that some things that may seem 'utterly stupid' to an amateur will make perfect sense for a professional. -- FA

:) That's exactly the point. You do not care (and that's absolutely OK)... ...and you're happy with all the free software you got (just as I am).... ...but you still understand that others would like to see linux audio getting easier to use for others. Thanks a lot for these thoughts. That's exactly the point. Best regards ce

At Sat, 18 Jun 2005 20:59:11 -0400, Ivica Ico Bukvic wrote: I agree with the necessity of a ready-to-use setup for end users. But, I'm not sure whether asoundrc is the right place for this role. Obviously, we need a "central station" for all apps. This set-up should work with all apps without blocking or any unconfortable behavior. The set-up is, however, not only the choice of the soundcard, but it includes eventually the choice and set-up of devices. For example, the default I/O should support 5.1 output or SPDIF if user wants (I'm wondering why no one mentions about them.) So, what is the intuitive interface for configuring such a thing? The simplest would be a list of available cards and possible "presets". The system-configurator (it's pretty distro-dependent) lets users choose one of them for the default. IMO, this information should be in a common format. Then, for example, qjackctl can retrieve the info, list the possible cards/devices and pass certain start up options according to the selected item. You can configure WINE setup with it. You can choose a proper device with xmms... Well, this is a bit different topic from what Ico suggested above. OK, returning to the original topic. I don't quite understand what (1) would bring. Once dmix is set per default and sound servers use it, I don't think there is problems regarding sound server and exclusiveness any longer -- except for JACK. Then (2), it's more about with JACK: I think the scenario above would work indeed. We don't have a plugin to do such a job yet, but it should be easy to create. Suppose a new plugin which have a configuration like below: pcm.!default { type sequential pcms [ "dmix" "jack" ... ] } so that it will try to open dmix, jack, etc sequentially until it succeeds. Then non-JACK apps can work seamlessly, too, without changing configuration. Of course, there may be still bugs in ALSA <-> JACK conversion or whatever. But it can be technically solved. Takashi

At Mon, 20 Jun 2005 23:50:38 -0400, Lee Revell wrote: Yes, but it's usually also exclusive. If any processes occupy the device, 5.1 output can't be played. This may be a problem, e.g. if you start a video player from a web browser. But, switching 2.0 and 5.1 on the fly during the output is impossible in many cases, too. Thus, we have to choose either 2.0 or 5.1 as the system configuration, and let dmix running ether 2.0 or 5.1 mode. Of course, there might be other problems with this. (Who on the earth wants to hear beep with 5.1 speakers? ;) Agreed. Let's keep discussion there, then. I think this is relatively OK. It's just a warning and obviously the plug layer prevents the optimal performance with JACK. And if JACK is started automatically, user would notice it rarely, too... Takashi

this is utterly, 100%, arbitrary. 'pro' does not mean 'totally different way of doing things', nor does 'consumer' mean "the only lazy option". -- ; Jay Vaughan

Sorry, as Fons pointed out in his "+5 Insightful" comment, this should have been "not *un*overcomable", or even "*are* overcomable"... -- Tim Orford

At 18:03 +0200 18/6/05, fons adriaensen wrote: well, i work in the pro audio world, it is my bread and butter, and i can tell you that if Linux Audio goes in the direction of requiring 'two different configs' for whatever use you want to put your Linux-based DAW, then its not going to go very far. it should work like coreAudio: the Operating System, as is its job, does the hard and difficult work of making all sound system, cheap or not, look and work the same. the user shouldn't have to do -anything- more than just use the audio channels presented to them by the operating system. rabbiting from the hard work of making the operating system function as the operating system should, in my opinion, is where the misguidance is .. -- ; Jay Vaughan

If you're on KDE 3.3+, try these Setup/Options on qjackctl: [X] Execute script on Startup: `artsshell -q terminate` [X] Execute script after Startup: `artsd -F 4 -S 1024 -a jack -m artsmessage -c drkonqi -l 3 -f &` and optionally, for completeness sake: [X] Execute script on Shutdown: `artsshell -q terminate` [X] Execute script after Shutdown: `killall artsd` Cheers. -- rncbc aka Rui Nuno Capela rncbc(a)rncbc.org

that's the problem. Currently there's no "standard", but creating one would simplify life a lot for developers of any kind of audio output as well as for the BOING.WAV users. Currently a developer who wants to make an application straightforward needed various output plugins (OSS & ALSA direct access, esd, arts, gstreamer and JACK). Then an autodetection needed to be added which checks for the most suitable output plugin. No developer will do this, because it's very much work. BTW: For me ALSA direct access (and therefore blocking the device) seems to be a bit ugly for a multitasking and multi user operating system like linux is. Is ALSA direct access really an option (regardless that DMIX can help with this)? An desktop independent soundserver available on each linux machine could help a lot. JACK could be a possible solution. As soon as there was an auto detection, OK. But still I'd prefer a common soundserver for all applications and window managers. arts will soon be dropped and AFAIK both major desktops are looking for a common replacement. Gstreamer is one of the candidates. Best regards ce

I also had this idea some time ago. Some disadvantages: * Someone is needed who does this job * It added a further layer to the already existing mess * Many many applications need to be rewritten * It is a dirty hack regardless how well it will be written Yeah, but users want hardware as cheap as possible, even musicians. AC '97 doesn't offer hardware mixing, my terratec USB card doesn't and I'm not sure if the AC '97 successor HDA does. Why not? JACK even enables users to easily record a web radio stream while listening to it. Even normal users can benefit from it. CPU usage? Forget about it. Contemporary machines are bored while the user listens to ogg files while reading a web page (or even lenghthy discussions on LAD ;-) . Me too. I'd like to try kasound which has been released on sourceforge just these days (Thanks dp for the hint). I really dislike the OSS based applications. Thanks for your thoughts & best regards

Not entirely true, Sonar achieves very nice solid latencies with WDM and MME drivers (both of which are used for "consumer" purposes as well). Best wishes, Ico

Christoph Eckert wrote: If those devices aren't the same model, you can use the vid/pid options of the snd-usb-audio driver to force them to have a specific index. For example, my three USB audio devices have to following vendor/ product IDs: 0582:0007 Roland SC-8820 0582:0018 Edirol UA-1A 041e:3020 SB Audigy 2 NX I use the following options to put them at index 4, 3, and 7, respectively: options snd-usb-audio index=3,4,7 pid=0x0018,0x0007,0x3020 HTH Clemens

Damon Chaplin wrote: Have you considered Polypaudio: http://0pointer.de/lennart/projects/polypaudio/ The Ubuntu people are looing at replacing ESD with this one. In their scheme, Polypaudio would use ALSA's dmix rather than direct ALSA. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ "There is no reason why anyone would want a computer in their home" Ken Olson, DEC, 1977

Jay Vaughan wrote: I assume you've already seen my 18 articles (one per month) published on-line for the Linux Journal ? Or perhaps you've read the articles I've written for the hard-copy LJ, Linux Magazine-UK or the Computer Music Journal ? Every letter of that output deals with Linux audio (and even some video). It's almost all out there on the Net for anyone to find and read. It's certainly one measure of jwz's incompetence that he didn't bother reading any of it. The -facts- have been on the table for a couple years now, but if folks like jwz don't come to lunch you can't get 'em to to eat. This guy gives me the impression that he'd go to Bordeaux and bitch about the wine not tasting like Boone's Farm and having to use a corkscrew to open the bottle. "Fucking morons, what were they thinking ?! I can go to Wal Mart and buy a perfectly good bottle of BF that's got an easy-to-use screw-off cap, no fuss or muss, just get home, unscrew that cap and start guzzling. Now how in the world can those Bordeaux snobs think they can compare with that kind of ease of use ? A fucking corkscrew, for God's sake !" Frankly, guys like jwz don't do their homework for shit. It reminds of the guys I hear from for the first time who don't stint telling me how hard they've worked at this mess, *but* : They assume they don't need to read directions, they already know enough about the subject (soi-disant smart fellows). They don't correspond on the available mail-lists, blogs, and wikis. They don't seem very interested in actually solving issues, but they're awfully self-righteous about their bitch. Jay, I've lost track of the number of jwz types I've already encountered in ten years of using Linux. I'm sure you'd get a good laugh from the old press slagging the efforts of the developers of Mozilla, OOo, and even Linux itself. They all started with the premise that "[your hobbyhorse here] will never be [available | any good | viable] under [your OS of choice here]". Boilerplate crapola is not PR, it's a quick ticket to a writer's discredit. I read over jwz's blog and realized I'd read his stuff before now. His comments re: Linux video were useless, and his blog is a blowfest. He likes to emphasize his point by swearing and denigrating the work at hand. If that constitutes a methology for the respect due an "opnion maker" then I agree with Dave R and will add that the people who find jwz enlightening need to get out of the cave. To paraphrase the man himself, he's a fucking moron. Back in the Old Days we had a saying I've found quite useful throughout my life: If you're not part of the solution you're part of the problem. Linux audio has grown phenomenally over the decade I've been using it, but that ten years is only 1/3 the time commercial audio and MIDI software has been in development (I sarted using music software in 1985). Seen in a competitive perspective of course we're "behind", though I find it difficult to believe that someone can think of JACK and ALSA as "behind" anything similar in the Win/Mac world. Alas, I don't find this particular thread very interesting, it takes time from much more important things, and paying attention to someone like jwz simply perpetuates the problem. Unless I see evident proof that someone is actively and seriously trying to make things better (and make better things) then I'll send his or her bitchfests straight to /dev/null, right back where they came from in the first place. Such works have already been written and published by Daniel James, Alex Prokoudine, Matthias Nagorni, Frank Neumann, Aaron Trumm, myself, and others. Journals such as LJ, SoS, and Keyboards(DE) have run excellent articles about Linux audio. The third annual international Linux audio conference just took place in Karlsruhe. From my POV things are progressing nicely in the Linux audio world, and I can honestly say that jwz appears to have no influence at all within this community. Btw, I submitted the announcement of LAC2005 to Slashdot, but they didn't put it on their front page. The /. crowd is phenomenally ignorant regarding audio issues, and even woefully ignorant about the advances being made in Linux audio. I hoped that /. would want to help address that ignorance by publicizing the event, but I overestimated their editors perspicacity. OTOH Don Marti at LJ is intensely devoted to improving the situation and has told me that he'll run almost anything I send him. Upcoming articles include user-level looks at ALSA and JACK, a report from LAC2005, and a lengthy update on Csound5. Interesting that a general-purpose magazine should show so much more awareness than the more dedicated music merchandising magazines (Keyboard, EM, Guitar Player), but that's probably understandable in the light of their advertsing revenue streams (i.e., it does not behoove them to run articles dedicated to free music software). See above. Like on the ALSA Wiki, the MusE wiki, the linuxmusician site, in the articles I've written, or... ? Again I ask: Do you mean success like Mirror Image Studios, or like Fervent's Studio To Go, or like the AGNULA/Demudi and Planet CCRMA distros ? Or do you mean success like the hours of music made with free software that I've heard at the LAC ? Or does success here mean the software design achievements such as Common Music, Csound5, Ardour, ZynAddSubFX, et cetera ? Maybe jwz is not as savvy as he seems to think he is. Perhaps he is very knowledgable where screensavers are concerned, but he's not too bright in this particular domain. However, there's no way he's going to announce himself to his readership as a not especially bright guy where Linux audio is concerned, it doesn't fit his style, and he has a readership who expect him to behave in the way he's already defined himself. I don't get from him any sense of extending community, and as far as I can tell he just wants to become notorious. No-one here is lying about how they use Linux audio software. The proofs are in the dozens of recordings now available on line, listed in this and other mail-lists. You want to promote Linux audio software, you'll likely do the best job by producing and distributing a disc of music made with absolutely free software (I think such a project is already in the works). When the proof is so audible that even a jwz can hear it, then people will be more interested in learning how they too can achieve such results with free software, instead of listening to the rants of a fucking moron. Best regards, Dave Phillips PS: Jay, I hope you understand that this message is not a screed against your position or opinions. I agree with a much of what you've stated, especially regarding the need for even greater positive publicity, but I think that you may have missed a few things in your own background research while studying the Linux audio scene. Btw, I use Linux audio software daily here in my studio. I use it to arrange music for my students, to record my own music, to play and analyze music, and so on. My most heavily-used applications include Ardour, seq24, Hydrogen, Solfege, Snd, QSynth, ZynAddSubFX, TiMidity++, amSynth, XMMS, Common Music, Csound5, and of course QJackCtl. I also use a variety of other Linux apps for printing lyric and tab sheets, for tuning instruments, and for burning practie discs for my students. I also use vi, emacs, and OOo for my writing assignments and occasional coding. For my purposes Linux rocks hard and steady. Maybe if jwz had bothered to ask me for some help his experienecs might have been better. Neither myself nor my works are invisible, I'm not that difficult to find, and I believe there are even a few people on this list who might testify that I will try to help anyone who needs the assistance.

Hi, I just wanted to add what I think about the whole issue: Frist of all, jwz is fundamentally right with one observation: There is something wrong with the Linux-Audio Situation. You install the Operating System, you want to listen to some Sound, and it doesn't work. This is a problem. Period. I'm well aware that the Linux Operating System is propably the System with the most potential, the best Software, and above all it's free Software. The Pieces are all there. But: They've not been put together well. Apple Computers are not better because of some magical secret Ingredience, the Keyword is Integration, they control the hardware, they control the Software, come on, it's obvious that this Situation is a little simpler than the incredibly amount of random El-Cheapo Hardware, Linux is expected to run on. I'm actually amazed that there is still no premium Linux-Workstation Integrator that ships well selected Linux-Boxes with a custom Linux-Distribution that's exactly fitted to the Hardware. That'd be hard to beat. Other than that, I'm perfectly optimistic that sooner or later we (the free software people ;) ) will "beat" every non-free piece of software, therefore I don't see jwz's rant as a defamation, but as a challange to make even better Software :) Have fun -Richard

On Tue, 2005-06-14 at 20:55 -0400, Eric Dantan Rzewnicki wrote: That business model is as old as the hills (in Linux terms), in fact it was one of the first Linux based business models anyone came up with. VA Research anyone? Anyway, Paul Davis sells Linux digital audio workstations, check out http://www.linuxaudiosystems.com. Lee

Andres Cabrera &lt;andres(a)geminiflux.com&gt; writes: This is totally unacceptable (in my opinion) and it should not happen. It does not happen here (anymore). Versions?. -- Esben Stien is b0ef@e s a http://www. s t n m irc://irc. b - i . e/%23contact [sip|iax]: e e jid:b0ef@ n n

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Jun 14, 2005 at 09:33:45AM -0500, Andres Cabrera wrote: wow :) for anyone interested, development of a new core foundation dyne:II started and is to a good point already http://devel.dynebolic.org ciao - -- jaromil, dyne.org rasta coder, http://rastasoft.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Jul 13, 2005 at 12:15:31PM -0700, Iain Duncan wrote: glad to hear! it is getting easier to customize, still keeping a simple design. the main differences from before is that it will have a compiler inside and that it will be a multiuser environment. also i'm not going to be the only mantainer of the only branch available: there will be more dyne: versions. actually the first branch out of dyne:II is the pure:dyne project that the people at goto10.org is planning, for a slick and efficient dyne:bolic with an advanced PD setup. yes. as i said, now it already contains the tools to compile. newer glibc with NPTL and 2.6 kernel. I will post more technical specifications on the development pages in the upcoming days. ciao - -- jaromil, dyne.org rasta coder, http://rastasoft.org

We aren't there - not yet. [...] Still it's a bit difficult to set up a pro audio system because it needs kernel patching and various configuration work. As for the kernel patches we're optimistic to get a realtime patch in the vanilla kernel sooner or later. As for the configuration work we could need a replacement for alsaconf (which has done a great job in the past) called audioconf to configure cards, realtime patches and creating a JACK configuration file. It is. I know about it, that's enough for me :) . I also use the i82k. As for the USB card numbering, you can index your card. What's missing is auto-configuration to avoid manual work for common users, or at least a configuration help for unexperienced users, may it be CLI or GUI. You're invited to contribute ;-) . If I were you I'd cancel this offer. Otherwise we'll meet again in five years and you will not be finished yet ;-) . Frankly, save your time and better help us improving linux audio if you like. We have addressed several weak points in this thread, so there are many good starting points. Otherwise, all the characters of this thread have been temps perdu. [...] * Take a Distro (I use Gentoo and I'm just happy with it) * Stop all desktop soundservers * Start JACK * Start [Rosegarden|Hydrogen|ams|Zyn|Ardour|any other fun toy] * Enjoy Best regards ce

well, see .. to me .. MIDI precedes AUDIO in priority, time or otherwise.. otherwise, what is a music event but a description of that event, executed? from a purely musicians' standpoint, 1ms ought to be good enough for anybody. ;) of course, i reserve the right to change my mind, authority or none. no reason it couldn't happen this year. but, if MidiShare is the 'hidden API' behind a nice front-end, and Audio+MIDI events are happening when they should, who cares? don't ever forget, Stephane, you launched an API on the world. -- ; Jay Vaughan