Steve wrote: With Linux, the enthusiasts are the foundation. Without them (you) nothing would have been developed to the point that Linux attracted wider attention. To take it to the next step, it may take the involvement of profit making businesses. Profit seems to be the incentive in this society to make things solid enough for to offer a real (read: stable and useful) product. If we want to see Linux reach a wider audience, the enthusiasts will need to take roles in those commercial projects as developers, consultants and advisors, for without them the commercial projects won't get off the ground. So please encourage them to accept these roles in commercializing their programs. Len Moskowitz Core Sound http://www.core-sound.com

David, [Embedded comments at the end also.] I've been staying on the sidelines of this thread up 'til now. I'd like to add a users' perspective. I am not a programmer at all. I come at this totally from the point of view of a user. A little bit of this post might sound like a low-end rant, but mostly it's an opinion of someone that's used tools like this and spent a lot of time around other folks that do also. And, as always, the opinions are mine alone. I personally think it's a bit too early to start talking outside of an interest group like this. It's not too early to figure out what we're going to say, and figure out how we're interested in saying it, but to go out an bring people here before there is a toolset that really works is just asking people to be beta testers. If we're doing that, then let's be honest when we tell them. There is a really GREAT reason for people to start migrating somewhere though - 96KHz support. Everyone is worried about getting trapped in a close, expensive, buggy solution when they more to 96K. DigiDesign is really messing with the semi-pro guys. They know it, but they don't know what to do. That's why I'm here. I did start talking to people in the Pro Tools area about Ardour and too many people showed up that didn't know Linux, (like me!) couldn't fix the problems they were having, and went away saying Ardour has nothing to offer. They are not right, but they say these things and it turns other people off. I don't want to see that happen. It takes too long to recover. When speaking about tools from a users' perspective, be he/she a professional, a semi-pro or a home enthusiast like me, the thing that really matters is whether the tools do the job. I think your list below points up the one totally glaring problem with the Linux tools that needs to be address long before you go push people to look at this work. That problem is the lack of MIDI integrated to work with audio. Today we have some great MIDI apps coming along (Muse, Rosegarden, Midi Mountain) Ardour on the audio side, soft synths galore (although they are not all usable in an integrated way yet) loads of interesting plugins and jack to allow the audio to talk between apps. But, unfortunately, there's no way I know of yet to talk about all of the Alsa apps to users who want to replace Pro Tools, which is where I'm coming from. This needs to be handled in a convincing way before talking to people, or the negative press will be very hard to overcome. Here comes my little rant. The 'problem' here is that Linux apps are developed by very intelligent, well meaning, technical people who work on what they want to work on and not necessarily what's wanted and needed by the 'marketplace'. I think that some real program management is required. Look at what the market wants and needs, (audio, MIDI, soft synths, plugins, scoring, automation, etc.) write it down somewhere and then do an honest assessment of where Linux audio solutions are. If we have what the users need, then we talk. If we don't, then we put a program in place to make that stuff happen fast, so that when we do have it we can talk. Unfortunately, this would require the developers to respond more like work and less like a hobby. I don't know that they want to do that. <EOR> Beyond that, we need to handle the installation stuff much more cleanly. PlanetCCRMA is doing a great job of that for the Redhat platform. I know that many people wouldn't want to be forced into a distribution long term, but in the beginning many people who will come and try out this stuff won't be Linux users and should be directed towards a COMPLETE solution. Currently I think the Planet is the best I know of. As I don't want you to think I'm negative on what's going on here, I think there are MANY things that Linux could offer, but isn't even trying to talk about yet. Things like: 1) Real multi-processor support 2) Distributed processing where different apps are on multiple machines all working together 3) Remote access - all the application computers are in a different room and one very quiet PC is used in the studio to display their screens. No noise, but water cooling not required. 4) Much more stable platform. No reboots, no sad Macs, no BSODs. 5) More open hardware support, presuming someone ever makes the multicard thing understandable by those of us that don't have a PhD. in Alsa. Anyway, all said, I personally don't think money and bank accounts are the answer right now, but they may be helpful in the future, and I'd certainly contribute time and a bit of money to help things move along when we have a real plan. I just don't think we're thee yet. Actually, I think we don't even have a plan to have a plan yet, and that needs to be solved before anything will really work out right. Thanks for listening. I hope you got this far. Cheers, Mark -----Original Message----- From: linux-audio-dev-admin(a)music.columbia.edu [mailto:linux-audio-dev-admin@music.columbia.edu]On Behalf Of David Gerard Matthews Sent: Sunday, October 20, 2002 8:02 AM To: linux-audio-dev(a)music.columbia.edu Subject: Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter] At this point, I highly doubt that anyone is going to chuck their ProTools (TM) system in favor of Linux anytime soon. [MWK] I'm trying!!!!!!!!!!!! The thing that could do it is to have some killer apps - 90% of the functionality of say, Logic would be good enough - with free redistribution. [MWK] Yep! The caveat is that you have to have the right 90%! Jack is a very good thing, and once ardour achieves something resembling stable and truly usable status we'll be close. FreqTweak is brilliant, especially since it's jack-ified. PD already has Jack support, and a working version of SC will do wonders. [MWK] Great examples, but I'm not sure this morning what 'SC' is. However, not a MIDI app in the bunch yet, as per my comments above.

On Sun, Oct 20, 2002 at 02:50:19 -0400, David Gerard Matthews wrote: This might be true on the macro scale, "what we need is a complete DAW that does everything" ;) but I, personally have no idea what the average musician wants from plugins. My needs are pretty esoteric, and I'm trying not to flood the LADSPA scene with bizarre, special purpose plugins (belive it or not ;). Which brings me to my off-topic rant, I think its my turn again ;) Don't be afraid to criticise. I am very thick skinned, and wont be offended if you tell me that plugin X is crap, or should be different. Or something. Complain! Just because you're not paying me doesn't mean I don't care if it sucks. I have a bigish todo list, but some of the things on it are truly hard, however if what you want is easy, it will get done quickly, and if enough people want something I will be more motivated to pull my finger out. </rant> - Steve

David, Great thoughts. Thanks! Mark though - 96KHz support. The point: 44.1 and 48 kHz are going to remain standard for awhile, and the presence or lack of 96 kHz at this point doesn't seem to make or break a platform for most people that I know. [MWK] - I agree with you technically, but if I understand the point of this thread then marketing is the real issue. Everyone out there is thinking they're going to go to 96K. Any solution that comes out from now on will have some sort of support for it, and people think they need it to keep up. Linux can, and does, offer it. The cost is no worse here than anywhere else, and for a number of reason probably better. have some great MIDI apps coming along (Muse, Rosegarden, Midi Mountain) Ardour on the audio side, soft synths galore (although they are not all usable in an integrated way yet) loads of interesting plugins and jack to allow the audio to talk between apps. Fair enough criticism, I suppose. The list reflected my own personal needs and priorities, and I don't often use or care about MIDI. (I like old-school text-driven synthesis languages and graphical synthesis environments like PD and jMax.) [MWK] - Yep, we all look at this from our own perspective, me included. Linux give you tools to do that, but in my mind the discussion is about what most people want, and today most people are in the graphics based, Windows/Mac world. We need reasons to bring them over. I don't want to see things get in the way. developed by very intelligent, well meaning, technical people who work on what they want to work on and not necessarily what's wanted and needed by the 'marketplace'. True enough. One sees this in Linux across the board. I do, however, think that this is changing. Geeks and non-geeks can blissfully coincide. One does not need to give up emacs to use OpenOffice. [MWK] - Yep, I agree completely plugins, >scoring, automation, etc.) write it down somewhere and then do an honest >assessment of where Linux audio solutions are. I don't think lack of awareness is the problem. [MWK] Agreed The problem is that most Linux audio apps are developed by people who have full-time jobs doing other things. The problems involved in designing audio apps are so great that even those people who are able to work full time on Linux audio are often stumped as to how to implement the desired solutions. Everyone knows we need a decent midi sequencer, and I for one would love to have a truly usable notation program. Great. Just about everyone who knows how to develop such an app is working for one of the big companies, and you can bet they ain't going to open-source their code anytime soon. Guys like Paul Davis and Bill Schottstaedt do not have the benefit of a team of full-time codes who can help them solve the sorts of problems they face. [MWK] David, I more than agree, but when a new person looking for tools comes here because he read an article in Sound on Sound, he isn't going to accept that Linux developers have other things to do. He's going to make a decision based on his needs in a certain time frame. If what he's looking for is here, he becomes a user. If not, he goes away. The only real point I'm making is let's not over commit, and my thought on how to do that was in the original post. that >stuff happen fast, Suggestions as to how to make this happen? [MWK] First it takes a common vision about what we want. Do we want a single program like PTLE or Cubase SX, or do we want something more distributed? Is it possible to have both? I have my vision. Others undoubtedly have theirs. I'd be happy to try and set up some way for us to monitor, measure, track, manage something like this. Beyond that, it takes developers and users/testers getting committed to making it happen. Personally I think at least 80-90% of what we need is probably here somewhere. If I was running this as a business, my input would be that we need to choose a direction, find the pieces, figure out how to integrate them, find people who have some time to do it, and get started. >so that when we do have it we can talk. Unfortunately, >this would require the developers to respond more like work and less like a >hobby. I don't know that they want to do that. <EOR> Beyond that, we need to handle the installation stuff much more cleanly. >PlanetCCRMA is doing a great job of that for the Redhat platform. Yes they are. Nando rocks. Currently >I think the Planet is the best I know of. AGNULA is also a possibility. > As I don't want you to think I'm negative on what's going on here, I >think there are MANY things that Linux could offer, but isn't even trying to >talk about yet. Things like: >1) Real multi-processor support >2) Distributed processing where different apps are on multiple machines all >working together >3) Remote access - all the application computers are in a different room and >one very quiet PC is used in the studio to display their screens. No noise, >but water cooling not required. >4) Much more stable platform. No reboots, no sad Macs, no BSODs. >5) More open hardware support, presuming someone ever makes the multicard >thing understandable by those of us that don't have a PhD. in Alsa. Unfortunately Linux is no longer the only platform to offer all that. Mac OSX has all of the above, as well. >At this point, I highly doubt that anyone is going to chuck their ProTools >(TM) system in favor >of Linux anytime soon. >[MWK] I'm trying!!!!!!!!!!!! Great! But are we talking ProTools LE or a big ol' nasty TDM system? I could see someone ditching LE, but TDM users (and the highest echelon of the market is exclusively TDM, even if the software is not ProTools) have too much invested in the hardware. [MWK] There are reasons they will NEVER ditch those systems, but it has nothing to do with the sound. It's business. They see the Pro Tools (tm) name as a business advantage. They will, however, put a Linux box in place and use it if it works. >The thing that could do it is to have some killer apps - 90% of the >functionality of say, Logic would be good enough - with free redistribution. >[MWK] Yep! The caveat is that you have to have the right 90%! As I said before, the problem isn't that the developers are ignorant as to what the users want, it's that they don't really know how to implement it. [MWK] I sincerely hope that I'm not saying anything that would make you or anyone else think I believe the developers are ignorant. Far from it. They are amazing. However, if we have a vision of what we want to do, as we've been speaking of above, will they develop it? >[MWK] Great examples, but I'm not sure this morning what 'SC' is. However, >not a MIDI app in the bunch yet, as per my comments above. SC = SuperCollider. Formerly a proprietary MacOS app, recently GPL'd and ported to OSX, andthere's a project underway to port the OSX version to Linux. [MWK] Yes, Super Collider! It looks cool! -dgm

I'm looking at professional from the perspective that if you spend more than 20 hours of your time per week working on Linux Audio then you should be considered a professional. There are other factors that would qualify someone as a Linux professional. Just because you don't get paid in money doesn't mean it is not a job. Every successful organisation I have ever heard of has financial commitments. What makes us any different? If anything we have more of an obligation to provide a community funded intiative as money is not supposed to be the driving force in our motivation. Therefore we shouldn't care if we spend a little as a group. BTW. I was not suggesting that we advertise in SoS. I thought that quote had direct relevance to the target audience of who we would be advertising to. I have no definitive idea of where or what would be the best media to advertise. I have many ideas of what should be said though. DGM has mentioned SoS Electronic musician I would like to add google The independant The New York times What are some of the non english speaking possibilities? Steve you were wondering what the basic rate is for Sos. I think that is a good standard to work from. http://www.sound-on-sound.com/html/advert/adsos1.htm I believe firmly that taking control here will benefit all areas of Linux Multimedia and the community at large. Some of us have really been trying for a while now. I think they would have to do something if they were overwhelmed with success stories from our community. But that requires people to pull finger and actually write to the publications and inform them. A campaign along these lines could be extremely effective at gathering publicity. I will write something up as guidelines and add it to the openads site. However, remember a picture tells a thousand words. -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== "Um...symbol_get and symbol_put... They're kindof like does anyone remember like get_symbol and put_symbol I think we used to have..." - Rusty Russell in his talk on the module subsystem

On Sunday 20 Oct 2002 19:58, David Gerard Matthews wrote: [snip] [snip] So, we need to take a poll of the best architected open source example of each category of sound app and put it up in big letters somewhere so people can find it. Of course, the examples would have to be useable and useful at the point of being announced, otherwise time-poor hackers (like me) who want to spend their (scarse) time playing with the apps rather than debugging will go elsewhere. (I'm quite happy learning and extending TiMidity++ for example - it works well enough; I'm considering using it as a way of learning JACK but the learning curve compared with translating the esd support to artsd looks kind of steep ;-).) <rant> I also want to be able to do this on my current machine, a Celeron 400. Jack won't run - my machine's too slow. MPlayer won't run - my machine's too slow. But under Windows, WMP works, dropping frames quite happily. (TiMidity++, now I've learned how to tune it, works _better_ than under Windows. I don't _believe_ my machine is too slow. So I object to jack and MPlayer telling me it is.) </rant> -- Peter

On Sunday 20 Oct 2002 21:38, Kai Vehmanen wrote: Exactly. So why, having studied the docs, am I completely stumped with jack? It refuses to play. I don't consider any solution based on a piece of software _I_ can't operate suitable for general use. Yes, I'm big headed maybe: I frequently overlook the glaringly obvious. I frequently need the glaringly obvious carefully pointed out. However, jack isn't spotting it either so either (a) jack doesn't spot the glaringly obvious when it should or (b) it's not glaringly obvious. In either case, I reckon this justifies the view it's not suitable for general use. When I get time, I'll get over to the jack users list (if there is one). Right now, I don't _need_ jack working. -- Peter

While jack isn't intended for general use, it definitely isn't hard to use at all. It's a fantastic piece of software - easy to use (and even easier to write applications that use it). It's one of the best things that ever happened for linux audio. Perhaps Peter is having trouble getting jackd running? Try: jackd -d alsa That should get it running with the default parameters, and let you connect clients and hear them. There are also some example clients included with it. Good luck with it, Ian On Mon, 21 Oct 2002, Paul Davis wrote:

On Mon, 21 Oct 2002, Ivica Bukvic wrote: The problem is that OSS and ALSA based programs use the block on read/write metaphor that kills latency. That's why they need to be ported/rewritten to the non-blocking style. That jack forces the clients to do so could probably be considered it's greatest contribution. What needs to be done is for someone to implement alsa-server as a jack client. This has been gone over before, the solution was found (alsa-server), but no one did it. If latency is a choice for the user (and often it isn't) then they can pick their sound server. Jack is a no-compromise low-latency server. This is unnecessary. I often run xmms and ardour at the same time. Xmms doesn't talk to Ardour or Jack, but it doesn't interfere either. Of course, I don't hit play while recording or playing in Ardour. But companies write for ASIO. Certain software needs a promise of low-latency. Everything is about tradeoffs. The important design decision in jack was to work in lowlatency. Allowing for higher latency would compromise that decision. And that's almost besides the point. You can have higher latencies. I often run with a buffer of 8192. Horrible latency. But I never see an xrun. Well, that really depends on your system. Latency is tricky. Heck, digidesign only provides support on certain hardware configurations. You might want to look at PortAudio also, which has jack as an output. Taybin -- http://www.piratesvsninjas.com

does it occur to you that there might actually be something *good* about ASIO? that JACK might be trying to learn from what's good? and that as a result, JACK might have similar behaviour with respect to hardware design that ASIO does? does that make it an "ASIO wannabe"? the reason for not doing this is that there isn't manpower to do it. i am focused on JACK as the engine for a set of apps that i want to be able use (and i want others to be able to use them) in pro audio, real time, low latency environments. i don't have the hours (or the cash) to support the development of a "joe user" sound server. if you do, then please join the development team and help us out. RTcmix, as fabulous of a program as it is, doesn't meet my definition of "pro audio". actually, "pro audio" is a bad term. i should stick with stuff like "studios operated as profit-making entities and/or real time performance with a mixture of electronic and acoustic sound sources". i'll call SOPME/RTP from now on, OK? 1) who said "linux is supposed to be all inclusive"? who? 2) there has never really been much of an oss vs. alsa debate. i have never seen anyone suggest that oss was better than alsa, merely that it was expedient to use it because it was there. well, from 2.5/2.6/3.0, alsa will just "be there" too. so i suspect that that particular debate is about to evaporate, though alsa's continued support for the OSS API will not make it happen too quickly. 3) the esd/artsd thing was resolved in favor of artsd by the GNOME crew. KDE was already going with artsd. 4) gstreamer has nothing to do with JACK - its an architecture for streaming data *within* a program. i never said that not supporting JACK makes something a toy. i noted that most of the audio applications for linux are (1) written to use OSS and (2) are toys. there are thousands of links to such programs on dave's pages. the toys are fun, and often very useful. however, they are not viable candidates to act as the basis of SOPME/RTP for most people. as kai has noted, most of the apps i care about already have JACK support. from my point of view, its already moderately successful. how about this as alternatives to arrogance? * 3 kids, including one grumpy and irritable teenage boy, and two girls who fight endlessly. * a studio/office under construction * a house still requiring some basic stuff after moving in * a long list of bugs and TODO's for my primary software project * hardly any income (a few US$100's) ever derived from from linux audio work so far * 2 CD's of live performances to mix down * training for ultra-distance cycling racing * sleep, food, music, sex and books why should i be doing *anything* for "users" who aren't interested in paying me, aren't interested in what i'm interested in, and keep telling me they want things that i can give them but don't like the package it comes in? because the OSS API is so deeply *FUCKED* and makes this really hard to do without user intervention!!! how many times do i and others have to repeat this? why don't you just spend $US60 on a decent audio interface that supports hardware multiopen, and stop looking for software solutions? the trident cards are nice, simple, reliable and cheap. 32 hardware stereo streams. just like they won't touch ProTools TDM with a 20 foot pole despite it being certified for only a couple of wintel based systems and it requiring custom audio interfaces and other specific stuff? just like they won't develop for MOTU's MAS, despite it being a 100% proprietary solution that works only for MOTU systems? just like they won't develop develop for ASIO, despite only certain audio interfaces having ASIO drivers? i'm not here to do what you feel is obvious. i'm here to do what i think is the right thing to do and what satisfies my needs and plans the best. if you want to influence me then paypal is a few clicks away, but otherwise, exhortations about what users need will not accomplish very much. --p

yes, i think i wrote contradictory things. i sometimes do that. my original point was that JACK was not *intended* to replace other sound daemons. its design, its development process, its performance characteristics, its capabilities: all these were done with no attention paid to its suitability as a general purpose server. if it turns out to be useful for that, great. if not, its not a failure on our part. i do know what RTcmix is. i've used it. its a really cool program. its not the sort of thing i would use for RTP. if you do, thats great, but most of the people who are buying software for RTP are also not looking for software like RTcmix. csound is massively more capable of generating interesting sounds and music than reaktor and unity-ds1 put together. yet which one is "good for the commercial market"? a lot of good work has gone into making csound more useful to people without a background in assembler/fortran programming, and the core program continues to be extremely capable. that doesn't make it a good tool for "the commercial market". i defined my market as the SOPME/RTP world. if you want to point out that educational institutions are a bigger financial pie, thats great. the problem is that their needs and goals don't align with those of the SOPME/RTP world all that much. there are several computer music and audio technology departments and institutions around the country that do amazing work, both from a software and a musical perspective, but just like the stuff that emerges from computer science departments, very little of it ever sees the light of day in the rest of the world without a serious mangling, if not a complete rewrite. its an interesting market, full of a lot of smart and good people. so smart, in fact, that they have really smart people like fernando around who can not only compile and install ardour (as well as send patches), but also build the whole of planet ccrma in his copious spare time. such institutions might have reasons to send some grant money toward the LAD community, but they have lots of reasons to save money when they can, and they can save a lot by using their own inhouse expertise when it comes to free software. "hmm, we can spend US$8K on this ardour-based prebuilt DAW, or fernando can put on one of our stock audio-configured intel PC's and we pay nothing?" if you stick with the first clause of that sentence, i agree with you. but the second part: i have *never* seen anything but commemorative recordings of music that were made within education institutions. professional music making is done outside of such institutions, fostered by the education and research that is performed inside of them. the musical pieces that do emerge from the media lab, from ccrma and other places flutter briefly in the thin air of academic music appreciation, and then vanish back into the ether from which they came. meanwhile, hundreds of small studios around the country are recording jazz, country, blues, pop, rock, mesopotamian, carnatic, electronic, opera ... some of which will end up being sold to pay someone's salary. and a few times a week, some large halls and many more smaller ones will echo (sorry, reverberate) with the sounds of orchestras and smaller ensembles keeping alive the "serious" music of the past and the present. occasionally someone will use a computer in some capacity at one of these concerts, and occasionally what they do with might end up resulting in some kind of financial exchange that underlies "professional music making". ah, so that's a new constraint. did you try this under windows or macos yet? did you find any laptop that has a half-decent audio interface available? why do you think digigram and now rme and others are making the devices they are? my experience of motherboard-mounted audio interfaces is that they are universally utter crap. i don't have a laptop. i have tried to report to the best of my ability what we have learned about how to get the cardbus interface working (its there in the link from the ALSA card matrix). what needs changing has nothing to do with the driver, but is instead related to the kernel, the cardbus mgr software and the BIOS. one of the perils of the free software world is that its hard to find a direction to point one's finger in blame. this is definitely one of those instances. it is clear that the driver works (bar the warm reboot issue - even RME have no idea about that whatsoever), but its definitely not clear what has to be done to get the kernel's pci/cardbus/hotplug system to work smoothly with it. you're welcome to send patches. i don't have any CVS write access to alsa either, btw. the rme driver doesn't support software mixing only to the extent that alsa doesn't support software mixing. no alsa driver supports software mixing more or less than any other. software mixing doesn't fit into the alsa driver architecture in any way. people ("us") looked at the windows kernel mixer that people love for its transparent mixing of streams and noticed how much cakewalk, motu, steinberg and others hated it and lobbied microsoft to change it. they did, and those companies love the result, which is, suprise suprise, rather like ASIO and JACK in its "callback/interrupt-driven" design. those drivers don't support software multi-open unless someone writes with that in mind and creates "subdevices". its been the policy of ALSA not to do that unless it reflects a true hardware capability. some cards have multiple subdevices, but alsa never claims that a 10 channel card is really 5 stereo devices. you can use it as a stereo card, and that will permit multi-open, but this functionality is not part of the low level driver in any way - its all in alsa-lib and the infamous .asoundrc file. i wasn't complaining. my life is great. its also full. --p

On Tue, Oct 22, 2002 at 07:15:39PM -0400, David Gerard Matthews wrote: There have been success reports on linux-audio-user. Don't know how good/bad the latency is. -- Paul Winkler http://www.slinkp.com "Welcome to Muppet Labs, where the future is made - today!"

Ivica Bukvic wrote: That was the most useful part of this email. I've hoping that someone would port one of the Music N languages to JACK for some time, and I certainly do not have the skills do it myself. Thank you very much, Ico. I look forward to trying it out. -dgm

Kai Vehmanen wrote: Actually, this was exactly the thing I'd been hoping for, since I already know CSound and I'd have to learn RTCmix. I'm already using PD with JACK (beautiful!), am psyched about the possibility of SC on Linux (used the Mac version a few years ago), and am curious about SAOL. Thanks for the links! -dgm

On Wed, Oct 23, 2002 at 01:16:31 +0200, pdq808(a)t-online.de wrote: I've used both (both are available as RPMs from Planet CCRMA), and they are good, but I think that the plugin~ object is a bit awkward, and I couldn't express all LADSPA ports in message objects (some problem with spaces I think). Has anyone considered a plugin~ object where the LADSPA control ports are k-rate pd ports? Or or there good reasons for not doing it that way. - Steve

On Wed, Oct 23, 2002 at 08:09:24 +0200, Reiner Klenk wrote: OK, cheers, I probably just didn't RTMF enough. - Steve

On Tue, 22 Oct 2002, Conrad Parker wrote: But the second paragraph of the intro basicly already mentions the focus: --cut-- JACK is different from other audio server efforts in that it has been designed from the ground up to be suitable for professional audio work. This means that it focuses on two key areas: synchronous execution of all clients, and low latency operation. --cut-- -- http://www.eca.cx Audio software for Linux!

On Mon, Oct 21, 2002 at 08:51:01 -0700, Joshua Haberman wrote: I can't answer this properly, but there is some issue to with mmap mode I believe. It is a very small number of cards that dont work. Its fine, as long as it doesn't alter the design of jack. Theres no point adapting jack to suit the needs of consumer apps if it will increase the latency or make it less stable at low buffer siezes. Thats the reason it exists. There are plenty of alternatives for xmms type things, eg. MAS. It is a good idea (IMHO) for jack to have interface clients to some of these consumer port sharing systems, so you can seamlessly interface between them. Like the alsa interface Taybin mentioned. If you look at the interfaces of things like MAS, ESD and Arts, they are very different to jack. If someone writes an mp3 player, with a callback design and makes it realtime safe then theres no reason it can't be a jack client, c.f. alsplayer. - Steve

On Tuesday 22 Oct 2002 17:42, Paul Winkler wrote: I'd much rather have a list of current cards that work _well_ than a lists of cards that don't. The current ALSA card list just says whether or not a card has a driver (and the state of that driver). It doesn't indicate how well the card is going to work. I don't want to have to learn about DSPs and stuff to be able to identify a _good_ sound card. I've currently got a shortlist for my next machine: * MidiMan Delta Audiophile 2496 (Envy24) * VideoLogic SonicFury OEM (CS4360) * Creative SB PCI 128 (ES1371) I've read the specs and looked around various review sites. Nothing anywhere tells me how well they're going to work. Or does it? Am I failing to find some secret source of information? All these things just make life _easier_. I want to get on with developing code, not wondering why my hardware isn't performing. I don't _want_ to have to learn _that_ part of the system. Because I'll only need to do it once: when I spec the next machine. (The next time I spec a machine, everything I found out last time will be out of date.) -- Peter

* Kai Vehmanen &lt;kai.vehmanen(a)wakkanet.fi&gt; [Oct 22 02 16:09]: Actually, I've had terrible results with this. It could be due to the fact that it got pushed to a higher IRQ by my other card, however. --ant

* Kai Vehmanen &lt;kai.vehmanen(a)wakkanet.fi&gt; [Oct 22 02 16:45]: One of the intel, but forget what revision. Its actually builtin to some generic mobo (i.e. not laptop). The ALSA drivers were always after they fixed some major issues. I think it may have been more due to JACK which was no where near as reliable as it is now. I should try it again soon when I have time. Actually I never intended to use it for serious work, since the hiss is unbearable. --ant

On Tue, 22 Oct 2002, Peter L Jones wrote: Well, yes. ES1371 brings you 2ch in+out with max 48000Hz sampling rate, and 16bit sample resolution. Midiman 2496 on the other hands provides up to 96kHz sampling rate, 24bit sample resolution, 2ch in+out and digital in+out. Check the specs from manufacturer's site. And btw, I confused Audiophile with Delta44 (which I have, has 4ins + 4outs, no digital in/out). Both are based on the envy24 chipset, should perform equally well. Please, correct me if I'm wrong. Yup, I'll probably never get tired of the following slogan: "sb128 (ens1371) is the best creative card as it's the one they didn't make themselves". :) Ok, maybe the current SB cards are better, but I'll never forgive the company the disappointment their AWE64Gold caused me. Such waste of money! ;) Well, it depends on what you want to do. How many channels you need in and/or out, do you need high-quality recording, do you need digital ins/out, do you need hardware support for multi-open, etc, etc? I'm not a hardware expert so I can't answer to all these questions, but I can tell about the criteria I used when I selected my last card. My primary use is multitrack recording and mixing. I needed capability to record >2 channels, high-quality a/d and good support for low-latency and full-duplex. My choice was midiman delta44. It has 4 ins, an external a/d&a/d box (important for high-quality conversion), good ALSA drivers and wasn't too expensive (ie. a lot cheaper that the RME cards for instance). So far I've been very satisfied with this purchace. PS Let's cross-post to linux-audio-user. That and alsa-user are probably the best forums for this discussion. -- http://www.eca.cx Audio software for Linux!

On Wednesday 23 October 2002 12:49 pm, Bob Ham wrote: It's not the equipment you have that really counts.. it's what you do with it! -- My cat's a debugger.. Potter "ljp", Lorn core member Project OPIE- the Open Palmtop Integrated Environment http://opie.handhelds.org | http://www.opie.info (german) | http://www.opie.us IRC: irc.freenode.net #opie #opie.de llornkcor(a)handhelds.org

On Tuesday 22 Oct 2002 23:22, Kai Vehmanen wrote: My original pick was the Delta44 but I don't need that much I/O. All I'm currently doing is driving a soft synth (TiMidity++) from a USB MIDI keyboard. My current view, just starting out, is that I only need a single in for sampling and a single out for playback. For future use, digital i/o might be handy. I've come to the conclusion that putting a MIDI synth onto a sound card is a bad option - you can always find a larger set of samples you want to play with. So most of the grunt work is going to be on the CPU. Thus my main concern is that the card isn't going to slow the system down while it's processing the samples. And that the card doesn't prevent the CPU feeding it audio data as fast as it can play it. Mostly those are to do with system configuration rather than hardware, I think... Well, getting the positive feedback on the Envy24 is really good. Like you say, given the (relatively) low price on the 2496, I'll probably go with it to try for future proofing. I've kept them on the CC but I'm not subscribed - I'm currently struggling to keep up with LAD and ALSADEV :-(. -- Peter

On Wednesday 23 October 2002 11:51, Takashi Iwai wrote: ... it cost me a day of debugging to find out that my notebook with ES1983S (Maestro3i) chip does not work well with JACK. Sometimes all seems to be ok (no underruns) sometimes timing was horrible with lots of underruns. Tracing shows that soundcard interrupts (JACK callbacks) sometimes are just too late. Takashi, are you saying that this cannot be fixed because the driver does not get an interrupt on buffer empty? - ws

Takashi, thanks for these corrections! It'd be great to see yet more reports about successes, failures, suspected problems, etc, etc concerning different soundcards and chipsets on alsa-user (and other lists)! It's much easier to make purchasing decisions if you know that at least someone has had success with the desktop/laptop/soundcard model (and not just the chipset!) you're about to choose. On Wed, 23 Oct 2002, Takashi Iwai wrote: How is it different...? And do you happen to remember what notebooks (brand, possibly any IBM models)? Ugh, not good. Thanks for the clarification! -- http://www.eca.cx Audio software for Linux!

Hello, DRC generates digital room correction FIR filters to be used within HiFi systems in conjunction with real time convolution engines like BruteFIR. Changes in this release: two new parameters used to clean up the input impulse response have been added. DRC is available at: http://freshmeat.net/projects/drc/ Regards, -- Denis Sbragion InfoTecna Tel: +39 0362 805396, Fax: +39 0362 805404 URL: http://www.infotecna.it

On Thursday 24 Oct 2002 18:32, Kjetil S. Matheussen wrote: [snip] Kjetil, Thanks for that -- I'm planning on either the MSI or ASUS m/board but I forget currently whether the dual board have the built in audio (nevermind - good info anyway). I was thinking of keeping the ES1371 from my existing machine for low-end stuff, then remembered I might be getting built in audio, so it's good to know it's good enough. In fact, I may forego the Audiophile for now... -- Peter

actually, i'm not really as strict as i sometimes sound. yes, i think it would be great if JACK can eventually serve as a general purpose sound server (though an even better intermediate goal would be get to all apps to use a callback model). but i don't want to get distracted by that goal when there are still some very difficult issues standing in the way of 100% reliable operation at low latency settings. creating something that is a credible replacement for arts or esd etc. is a very different exercise than what we are focused on right now. one set of problems arise with consumer interfaces that don't keep their capture and playback streams in sync with each other. another set of problems comes from thos interfaces that don't allow mmap, but there are almost none of those in current production. another set of problems arise with cards that have unusual buffer size/division constraints. other than that, there's nothing about the way JACK uses ALSA that stops it from working (as Kai said) on pretty much any ALSA supported soundcard. almost any audio interface that someone who is "into audio" would use work excellently with JACK (and, not coincidentally, with ASIO). and guess what? if there is, you can get the source code and you can fix it (or reimplement the ALSA driver/client if its basic design is a problem). --p

On Tue, 22 Oct 2002, Peter L Jones wrote: Are you running JACK as root with "-R" or with "-R --asio"? Do these 50ms xruns occur even if you don't have any clients connected? If that's not the case, what client apps you have tested with? Also, do these xruns happen all by themself, or are you doing something at the same time (maybe moving windows or something). Does the HD led go on when the xrun occurs (kernel maybe syncing its caches)? What kernel, with low-latency patches, with pre-emption enabled or not? -- http://www.eca.cx Audio software for Linux!

On Tuesday 22 Oct 2002 22:10, Kai Vehmanen wrote: D'oh! Where _did_ the -R go in my jack script... Well, that sorted jackd out quite nicely. Now, onto why freqtweak locks out my machine... (Once I've tried a few more things... I'm likely to end up saying something foolish anyway, but I like to look like I'm trying :-).) -- Peter

Another reason for advertising (assuming we can choose the correct places) is that we increase our chances of the reporters being able to publish their yet to be written stories if we have a proven track record of supporting the publications. We scratch their back and they will be less resistant to scratching ours. I agree with Mark that we shouldn't be promoting Linux Audio as fully functioning because we will get a negative reaction which will be hard to overcome. There is definite scope for targetting the techies though. As long as we don't promote lies we will be doing a lot more for our image than most consumers expect from advertising campaigns. -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== "Um...symbol_get and symbol_put... They're kindof like does anyone remember like get_symbol and put_symbol I think we used to have..." - Rusty Russell in his talk on the module subsystem

Patrick, Nobody, me included, thought anyone would promote anything except the truth. We can certainly work on the plans and figure out what to promote, and when to promote it. I'm in need of a better MIDI setup first. If anything in the Linux environment could run along side of my Pro Tools setup, giving me what I need (instrument naming, better program changes, scoring, etc.) then I could just wait for Ardour to get there on the audio side. One step at a time with a vision of where we're going. Mark -----Original Message----- From: linux-audio-dev-admin(a)music.columbia.edu [mailto:linux-audio-dev-admin@music.columbia.edu]On Behalf Of Patrick Shirkey Sent: Sunday, October 20, 2002 1:51 PM To: Patrick Shirkey Cc: linux-audio-dev(a)music.columbia.edu Subject: Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter] Another reason for advertising (assuming we can choose the correct places) is that we increase our chances of the reporters being able to publish their yet to be written stories if we have a proven track record of supporting the publications. We scratch their back and they will be less resistant to scratching ours. I agree with Mark that we shouldn't be promoting Linux Audio as fully functioning because we will get a negative reaction which will be hard to overcome. There is definite scope for targetting the techies though. As long as we don't promote lies we will be doing a lot more for our image than most consumers expect from advertising campaigns. -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== "Um...symbol_get and symbol_put... They're kindof like does anyone remember like get_symbol and put_symbol I think we used to have..." - Rusty Russell in his talk on the module subsystem

On Monday 21 October 2002 13:29, Patrick Shirkey wrote: Yikes. While I applaud your conviction - I still don't quite get it. If you're collecting names and buying advertising space does this now make you an agency? And if so will you be collecting commissions at any point in the future? And can you prove this? Forgive my scepticism but I was brought up to believe that you don't ever get something for nothing. B

Patrick Shirkey wrote: Or did you mean "will I be asking people to donate money to help me advertise"? If that is the case I won't be asking for help with the google ad but donations won't be turned away. I am asking people to contribute to a larger fund specifically for advertising Linux Audio. I've already spent just over US$100 this year on the increased traffic from linking the LAU guide directly into the alsa website. I am in the process of writing up a full plan for how I see a community sponsored fund working. I feel that we are in a very important time right now which we can use as a launching point for increasing peoples motivation to get involved in Linux Audio. There are two major international events happening at the moment that are getting the target audience to question the established norms. We should be riding that wave as we have a really good concept that answers many of the questions. Open Source. I think many of the products are ready for people to use and especially contribute to. The problem I see is that most people are not ready for that because they have not been given the incentive to get involved. it's been said many times before that another way we could add serious clout to our image is having some high profile users. -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== "Um...symbol_get and symbol_put... They're kindof like does anyone remember like get_symbol and put_symbol I think we used to have..." - Rusty Russell in his talk on the module subsystem

Hi guys, Most musicians I know really don't give a hoot for what OS they run or indeed what philosophy drove the development of the apps. All they care about is if it will do the job better then their current setup at a cheaper cost. Piracy is rife in the audio world which means people can get their hands on pretty decent software. This is what they'll be comparing LAD with. For Linux to compete in the audio field, I believe it must be able to do a number of things including the following: 1. Provide an easy to use system that is exactly that 2. Provide 32bit support where possible 3. Have the ability to use DirectX plugins Sure, there is probably a lot more but I'm just gathering my thoughts here. What I'm afraid of is that LAD will end up with the same problems as most Linux distros suffer from: Bloat. Choice is good, but do I really need 7 text editors on my system? No. What I believe would benefit LAD, and correct me if I'm wrong, is to create a 'big picture', a complete DAW system. It should consist of AN audio editor, AN audio recorder, A sample editor, etc. Like I said, choice is great but musicians don't give a hoot about choice, they want something that works, not 7 things that are half done. If all effort was pushed in this direction, I believe we would end up with a quality system that the world would take seriously. I don't know if the 3 points I've made have already been done, I'm new to LAD, but they are important. Especially 3 as it gives a "migration path" to existing windoze users. I know, I know, DirectX plugins are written against Microsoft libraries, but how come mplayer on Linux can use windows binaries (codecs) in it's system? Could the same not be done for audio? Surely it's the same principle? (Media data input, process, media data ouput). Maybe I'm going over old ground here but I wanted to say something anyway. Isn't that what mailing lists are for? I know people who would move away from windows at the drop of a hat. They hate windows. High latency, instability... So how about it? An integrated system using your good talents. If you have a waveform in an audio recorder you want to double click to edit it, not drop out, load up a different program and then search around the directories for audio_track_3_guitar_take_7.wav. Stupid stuff like this creates a good user experience which in turn wins people. I have a ton of ideas for audio editing that aren't in the 'big name' apps and if I had the time, would code them myself (but I'm sure there are people who could do it in half the time here :). Aaanyway, that's my brain dump for today. Hope I didn't lose you on the way :) Cheers, -Lea. PS: There was no criticism intended in this post.

Len Moskowitz wrote I am. What's your point? If you are percieving this thread as me doing a plug for my site and business then I have not been specific enough about what I want to see happen. I have a small business and there are others out there in similar positions. We don't have the financial resources to fund large scale ad campaigns on our own. But we do if we work together. There are also plenty of people who might be willing to invest a little into a community run initiative if we can prove that we are not doing it for self serving purposes. Maybe these people would like to see us succeed. I want to tap that vein. Sorry if this is short but I find your comment a little on the short side too. If it's a joke then you got me ;] -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== "Um...symbol_get and symbol_put... They're kindof like does anyone remember like get_symbol and put_symbol I think we used to have..." - Rusty Russell in his talk on the module subsystem

On Monday 21 October 2002 20:21, Patrick Shirkey wrote: Oh well _now_ you come on to my pet subject. A while ago I got involved in a flamespat with the head honcho of AGNULA when I suggested that they should improve their communication with the rest of the LAD community and specifically with the development teams. I think we'd pretty much all like to know what's happening with AGNULA (apart from the minutes of their meetings) and naively I saw it as their job to tell us and be nice to us. While they do have selective communication with those that they consider to be key people I think my fundamental mistake was to actually think of AGNULA as an organisation. While it appears to be an organisation it's really just a tech project - it's run by geeks and it will aim to deliver some packaged apps and code in the time allowed. Once it's packaged it'll ship and LAD type projects will get exposure to the rest of the world through their distro. AFAICT that's the deal. While that's not a bad deal of course I think AGNULA should have more of a personality and a PR role with and in the LAD community. I've said in the past that I think it'd benefit "them" and "us". But hey. I'm not going to get on my hobby horse again over that one. No chance. No sir. B

Eric wrote: This is a misconception on your part. The general consensus is that the artsd, esd, gstreamer... servers are *very* useful just not for professional audio needs. I am pretty sure that people who only need to browse and hear mp3's at the same time have a fully functioning system with kde and gnome. Seeing as they are the standard desktops anyone who cannot install a different desktop would be even less likely to be playing around with professional audio. If they are trying to then they need to either learn how to use their computer more effectively like everyone else round here or get someone to do the work for them. If they want the latter thought they will have a hard time finding contact details because we haven't yet made a site that provides that info. LAD centric of course. I am working on it now and hope to have it finished in the next few days. At that time I hope the people on this list will use it as a resource. -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== "Um...symbol_get and symbol_put... They're kindof like does anyone remember like get_symbol and put_symbol I think we used to have..." - Rusty Russell in his talk on the module subsystem

So would it help to provide them with articles? Having lurked a while, i'd think generating more content would be very useful. Plus it would add to the general amount of information available. cliffw