Re: [linux-audio-dev] Re: image problem
* Ivica Bukvic <[EMAIL PROTECTED]> [Oct 22 02 20:16]: > I am thankful for Jack, but at the same time that does not mean there > should be no criticism. If you are referring to me criticizing Paul's > statements, then how do we dare criticize Linus Torvalds for letting OSS > happen? After all, he is the one who made Linux, without him Linux would > have never been. And since we use it, should we simply shut up and use > it with OSS? ;-) Theres quite some difference between constructive criticism and saying that something is broken or incomplete because it doesn't meet your needs, despite being told over and over that your needs were never the objective of the system in the first place or there is no manpower devoted to achieving what you want right now. I sincerely hope this thread can come to an end now or turn into something slightly less sour. So agree to disagree? Please? ;) --ant
Re: [linux-audio-dev] Re: The Image (usablity) problem from aMusicians point of view
John Lazzaro wrote: Lea Anthony <[EMAIL PROTECTED]> writes Wishing for people to write native apps for a system with no market is like wishing Windows would die. It might happen, but it's not bloody likely. However, if you port a novel Linux application to Windows or OS X, the users on those platforms are quite happy to add the free tool to their workflow if it helps them do their work better. This is how the GNU project got its start, after all -- free, usable software that ran on popular commercial UNIX platforms. Sfront has taken this route -- most of my users are non-Linux users now. I can think of some other examples: pd jMax (many users of those apps were looking for a free Max/MSP replacement, or had been using pd on windows) CSound CLM/CM (All of which started on Unices other than Linux, but hey) There is also a growing degree of overlap between people running OS X and Linux. Many people I know have or have access to both platforms, and an eye towards OS X portability might be something *some* (I did _not_ say all or even most) developers *might* (I did _not_ say should) keep in mind. -dgm
Re: [linux-audio-dev] Re: The Image (usablity) problem from aMusicians point of view
Paul Davis wrote: (*) of course, no public release of nuendo for beos, or (i think) even nuendo for irix, has ever took place. Rather unfortunate, in many ways. I love Irix, and and you would think it wouldn't be too hard to port the Irx code to Linux. -dgm (Who has been searching for a copy of Irix for Nuendo for the last few years so that he would be able to justify buying that used O2 he fantasizes about every now and again)
Re: [linux-audio-dev] Re: The Image (usablity) problem from a Musicians point of view
> Lea Anthony <[EMAIL PROTECTED]> writes > > Wishing for people to write native apps for a system with no market is > like wishing Windows would die. It might happen, but it's not bloody > likely. However, if you port a novel Linux application to Windows or OS X, the users on those platforms are quite happy to add the free tool to their workflow if it helps them do their work better. This is how the GNU project got its start, after all -- free, usable software that ran on popular commercial UNIX platforms. Sfront has taken this route -- most of my users are non-Linux users now. I think there's a migration path to Linux that could be based on this strategy -- if the free software community comes up with a set of audio content-creation tools that Windows or OS X users are willing to use as a complete workflow, the case for switching over to Linux to run the workflow more efficiently (or to avoid OS license upgrade fees, etc) is easier to make. Certainly on the CLI side, many people started out at Cygwin users to run emacs and gcc and TeX under Windows, and then decided to add a dual-boot option for Linux to get "the real thing." - John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -
RE: [linux-audio-dev] Re: image problem
You're right, I need a coffee break :-). But before I do that... > i think everyone appreciates food for thought, but (at least to me) the > wording of some of the opinions in this thread was rather suboptimal and > might easily provoke some strong rhetoric in defense. > let's just all take a deep breath and stop the jack bashing. No one is bashing jack and constructive criticism never hurt anyone. Just because it's not shrink-wrapped with cherry and whipped cream on top, it does not mean it's somehow geared towards bashing. If I had time to talk with Paul in person, I am sure I'd choose a smoother way of expressing my concerns. But on mailing lists, I don't have the time to proofread and make every statement of mine a Shakespearen creation of thousand words. (yet I am here ranting and ranting away... oh, well...) > this thread has some ugly similarities to the "reborn" flamefest and > that curious religious EULA of nasca's synthesizer: it's criticizing > *people* for something we wouldn't even have if not for those very same > people. I am thankful for Jack, but at the same time that does not mean there should be no criticism. If you are referring to me criticizing Paul's statements, then how do we dare criticize Linus Torvalds for letting OSS happen? After all, he is the one who made Linux, without him Linux would have never been. And since we use it, should we simply shut up and use it with OSS? ;-) Now, onto that coffee... Cheers! Ico
Re: [linux-audio-dev] Re: The Image (usablity) problem from a Musicians point of view
>Wishing for people to write native apps for a system with no market is >like wishing Windows would die. It might happen, but it's not bloody >likely. steinberg committed to neundo on beos when beos had even less market than linux does now (*). so did several other companies. one of them, iZ, even went so far as to base an entire product (the RADAR HDR system) around that OS. --p (*) of course, no public release of nuendo for beos, or (i think) even nuendo for irix, has ever took place.
Re: [linux-audio-dev] Re: The Image (usablity) problem from aMusicians point of view
This is the same issue as with Linux Games. Does wine hurt or help? Well, here's my take: If Linux doesn't run the software they're used to then they wont use it in the first place. Once there is a marketbase, then the NEXT generation of stuff would be written natively as they would see that it gives them more benefit. Wishing for people to write native apps for a system with no market is like wishing Windows would die. It might happen, but it's not bloody likely. -Lea. On Tue, 2002-10-22 at 11:23, Steve Harris wrote: > I'm not sure this would be a great idea. It looks good to say we support > 90% of DX plugins (or whatever), but it might just disuade developers from > porting to native linux binaries. You can bet DX emulation would be slower > and less reliable than native Windows, giving the impression that Linux > was slow and unreliable. > > Given that many of the respected plugin developers allready release for > Windows, Macos and TDM, I dont think they would have a problem with adding > Linux to that list. Not that there is an API for them to port to, but that > is another matter... > > - Steve >
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]
On Tue, Oct 22, 2002 at 04:26:41PM -0700, Paul Winkler wrote: > On Tue, Oct 22, 2002 at 07:15:39PM -0400, David Gerard Matthews wrote: > > I can certainly sympathize with that one. Supposedly there is some work > > being done on supporting > > USB audio devices under ALSA; that may be our best hope. (Yes, I know > > USB has potentially > > horrible latency. ) > > There have been success reports on linux-audio-user. > Don't know how good/bad the latency is. Forgot to mention, this is with current alsa. cvs or latest release should do. -- Paul Winkler http://www.slinkp.com "Welcome to Muppet Labs, where the future is made - today!"
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]
On Tue, Oct 22, 2002 at 07:15:39PM -0400, David Gerard Matthews wrote: > I can certainly sympathize with that one. Supposedly there is some work > being done on supporting > USB audio devices under ALSA; that may be our best hope. (Yes, I know > USB has potentially > horrible latency. ) 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!"
Re: [linux-audio-dev] Re: image problem
hey, stop whining. your contributions are very welcome and respected. as to your *feature requests*, well, go ahead and implement them or find someone who does. i think everyone appreciates food for thought, but (at least to me) the wording of some of the opinions in this thread was rather suboptimal and might easily provoke some strong rhetoric in defense. let's just all take a deep breath and stop the jack bashing. this thread has some ugly similarities to the "reborn" flamefest and that curious religious EULA of nasca's synthesizer: it's criticizing *people* for something we wouldn't even have if not for those very same people. which i think is stupid beyond comprehension when you look at it from a distance. sometimes it just seems to evolve from discussions which started with good-willing suggestions, and nobody notices... it feels like time for a coffee break to me. Ivica Bukvic wrote: > > > This is a fair question. First, "many people" might promote OSS, but > that > > doesn't mean unconditional surrender. ;) I mean, I was really quite > > offended by Ivica's message where he proposed that JACK developers are > > arrogant if they don't implement x and y. OSS or not, that's not very > nice > > considering how much free time we have spend on this. > > And what do you think how do I feel when I contribute to this community > with my apps (which certainly are nothing even close in scope or quality > to Ardour, but are my best and most honest shot at it), spend most of my > time promoting Linux, conceiving a Linux & Multimedia class at my > University and teaching it, convincing my mentor that the Linux is the > way to go by purchasing new Linux machines, and evangelizing > Linux/Alsa/Jack among my peers, and all this without any compensation > whatsoever? Do you think my time is any less valuable than yours? > > Besides, I was, and still am the advocate of Alsa. But even Alsa > supports OSS apps (to some extent), so I have no clue as to why you are > placing me in the OSS camp. If you read my post carefully, you'd realize > that I am talking about good quality apps that will simply not be usable > with Jack framework which is a shame, and as such would limit user's > ability to unlock the full potential of Linux audio... > > The arrogance I spoke of you managed to misinterpret rather well. What I > spoke of is the fact when addressing this issue to Jack developers, you > get cornered into a situation where you are "damned if you do present > the issue, and damned if you don't" while at the same time Jack > developers simply suggest the impossible: why don't you port all those > 1000+ apps to Jack? So if I come out with a suggestion, then I get > flamed all over for it, but if I keep quiet, then I cannot use it for > what I need it for. > > If that did not come of as described above, then I do apologize. > > Every wish for contribution that came from my mouth was in a form of > suggestion/criticism/request for a feature, because that is the most > comprehensive and quickest way of presenting the case. After all, > stroking egos will not make Jack any better... Every one of those was > met with a strong opposition and defensive behavior. I want to > contribute, but if the project developers to whose project I want to > contribute to marginalize my suggestion for contribution, then what's > the point? > > Ico -- Jörn Nettingsmeier Kurfürstenstr 49, 45138 Essen, Germany http://spunk.dnsalias.org (my server) http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)
RE: [linux-audio-dev] Re: image problem
On Tue, 22 Oct 2002, Ivica Bukvic wrote: >> offended by Ivica's message where he proposed that JACK developers are >> arrogant if they don't implement x and y. OSS or not, that's not very nice >> considering how much free time we have spend on this. > And what do you think how do I feel when I contribute to this community > with my apps (which certainly are nothing even close in scope or quality > to Ardour, but are my best and most honest shot at it), spend most of my Btw; I'm not involved in any way with the Ardour project, and there are also others in the same position involved in JACK development. Who knows, maybe you and I might share some common goals with regards to future JACK development. There might be also others. But with the messages like the one I have referred to above, you are just burning bridges. > Besides, I was, and still am the advocate of Alsa. But even Alsa > supports OSS apps (to some extent), so I have no clue as to why you are > placing me in the OSS camp. If you read my post carefully, you'd realize > that I am talking about good quality apps that will simply not be usable > with Jack framework which is a shame, and as such would limit user's > ability to unlock the full potential of Linux audio... Ok, let's try to calm a bit. Facts about this issue: 1) most JACK developers have nothing against a OSS-to-JACK or ALSA-to-JACK bridge; in fact, most would like to see one 2) there is real technical problems involved in implementing (1); we will never be able to demonstrate JACK's best features with apps using (1) 3) there are currently real technical problems getting native JACK clients to run well enough 4) we must get JACK to perform well enough with _some_ clients, so that we can demo and market it to developers 5) (4) is not going to happens with bridged (1) apps, so we are currently focusing all our energy to (1) 6) Paul has done most of the work involved in (5) and this might shine through from his recent messages ;) 7) even though Paul is the project leader, there's a community of users and developers behind JACK 8) we don't have a central pr-agency; not everything said and written by a person involved in JACK represents the opinion of all involved developers and users 9) if someone implements (1) in a way that doesn't compromise (4) (which we absolutely need to achieve), most JACK developers (but remember (8) ;)) have nothing against it ... ok, that should settle it. :) -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help fora levelmeter]
Paul Davis wrote: 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. LADSPA plugin out there... Yet you say it's no good for commercial market... Hmmm... 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". Ah, so what it all boils down to is a cultural difference. :) Seriously, Ico, Paul's right on this one. I'm also involved with the creation of academic/experimental/avant-garde electronic music, and I love and use CSound and PD and things of that ilk. But I would never recommend trying those tools to anyone running a commercial (better word than "professional", IMHO) studio. You want to talk about a steep learning curve? The commercial audio world always prefers convenience over flexibility. I don't doubt for a second that a RTCmix wizard can probably do things with just a RTCmix that would require a "pro" audio engineer to use a dozen racks of outboard gear. But different trades have different tools. (Personally, the music I'm working with these days would probably be best served by a big ol' analog modular synth with 128 sine wave oscilators. I can't afford such a beast, so I use software synthesis.) If you knew anything about the market, then you'd realize that as many SOPME/RTP studios there are in the world, they don't stack up to the amount of money educational institutions spend on building their electronic music studios, and this is where apps like RTcmix are an equal concern as Protools (even the university this list is hosted on True. It is only in such places that audio on *nix has ever had any impact until recently, and it's also true that we had digital audio and synthesis when the rest of the world still thought C64's were neat. (Disclaimer: I thought my C64 was pretty neat in 1982. Disclaimer to above: It was 1982, and I was 6 years old.) 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 anything, at this point the academics are more likely to use commercial stuff than vice versa, by a large margin. There may still be a few departments without ProTools systems, but they're pretty rare. I've gone on record on this list saying that midi is pretty much useless to me, but I do want and need a good multitrack DAW and some good plugins. To draw a parallel: only a small portion of all computer users have use for a text editor like vi or emacs, but most of the people who use such things also want a WSYWIG word processor. of the INDIVIDUAL University studios in the US spend over $100,000/year for the new equipment/software. How much do the SOPME/RTP spend once they equip it for the first time? Depends upon how profitable they are. Also, I don't know which universities you've been hanging around, but music departments around the world are suffering budget cuts. Yes, this is more likely to incline them to Linux as a possible solution, but that would entail Linux-based machines actually costing less to deploy. 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 e
Re: [linux-audio-dev] [ann] unmatched - a LADSPA amp tone
On Tue, Oct 22, 2002 at 09:38:26 +0200, Tim Goetze wrote: > the problem with converging IIR is that either the IIR or the > converging algorithm or both don't like impulses that are too > lively. the converger will simply fall dead when it sees an > exponentially decaying white noise impulse. it makes sense, I don't understand why. Is it just beacuse the kernle is a bit too long to be stable, or is there someting more to it than that? > what i don't get about the valve (the rect influence seems > negligible) is that it only shapes the negative portion of a > sine. without a LP, there's faint aliasing. it doesn't sound > so bad though, in fact i like it. Thats because its only odd harmonics (or is it even?). It should be follwed by a DC offset remover. This is pretty normal for a tube simulation. The aliasing is because I never got round to oversampling the valve. It needs some more optimisation to make that a good idea, and LP filters are so much easier ;) > however i'm into harsh distortion now, and have fed the fender > three sines from zero to full gain (three octaves of 'c'). > the shaping it does has some important properties that i'm only > beginning to understand, but it really does look fundamentally > different. it seems to self-oscillate at the zero-crossings, > and otherwise compresses the sine much like your valve does, > only the output signal is not a straight line where compressed, > but rather another irregular but smooth oscillation about a DC > value. a (realtime) electric circuit simulator would come in Hmmm... I'm quite out of my depth here, but could this be a class B effect I'm not correctly modelling? I suspect a class B crossover discontinuity, effected by the mostion and mass of the speaker cones (pretty high for a guitar amp I'd guess) could look like that. Any chance of a short sample, to make sure I'm thinking of the right shape. Infact, this should just happen, if you use the crossover plugin and put the output through your speaker cone IIR you should see a similar shape, as the LP characteristic of the IIR damps the abrupt 0 sticking point from the crossover. - Steve
Re: [linux-audio-dev] [ann] unmatched - a LADSPA amp tone
On Tue, Oct 22, 2002 at 11:44:42PM +0100, Steve Harris wrote: > On Tue, Oct 22, 2002 at 10:40:23 -0700, Paul Winkler wrote: > > Everybody should have at least one good dynamic mic! > > I've got a Sennheiser 421. An EV RE-20 would be even nicer. > > I have an EV dynamic mic, but it is a vocal mic of some kind, and it has > seen better days, the grill thing round the ouside is dinted and rusty! I said "good". :) There is a world of difference between an RE-20 and most dynamic mics. A few other cool ones are AKG-D220/222/224 (hard to find) and Sennheiser MD-441 (a bit fragile and very expensive). Unlike your average stage vocal mic, any of these can make a useable recording of most source sounds: vocals, drums, amps, acoustic instruments, animals, trucks --PW, refugee from rec.audio.pro Paul Winkler http://www.slinkp.com "Welcome to Muppet Labs, where the future is made - today!"
Re: [linux-audio-dev] [ann] unmatched - a LADSPA amp tone
On Tue, Oct 22, 2002 at 08:01:35 +0200, Tim Goetze wrote: > >to do it. How do you generate the impulse? (I've tried simply creating > >a sample with 1 frame at maximum followed by zeroes, but this seems > >not to make it through the D/A conversion - it comes out as dead > >silence.) > > maybe widening the pulse will help. steve? i've yet to take one That would require deconvolving anyway, so you may as well got for the chirp (swept sin), many epopel say there better for things like amps anway, and you should suffer less from the DA converter. - Steve
Re: [linux-audio-dev] [ann] unmatched - a LADSPA amp tone
On Tue, Oct 22, 2002 at 10:40:23 -0700, Paul Winkler wrote: > Everybody should have at least one good dynamic mic! > I've got a Sennheiser 421. An EV RE-20 would be even nicer. I have an EV dynamic mic, but it is a vocal mic of some kind, and it has seen better days, the grill thing round the ouside is dinted and rusty! It was never that sensitive anyway. My preffered mic is a big ugly black octava condenser. > > I never thought of a baloon, I was going to try a kids cap > > gun. > > Didn't think of that. People often use starter pistols, but I think that would be seriously unpleasent in a small, concrete tank, and they are hard to get hold of. You have to deconvolve them, which requires getting an uncouloured recording of the pistol, which is probably also hard. > Balloon pops probably have some coloration, but they're much stronger and > probably less colored than handclaps... I don't have a spark-gap > generator--I don't even know what it is really, but I've heard > those are the "proper" tool for acoustic impulses. Accoring to google, a spark-gap generator is a bigish dangerous looking van-de-graff type thing. Hmmm... impulse gathering death sports ;) The circuits look pretty simple, but I'm not safe with soldering irons. - Steve
Re: [linux-audio-dev] Re: latencytest problem with 2.5.44-mm2
Benno Senoner wrote: > > Hello Joern, > Are you using ALSA right ? i think so :) > Perhaps an OSS emulation problem of ALSA ? unlikely. if i use "play" on the very same file i use for latencytest, it plays ok. afaik, play is oss, so my oss emulation seems ok. aplay also works. > I recall that I got grabled sound (even lockups) on the SBLive > when using 128byte fragments (seemed like a driver or hardware problem). > What kind of audio card do you have ? sblive. fun thing is, it used to work with kernels before 2.5.44 ok, maybe the kernel just performs horribly, *BUT*: i run do_tests, the sound is horrible, but when i aplay the same soundfile *during the test*, i can hear clear audio over the garbage (sblive does hardware mixing). > Anyway latencytest is completely outdated (does not compile cleanly > on newer distros due to wrong includes etc). > Now that I have some spare time again (seems unbelievable but I were > able to finish my university degree in CS just a month before turning > 30 ... better late than newer as we use to say :-) ) > I'll try to rewrite some of the useful tools including latencytest, > adding alsa support and new stress test methods and like one guy of the > list asked , the possibility to chose the disks (or the path) on which > perform the disk i/o tests. as i said, what irritates me is it used to work a few days ago... > Anyway low latency came useful in my thesis since a part of the project > consisted in a real time laser scanner that tracks a laser spot that > you move over the object you like to scan that is filmed by two cameras > that permit a 3D reconstruction of the surface. > (at 25 FPS we have processing cycles of 40msec so it is quite easy for > the low lat patch to keep up since there is basically no disk i/o > present during the scanning activity). it would be most welcome to have a reworked latencytest program. now that 2.5. is almost into feature-freeze, we need to jump in, run tests and bug the kernel guys for latency optimization. i fear most of the tweaking has been to maximize throughput, which does not buy us much for audio... best, jörn -- Jörn Nettingsmeier Kurfürstenstr 49, 45138 Essen, Germany http://spunk.dnsalias.org (my server) http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)
Re: Music N style sw w/ JACK-support (was: Re: [linux-audio-dev] Re:image problem)
Kai Vehmanen wrote: On Tue, 22 Oct 2002, David Gerard Matthews 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 Just in case you are not aware of these: - icsound has JACK-support -> http://agnula.org/~maurizio/icsound/ 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 - there's patch for PD that provides JACK-support -> http://sourceforge.net/mailarchive/message.php?msg_id=1169519 - supercollider's alpha version for Linux has JACK-support -> http://www.cs.tu-berlin.de/~kerstens/pub/SuperCollider3-linux.tgz - Paul Winkler has written a JACK driver for SAOL/sfront -> not yet released, mail Paul :) PS Nopes, it's not just alsaplayer, ardour and ecasound anymore. ;)
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]
>Then explain it this way, and do not contradict yourself by initially >saying Jack will never replace other sound daemons, and then mention 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. >electronic and acoustic sound sources," so obviously you have no idea >what RTcmix is. Sure, it did not have a fancy gui (although that just 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. >LADSPA plugin out there... Yet you say it's no good for commercial >market... Hmmm... 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". >If you knew anything about the market, then you'd realize that as many >SOPME/RTP studios there are in the world, they don't stack up to the >amount of money educational institutions spend on building their >electronic music studios, and this is where apps like RTcmix are an >equal concern as Protools (even the university this list is hosted on 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?" >of the INDIVIDUAL University studios in the US spend over $100,000/year >for the new equipment/software. How much do the SOPME/RTP spend once >they equip it for the first time? >> 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. > >But are commonly used in educational institutions for professional music >making purposes. 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". >> why don't you just spend $US60 on a decent audio interface that >> supports hardware mu
Re: [linux-audio-dev] Soundcard spotting
On Tue, 22 Oct 2002, Peter L Jones wrote: >>> * MidiMan Delta Audiophile 2496 (Envy24) >>> * Creative SB PCI 128 (ES1371) >> I've used both of these extensively with JACK and numerous other ALSA apps >> and they work really well (full-duplex, low-latency use). Other > Heh. Now, one of these I have in my machine ((PII vintage) Celeron 400) > already. The other would set me back £150. Your comment makes me think > there's little to choose between them. So, simply upgrading my soundcard > from a £15 low end consumer-oriented unit to something costing 10 times the > price looks like getting me nothing. Or am I missing something? :-( 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. >> - GUS MAX (this very, very old ISA-card can still beat a number of >> today's crappy chipsets... I don't know whether to cry or laugh ;)) > I noticed that the ENS1371 seems to have a better rating on one site I looked > than to EMU10K, so this doesn't surprise me! 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! ;) >> All in all, most of the PCI-cards supported by ALSA have fairly good >> drivers. > But how do I compare one card with another? What should I be looking for? > How can I tell which will reduce the load on my computer and which will > increase the load? Is there any difference? 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!
Re: [linux-audio-dev] good cards/chipsets for full-duplex/low-latency audio
* Kai Vehmanen <[EMAIL PROTECTED]> [Oct 22 02 16:45]:
> Btw; this a very interesting topic. Please, tell about your
> experiences. By discussing these things in a public forum,
> we are actually creating a nice searchable knowledgebase
> for all current and future ALSA users!
>
> On Tue, 22 Oct 2002, Anthony wrote:
>
> >> - snd-intel8x0 (nice chipset, is suitable for low-latency use)
> > 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.
>
> Hmm, what laptop/soundcard and what version of ALSA (the dma routines were
> rewritten quite recently)? It's true that intel8x0 is used quite a few
> different laptops/cards [1], so it's possible that not all work as well as
> I've experienced, but as it's in any case the same driver on the audio
> side, these problems shouldn't be common.
>
> [1] {Intel,82801AA-ICH},"
> "{Intel,82901AB-ICH0},"
> "{Intel,82801BA-ICH2},"
> "{Intel,82801CA-ICH3},"
> "{Intel,82801DB-ICH4},"
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
Re: [linux-audio-dev] Soundcard spotting (was Re: image problem [was Re: [Alsa-devel] help for a levelmeter])
On Tuesday 22 Oct 2002 22:07, Kai Vehmanen wrote: Kai, Many thanks for the reply. > On Tue, 22 Oct 2002, Peter L Jones wrote: > > 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) > > * Creative SB PCI 128 (ES1371) > > I've used both of these extensively with JACK and numerous other ALSA apps > and they work really well (full-duplex, low-latency use). Other > soundcards/chipsets that I've used: > Heh. Now, one of these I have in my machine ((PII vintage) Celeron 400) already. The other would set me back £150. Your comment makes me think there's little to choose between them. So, simply upgrading my soundcard from a £15 low end consumer-oriented unit to something costing 10 times the price looks like getting me nothing. Or am I missing something? :-( > - snd-intel8x0 (nice chipset, is suitable for low-latency use) > - snd-cs4281 (good for low-latency although has a max two-interrupts > per buffer limitation which can confuse apps) > - GUS MAX (this very, very old ISA-card can still beat a number of > today's crappy chipsets... I don't know whether to cry or laugh ;)) I noticed that the ENS1371 seems to have a better rating on one site I looked than to EMU10K, so this doesn't surprise me! > > Cards that I have no personal experience with, but I've heard very > good things about: > > - RME Digi9652 > > Beware: > > - SB AWE models (ugh, crap!) > - Yamaha YMF7xx/DS-XG (some have reported that these work ok, > but in any case they have a max 3 periods limitation > similar to cs4281, which can confuse apps) > > All in all, most of the PCI-cards supported by ALSA have fairly good > drivers. But how do I compare one card with another? What should I be looking for? How can I tell which will reduce the load on my computer and which will increase the load? Is there any difference?
Music N style sw w/ JACK-support (was: Re: [linux-audio-dev] Re:image problem)
On Tue, 22 Oct 2002, David Gerard Matthews 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 Just in case you are not aware of these: - icsound has JACK-support -> http://agnula.org/~maurizio/icsound/ - there's patch for PD that provides JACK-support -> http://sourceforge.net/mailarchive/message.php?msg_id=1169519 - supercollider's alpha version for Linux has JACK-support -> http://www.cs.tu-berlin.de/~kerstens/pub/SuperCollider3-linux.tgz - Paul Winkler has written a JACK driver for SAOL/sfront -> not yet released, mail Paul :) PS Nopes, it's not just alsaplayer, ardour and ecasound anymore. ;) -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]
>> When I run latencytest0.42-png from [EMAIL PROTECTED], I get about 99% sub >> 2ms latency. But jack still complains of xruns of about 50ms. There's >> something here I'm simply failing to understand... but I don't know where to > > >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? and finally, a general warning: JACK tests a lot more of the kernel than benno's latencytest program or andrew morton's rtc-based tester. that is because JACK requires not only rapid interrupt servicing and return to user space, it also requires absolutely correct scheduling between user space contexts using pipe write(2) and poll(2) calls. if all JACK clients were in-process, its performance characteristics would be identical, more or less, to latencytest. but nothing except the ALSA client/driver are in-process right now, and so if the kernel ever goofs up scheduling, then whatever the characteristics of the clients, things will break. the bad news is that the kernel (at least as of 2.4.19) *does* goof up the scheduling. if anyone wonders why i'm so cranky today, its because i am trying to discover why it does this, and to see if it can be fixed without compiling and booting 2.5 (which probably doesn't behave the same way). with latencies above 10ms, you will likely not notice the problem i am debugging. with latencies below that number, especially way below, at least on an SMP system, you will not JACK to run reliably with 2.4.19+ll. for now. hopefully, this will be fixed soon. none of the above applies to a system with just jackd+alsa running. such cases are immune to the scheduling bug i am looking at, and are more likely to be caused by other system activity that involves improperly tuned subsystems (such as IDE drives). --p
RE: [linux-audio-dev] Re: image problem
> This is a fair question. First, "many people" might promote OSS, but that > doesn't mean unconditional surrender. ;) I mean, I was really quite > offended by Ivica's message where he proposed that JACK developers are > arrogant if they don't implement x and y. OSS or not, that's not very nice > considering how much free time we have spend on this. And what do you think how do I feel when I contribute to this community with my apps (which certainly are nothing even close in scope or quality to Ardour, but are my best and most honest shot at it), spend most of my time promoting Linux, conceiving a Linux & Multimedia class at my University and teaching it, convincing my mentor that the Linux is the way to go by purchasing new Linux machines, and evangelizing Linux/Alsa/Jack among my peers, and all this without any compensation whatsoever? Do you think my time is any less valuable than yours? Besides, I was, and still am the advocate of Alsa. But even Alsa supports OSS apps (to some extent), so I have no clue as to why you are placing me in the OSS camp. If you read my post carefully, you'd realize that I am talking about good quality apps that will simply not be usable with Jack framework which is a shame, and as such would limit user's ability to unlock the full potential of Linux audio... The arrogance I spoke of you managed to misinterpret rather well. What I spoke of is the fact when addressing this issue to Jack developers, you get cornered into a situation where you are "damned if you do present the issue, and damned if you don't" while at the same time Jack developers simply suggest the impossible: why don't you port all those 1000+ apps to Jack? So if I come out with a suggestion, then I get flamed all over for it, but if I keep quiet, then I cannot use it for what I need it for. If that did not come of as described above, then I do apologize. Every wish for contribution that came from my mouth was in a form of suggestion/criticism/request for a feature, because that is the most comprehensive and quickest way of presenting the case. After all, stroking egos will not make Jack any better... Every one of those was met with a strong opposition and defensive behavior. I want to contribute, but if the project developers to whose project I want to contribute to marginalize my suggestion for contribution, then what's the point? Ico
[linux-audio-dev] good cards/chipsets for full-duplex/low-latency audio
Btw; this a very interesting topic. Please, tell about your
experiences. By discussing these things in a public forum,
we are actually creating a nice searchable knowledgebase
for all current and future ALSA users!
On Tue, 22 Oct 2002, Anthony wrote:
>> - snd-intel8x0 (nice chipset, is suitable for low-latency use)
> 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.
Hmm, what laptop/soundcard and what version of ALSA (the dma routines were
rewritten quite recently)? It's true that intel8x0 is used quite a few
different laptops/cards [1], so it's possible that not all work as well as
I've experienced, but as it's in any case the same driver on the audio
side, these problems shouldn't be common.
[1] {Intel,82801AA-ICH},"
"{Intel,82901AB-ICH0},"
"{Intel,82801BA-ICH2},"
"{Intel,82801CA-ICH3},"
"{Intel,82801DB-ICH4},"
"{Intel,MX440},"
"{SiS,SI7012},"
"{NVidia,NForce Audio},"
"{AMD,AMD768},"
"{AMD,AMD8111},"
"{ALI,M5455}
--
http://www.eca.cx
Audio software for Linux!
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]
On Tuesday 22 Oct 2002 20:27, Patrick Shirkey wrote: > Peter wrote: > >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.) > > This is a good idea to have this support and you've picked the right > thread for asking for it. Currently there are only a handful of people > who have worked on the official ALSA docs. I have done 90% of the work > myself. It's great I'm learning heaps in the process and will definitely > think about how to make it possible to add the info you require. > > Unfortunately we don't often get success stories on the ALSA lists so we > don't really know how well things work until someone says that it's > broken :( Heh. the life of a software developer. You only get fault reports and feature requests (that need to be delivered yesterday) :-). > > As it is I have tried to provide a feedback inteface via the notes > additions in the docs. So far it is being used but not as much as it > could be. I guess it will just take time. You can lead a horse to water... Ah, yes... I ought to post a report on my Evolution 249 USB keyboard. Works a treat (well, Clemens latest change isn't in my alsa driver yet...). > > Do you have a specific idea envisioned for how we could present the info > more effectively or a way to make more people contribute their results? > I'm listening. I think the new website is a _huge_ improvement over the old, static, one. Like I said elsewhere - I still don't really know enough about the hardware side of audio to know _what_ I'm missing :-( And getting the positive feedback ... maybe we could convince one of the large PC mags to do a soundcard comparison on Linux/ALSA... :-) If I knew enough to do a decent job, I'd happily nag everyone posting here, individually, into submitting details of their hardware setup and how they feel about their audio experience under Linux... :-) -- Peter
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help fora levelmeter]
Ivica Bukvic wrote: That being said, I have been at least somewhat convinced that Jack is possibly the way to go, and after some thinking, I've decided to attempt porting RTcmix into the Jack framework. Only time will now tell whether this was worth it or not. Regards, Ico 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
RE: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]
> > JACK *isn't* intended for general use, and i get tired of > > suggestions that it should be. and then later... > 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. Then explain it this way, and do not contradict yourself by initially saying Jack will never replace other sound daemons, and then mention that it is simply an issue that there is not enough manpower... Besides Jack can be high-latency (up to 8192 buffer size), so it is already fit to be used for purposes other than "pro" or SOPMF-whatever... > 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? First off, I USE RTcmix for "real-time performance with a mixture of electronic and acoustic sound sources," so obviously you have no idea what RTcmix is. Sure, it did not have a fancy gui (although that just changed a couple months ago with a new GUI from Dave Topper that makes RTcmix look like another Pd-like product). Other thing is, it is VERY LOW LATENCY, you can specify a single buffer size of 64 if you feel like it, the only question is whether your computer will keep up with it and how cpu intensive the process is. RTcmix has one of the best reverb, flange, place, and move filters I've heard, it has its own sub-busses (for mixing multiple filters), needless to mention dozens and dozens of other incredible instruments. It could as well be much better than any LADSPA plugin out there... Yet you say it's no good for commercial market... Hmmm... If you knew anything about the market, then you'd realize that as many SOPME/RTP studios there are in the world, they don't stack up to the amount of money educational institutions spend on building their electronic music studios, and this is where apps like RTcmix are an equal concern as Protools (even the university this list is hosted on uses RTcmix). If you had realized that, you'd know you'd be making a lot more money by selling your computers with Ardour and other stuff preinstalled to institutions like these (yet the institutions want their cpu's to do more than just Ardour). Just to give you a perspective, some of the INDIVIDUAL University studios in the US spend over $100,000/year for the new equipment/software. How much do the SOPME/RTP spend once they equip it for the first time? > >This will create an unnecessary polarization in an already heavily > >fragmented audio community (oss vs. alsa, esd vs. asd vs. artsd vs. > >gstreamer vs. jackd etc.). Linux is supposed to be all-inclusive and > > 1) who said "linux is supposed to be all inclusive"? who? Show me any past hardware that is not any more compatible with Linux and you'll know what I am talking about. Even if the device is not supported by the current kernel, you can always find a module and recompile it. That is by anyone's definition all-inclusive. Sure, some things do not work yet, but will be there soon (and this is not the issue in this case, since that falls into the forward-looking aspect). > 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. But are commonly used in educational institutions for professional music making purposes. Besides, please define "most people". I clearly see split on this list in terms of interests, so at best it's 50/50. > 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? Who said anything about you being the one who develops all this? What I did say is that you should not propagate the idea that Jack is never going to be an all-purpose sound daemon, when it is clear it could fulfill that purpose. In the end, it should be user's choice what they will do with it. Besides, I'd gladly poll my resources to add this feature to Jack, but the elusive alsa-server is in existence only in these discussions, alsa docs are still skimpy, and on top of that I do need to familiarize with the Jack's framework before I can contribute anything. Now why would I contribute to a project that you are
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]
* Kai Vehmanen <[EMAIL PROTECTED]> [Oct 22 02 16:09]: > - snd-intel8x0 (nice chipset, is suitable for low-latency use) 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
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] helpfor a levelmeter]
On Tue, 22 Oct 2002, Peter L Jones wrote: > When I run latencytest0.42-png from [EMAIL PROTECTED], I get about 99% sub > 2ms latency. But jack still complains of xruns of about 50ms. There's > something here I'm simply failing to understand... but I don't know where to 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!
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] helpfor a levelmeter]
On Tue, 22 Oct 2002, Peter L Jones wrote: > 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) > * Creative SB PCI 128 (ES1371) I've used both of these extensively with JACK and numerous other ALSA apps and they work really well (full-duplex, low-latency use). Other soundcards/chipsets that I've used: - snd-intel8x0 (nice chipset, is suitable for low-latency use) - snd-cs4281 (good for low-latency although has a max two-interrupts per buffer limitation which can confuse apps) - GUS MAX (this very, very old ISA-card can still beat a number of today's crappy chipsets... I don't know whether to cry or laugh ;)) Cards that I have no personal experience with, but I've heard very good things about: - RME Digi9652 Beware: - SB AWE models (ugh, crap!) - Yamaha YMF7xx/DS-XG (some have reported that these work ok, but in any case they have a max 3 periods limitation similar to cs4281, which can confuse apps) All in all, most of the PCI-cards supported by ALSA have fairly good drivers. -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] [ann] unmatched - a LADSPA amp tone
On Tue, Oct 22, 2002 at 08:01:35PM +0200, Tim Goetze wrote: > >I also have some very odd impulses lying around somewhere if > >I can find them - made by popping balloons in and around > >some 20' by 5' steel tanks that were in the basement of > >a converted industrial building I used to live in. > > i'd love to have one of those. if nothing else, they'll provide > excellent study material for our intrepid voyagers into the > sonic unknown. I just realized I probably won't be able to get at that old DAT tape for at least another 4 months - it's 700 miles away. :( Anyway, they sound quite interesting but not a "nice" reverb. kinda harsh and metallic. the decay was VERY VERY long. -- Paul Winkler "Welcome to Muppet Labs, where the future is made - today!"
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]
On Tuesday 22 Oct 2002 12:55, Kai Vehmanen wrote: [snip] > > JACK is not yet finished, and it has some definite usability issues > > that need to be resolved. but it is not, and i hope will never be > > (primarily) a general purpose sound server. > > In other words, development&testing help is welcome! I'd love to help. But at the moment I don't have the support I need to determine whether or not I can. I understand that getting low latency is an extremely complex issue. What I'd like to see, though, is some tool that will step me through a problem solving session to identify whether I really have done everything possible and I'm going to have to suffer. When I run latencytest0.42-png from [EMAIL PROTECTED], I get about 99% sub 2ms latency. But jack still complains of xruns of about 50ms. There's something here I'm simply failing to understand... but I don't know where to start investigating. -- Peter
RE: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] hel p for a levelmeter]
> -Original Message- > From: Taybin Rutkin [mailto:trutkin@;physics.clarku.edu] > > On Tue, 22 Oct 2002, STEFFL, ERIK (SBCSI) wrote: > > > except of the blocking of sounds (the problem mentioned > above) I am quite > > dissapointed by functionality of linux drivers I have > tried, I have sb live > > platinum and (last time I checked): > > Maybe you should buy cards from companies that care about > Linux support. and which are those? I know of no way to get information about how good/complete the alsa driver is. I have read number of thread on various mailing lists/forums etc. about which cards to use (for different purposes) and I didn't find any useful information... The docs at alsa site are pretty much useless for this purpose (as far as I can tell). BTW creative provides some linux support. Plus the sound matrix at http://www.alsa-project.org/alsa-doc/ doesn't say there are problems getting docs from manufacturer. > You seem to be forgetting that most of the drivers are written by > volunteers working without documentation. no I don't. I am not saying somebody should go and fix my problems. I was just ranting because I am frustrated and I hope it will provide semi-useful feedback to somebody... (and somebody will go and fix my problems:-) possibly... and we were talking about acceptance of linux audio. erik
Re: [linux-audio-dev] [ann] unmatched - a LADSPA amp tone
Steve Harris wrote:
>On Tue, Oct 22, 2002 at 03:00:03PM +0200, Tim Goetze wrote:
>> i guess (don't know much about reverb design [yet]) that in
>> order to get a truly 'white' reverb the number of delay lines
>> approaches infinity. which turns a decent implementation into
>> a real programming challenge. :) nonetheless, one could start
>> with what we have -- usually people complain that there's not
>> enough 'color' in our digital reverbs ('gray'?).
>
>Also, 1 delay will give you white, so maybe its just the middleground that
>causes problems. Its possible that a linear waveguide based reverb will
>shift the frequencies less.
>
>You're right though, we should try an off the shelf reverb first.
the problem with converging IIR is that either the IIR or the
converging algorithm or both don't like impulses that are too
lively. the converger will simply fall dead when it sees an
exponentially decaying white noise impulse. it makes sense,
my understanding of its nature has it that the IIR really likes
to oscillate smoothly. i'd love to see the response of a good
concert hall, that will surely clear some questions on my part.
>> >PS "Steve's flat" was captured with a half knackered monitor and a three
>> >quarters knackered mic. I should probably do it again, as I have moved :)
>>
>> and i should really do the fender here and compare the original
>> to the convolved/iir-filtered emulation. but it's more important
>> to get the nonlinear parts right first i think.
>
>As a first cut, have you tried valve_1209 + valve_rec_1405 + [some LP
>filter] plugins? These make a fairly conventional tube model when applied
>in that order, and the rectifier includes some line sag effects which are
>the source of some of the compression effects (modulo my very basic
>knowledge of electronics).
what i don't get about the valve (the rect influence seems
negligible) is that it only shapes the negative portion of a
sine. without a LP, there's faint aliasing. it doesn't sound
so bad though, in fact i like it.
however i'm into harsh distortion now, and have fed the fender
three sines from zero to full gain (three octaves of 'c').
the shaping it does has some important properties that i'm only
beginning to understand, but it really does look fundamentally
different. it seems to self-oscillate at the zero-crossings,
and otherwise compresses the sine much like your valve does,
only the output signal is not a straight line where compressed,
but rather another irregular but smooth oscillation about a DC
value. a (realtime) electric circuit simulator would come in
handy here. i have a schematic of a tube amp circuit but i'm
not apt at drawing conclusions from it.
tim
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] helpfor a levelmeter]
Peter wrote: >On Tuesday 22 Oct 2002 17:42, Paul Winkler wrote: >> On Tue, Oct 22, 2002 at 11:14:52AM +0100, Steve Harris 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. >> >>> We should compile a list of them, and maybe put it in the JACK FAQ. >> >> --PW >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.) This is a good idea to have this support and you've picked the right thread for asking for it. Currently there are only a handful of people who have worked on the official ALSA docs. I have done 90% of the work myself. It's great I'm learning heaps in the process and will definitely think about how to make it possible to add the info you require. Unfortunately we don't often get success stories on the ALSA lists so we don't really know how well things work until someone says that it's broken :( As it is I have tried to provide a feedback inteface via the notes additions in the docs. So far it is being used but not as much as it could be. I guess it will just take time. You can lead a horse to water... Do you have a specific idea envisioned for how we could present the info more effectively or a way to make more people contribute their results? I'm listening. -- 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
RE: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]
> -Original Message- > From: Kai Vehmanen [mailto:kai.vehmanen@;wakkanet.fi] > > On Tue, 22 Oct 2002, Conrad Parker wrote: > > > it might save you some hassles if you changed the intro to > jack's web > > pages, which currently read: > > > > JACK is a low-latency audio server, written primarily for the > > GNU/Linux operating system. It can connect a number of different > > applications to an audio device, as well as allowing > them to share > > audio between themselves. > > > > that, by itself, sounds to the average user an awful lot > like a general > > purpose audio server. Perhaps what you wrote in the email > below, comparing > > JACK to ASIO, would be more appropriate. > > 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-- 'suitable' does not mean 'exclusively suitable'. and 'focus' does not (usually) mean 'completely ignore anything else'. all in all if it can handle tough tasks I would expect it to handle easy tasks as well (which I think was the point of original post) erik
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]
On Tuesday 22 Oct 2002 17:42, Paul Winkler wrote: > On Tue, Oct 22, 2002 at 11:14:52AM +0100, Steve Harris 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. > > We should compile a list of them, and maybe put it in the JACK FAQ. > > --PW 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
Re: [linux-audio-dev] [ann] unmatched - a LADSPA amp tone
Paul Winkler wrote: >I recently acquired my first vintage amp - >a '63 Gibson GA-30 RVT in very good shape. >It's pretty versatile and doesn't sound quite like anything else >I've played. I'd be happy to donate some impulses, with various >mics / positions and amp settings, if somebody can tell me a good way >to do it. How do you generate the impulse? (I've tried simply creating >a sample with 1 frame at maximum followed by zeroes, but this seems >not to make it through the D/A conversion - it comes out as dead >silence.) maybe widening the pulse will help. steve? i've yet to take one myself, but if you come up with one you'll get an optimized plugin for it for free if i can get it to converge (so you can tell me whether you recognize the sound at all ;). >I also have some very odd impulses lying around somewhere if >I can find them - made by popping balloons in and around >some 20' by 5' steel tanks that were in the basement of >a converted industrial building I used to live in. i'd love to have one of those. if nothing else, they'll provide excellent study material for our intrepid voyagers into the sonic unknown. tim
Re: [linux-audio-dev] [ann] unmatched - a LADSPA amp tone
On Tue, Oct 22, 2002 at 06:31:16PM +0100, Steve Harris wrote: > I've not seen the DA converter problem you mention before, that's > interesting. What do you usually do? > > I also have some very odd impulses lying around somewhere if > > I can find them - made by popping balloons in and around > > some 20' by 5' steel tanks that were in the basement of > > a converted industrial building I used to live in. > > Mm. Yeah, that would be cool if you can find them. We have some old, > linked salt water storage tanks at work that desperatly need impulses > taking. The problem is that its really damp down there, so I didn't want > to take monitors down, and I dont have any acceptable mics that dont need > phantom power. Everybody should have at least one good dynamic mic! I've got a Sennheiser 421. An EV RE-20 would be even nicer. > I never thought of a baloon, I was going to try a kids cap > gun. Didn't think of that. Balloon pops probably have some coloration, but they're much stronger and probably less colored than handclaps... I don't have a spark-gap generator--I don't even know what it is really, but I've heard those are the "proper" tool for acoustic impulses. The problem with balloons is you have to keep blowing up more as each one is only good for one go :) -- Paul Winkler "Welcome to Muppet Labs, where the future is made - today!"
Re: [linux-audio-dev] [ann] unmatched - a LADSPA amp tone
On Tue, Oct 22, 2002 at 03:00:03PM +0200, Tim Goetze wrote:
> i guess (don't know much about reverb design [yet]) that in
> order to get a truly 'white' reverb the number of delay lines
> approaches infinity. which turns a decent implementation into
> a real programming challenge. :) nonetheless, one could start
> with what we have -- usually people complain that there's not
> enough 'color' in our digital reverbs ('gray'?).
Also, 1 delay will give you white, so maybe its just the middleground that
causes problems. Its possible that a linear waveguide based reverb will
shift the frequencies less.
You're right though, we should try an off the shelf reverb first.
> >PS "Steve's flat" was captured with a half knackered monitor and a three
> >quarters knackered mic. I should probably do it again, as I have moved :)
>
> and i should really do the fender here and compare the original
> to the convolved/iir-filtered emulation. but it's more important
> to get the nonlinear parts right first i think.
As a first cut, have you tried valve_1209 + valve_rec_1405 + [some LP
filter] plugins? These make a fairly conventional tube model when applied
in that order, and the rectifier includes some line sag effects which are
the source of some of the compression effects (modulo my very basic
knowledge of electronics).
- Steve
Re: [linux-audio-dev] Re: The Image (usablity) problem from aMusicians point of view
>From my experience with linux and audio I would say it is too early to start widely promoting linux as a professional audio solution, in general. It is just not there at this point. A couple of things could be "promoted", though. Companies or individuals that want to offer commercial (professional) linux audio solutions or services can promote their product(s). I think it is _not_ impossible to assemble a turnkey solution that will work for a given task. If it works and you want to sell it, then of course you have to promote it somehow. But it is the company promoting a product, not the linux audio community as a whole promoting the platform. Another one would be sharing success stories. If you are using linux in a professional audio environment successfully then by all means tell the world (and us :-). But tell the whole story, including the painful start (_if_ it was painful, of course :-) as well. I'm not talking here about the more common "I finally got ardour to work and it is cool" but the "I cut an album with ardour, it was not easy but the end result is great" (just an example). IMHO word of mouth from users that are happy with their systems is what should make linux successfull in the professional audio world. When that happens big commercial companies will probably also take notice. -- Fernando
Re: [linux-audio-dev] [ann] unmatched - a LADSPA amp tone
On Tue, Oct 22, 2002 at 09:55:07AM -0700, Paul Winkler wrote: > I recently acquired my first vintage amp - > a '63 Gibson GA-30 RVT in very good shape. > It's pretty versatile and doesn't sound quite like anything else > I've played. I'd be happy to donate some impulses, with various > mics / positions and amp settings, if somebody can tell me a good way > to do it. How do you generate the impulse? (I've tried simply creating > a sample with 1 frame at maximum followed by zeroes, but this seems > not to make it through the D/A conversion - it comes out as dead > silence.) OK, well an alternative, for EQ readings is to push whitenoise though. This doesn't work too well for convolving though, if you want to make it compatible with a convolver then I suggest you make a sine sweep (10 seconds long, 50Hz to 20kHz should be plenty), and record that. You can then deconvolve the recording with the sweep and you are left with an impulse. I've not seen the DA converter problem you mention before, that's interesting. > I also have some very odd impulses lying around somewhere if > I can find them - made by popping balloons in and around > some 20' by 5' steel tanks that were in the basement of > a converted industrial building I used to live in. Mm. Yeah, that would be cool if you can find them. We have some old, linked salt water storage tanks at work that desperatly need impulses taking. The problem is that its really damp down there, so I didn't want to take monitors down, and I dont have any acceptable mics that dont need phantom power. I never thought of a baloon, I was going to try a kids cap gun. I have a bigish library of impulses, but I can't remeber where most of them came from, so I'm reluctant to release them. - Steve
Re: [linux-audio-dev] Re: image problem
On Tue, 22 Oct 2002, Sebastien Metrot wrote: > There is this annoying kind of double talk in the OSS comunity: many people > just talk about how great OSS are and how every body should start using it > and all that kind of stuff, but as soon as you ask for some professional > behaviour from the apps and from the developers the only answer one gets is > "hey, we're just a bunch of volunteers, how can you be that arrogant and ask > this feature/effort from me?". The point is this: do people here wants LAD This is a fair question. First, "many people" might promote OSS, but that doesn't mean unconditional surrender. ;) I mean, I was really quite offended by Ivica's message where he proposed that JACK developers are arrogant if they don't implement x and y. OSS or not, that's not very nice considering how much free time we have spend on this. And really, the so-called OSS community does not consist of altruistic dummies that work for free, although suprisingly many people seem to have just the opposite belief. On the other hand, it is possible to get very good and friendly support and help here, but the attitude is everything. You have to be a team member and contribute (be it mental support, good/insightful comments, real-world experience with the given area/topic, promoting, coding, money, free beer, whatever) something. Then you can make demands and complain, and you will be listened to. If you just complain (like you might do if you have bought a software from a commercial vendor and do not like it), it just doesn't work. Of course, you can also choose to not to contribute anything at all, but it shouldn't come as a suprise to you if your comments don't have the same weight as those coming from contributing members. You know, life, give some, get some. ;) And just to be sure, it really is in our (now speaking as a developer) interest to listen to user feedback. That's the whole point of releasing our software under GPL_or_whatever. Active users are invaluable part of a succesful project. And btw; professional users have the advantage to other "normal" users that they can offer the kind of hard-to-find insight and experience from the real-world that is very valuable for developers. So if you are a professional, becoming a contributing member is really quite easy, if you just want to make the effort. -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] [ann] unmatched - a LADSPA amp tone
On Tue, Oct 22, 2002 at 12:41:38PM +0100, Steve Harris wrote: > > the recording seems to be of decent quality, and the iir > > response irons away most of the noise anyway. but the most > > important thing is i like the sound of it, which i do a lot. > > i've tried about every of your impulses and, would you > > believe it, liked the fenders the least. i regularly play > > a fender super 60, for ten years or so. :) got to take > > a response from it someday myself. > > Sadly heres where my zero knowledge of amps kicks in ;) I wouldn't know a > fender form a hole in the ground. I recently acquired my first vintage amp - a '63 Gibson GA-30 RVT in very good shape. It's pretty versatile and doesn't sound quite like anything else I've played. I'd be happy to donate some impulses, with various mics / positions and amp settings, if somebody can tell me a good way to do it. How do you generate the impulse? (I've tried simply creating a sample with 1 frame at maximum followed by zeroes, but this seems not to make it through the D/A conversion - it comes out as dead silence.) I also have some very odd impulses lying around somewhere if I can find them - made by popping balloons in and around some 20' by 5' steel tanks that were in the basement of a converted industrial building I used to live in. -- Paul Winkler "Welcome to Muppet Labs, where the future is made - today!"
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]
On Tue, Oct 22, 2002 at 11:14:52AM +0100, Steve Harris 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. We should compile a list of them, and maybe put it in the JACK FAQ. --PW -- Paul Winkler "Welcome to Muppet Labs, where the future is made - today!"
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] hel p for a levelmeter]
>There is this annoying kind of double talk in the OSS comunity: many people >just talk about how great OSS are and how every body should start using it >and all that kind of stuff, but as soon as you ask for some professional >behaviour from the apps and from the developers the only answer one gets is whoa. professional behaviour from the apps is one thing. professional behaviour from the developers implies an exchange of money. >"hey, we're just a bunch of volunteers, how can you be that arrogant and ask >this feature/effort from me?". let suppose you've ripped a copy of cubase sx from a warez site. you'd like it do something that it doesn't do and you feel its very important for your work. you write to steinberg and complain: "i've been very unimpressed by the tempo options in cubase sx" do you think these guys will even give the time of day to finish your message? you're using free software, you pay nothing for whatever support you get, and you expect us to treat you the way for profit companies treat people who actually pay them? The point is this: do people here wants LAD >to become professional or just stay a bunch of cool guys doing cools things >in their garage? i'll make you a deal. how about i start acting "professional" and have you talk with 3 layers of support personnel before you come across anyone who actually knows anything about my software, rather than answer questions directly (and generally very promptly) myself? Of course good support will mean some exchange of money at >a moment or another but you will never get any money from the public with >half working drivers and half done apps... with all due respect, i feel comfortable giving out this response. several people here on the list know that i've been working on linux audio apps more or less full time (albeit with euro-sized summer vacations) for 3 years with no pay. i'm very lucky that i've been able to do this, especially because it gives me a metaphorical big stick :) i have no problem with people giving me good useful feedback: "i tried to get ardour to sync to MTC but it didn't work. it seemed to keep drifting in and out of sync, and then just gave up and stopped. i'd really like to see this work." i have even less problem with people saying "here's some cash as a contribution towards your work in fixing this". but showing up and saying the equivalent of "i'm unimpressed by the sync facilities in ardour" is rude and disrespectful. --p
Re: [linux-audio-dev] Re: The Image (usablity) problem from a Musicians point of view
Yes, sure, I'm pretty sure nobody ever made a pure C vstplugin. I'm not sure about how Borland C & Delphi users manage to make plugins though. I believe Delphi user only use the C API but this is becoming mostly rethorical now :) Sebastien - Original Message - From: "Paul Davis" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 22, 2002 6:18 PM Subject: Re: [linux-audio-dev] Re: The Image (usablity) problem from a Musicians point of view > >Hu, in fact it's the other way around: VST is a C ApI based of a very small > [ ... ] > > sebastien - thanks a lot for the clarification. you are right about > VST being a C API in a fundamental sense, but i think it more than > notable that there are no C plugins, only C++ ones. i was simply wrong > about DX being C. thanks. > > --p >
Re: [linux-audio-dev] Re: The Image (usablity) problem from a Musicians point of view
>Hu, in fact it's the other way around: VST is a C ApI based of a very small [ ... ] sebastien - thanks a lot for the clarification. you are right about VST being a C API in a fundamental sense, but i think it more than notable that there are no C plugins, only C++ ones. i was simply wrong about DX being C. thanks. --p
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] hel p for a levelmeter]
There is this annoying kind of double talk in the OSS comunity: many people just talk about how great OSS are and how every body should start using it and all that kind of stuff, but as soon as you ask for some professional behaviour from the apps and from the developers the only answer one gets is "hey, we're just a bunch of volunteers, how can you be that arrogant and ask this feature/effort from me?". The point is this: do people here wants LAD to become professional or just stay a bunch of cool guys doing cools things in their garage? Of course good support will mean some exchange of money at a moment or another but you will never get any money from the public with half working drivers and half done apps... With all due respect, Sebastien - Original Message - From: "Paul Davis" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 22, 2002 5:39 PM Subject: Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] hel p for a levelmeter] > > except of the blocking of sounds (the problem mentioned above) I am quite > >dissapointed by functionality of linux drivers I have tried, I have sb live > >platinum and (last time I checked): > > "i am quite disappointed that a group of volunteers who work for no > monetary compensation have failed to implement all the features i > want. i haven't offered to pay them, but i really hope they get all > these features working really soon because its really irritating not > being able to ..." > > --p >
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] helpfor a levelmeter]
Eric wrote: >it is also pretty much useless for general users. I mean if I can't >listen to mp3 and browse the web at the same time ... (without sound >servers which were discussed recently and as far as I can tell the >general consensus is that they are bad and not to be used). 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
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]
Patrick wrote: > >If you will be making money from a Linux-based product, then you > >*should* be investing your own money for promotion. > > I am. What's your point? Other people (people who are not in business) need not and likely won't invest money to promote Linux Audio. People here invest their time and effort (but usually not money for promotion), mostly because they're techies who want to to build something that they really need/want. Businesses invest money for another reason, because they want to develop and promote commercial products. They're mostly two different worlds (though there is crossover). > 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. Perhaps there's no need to promote Linux Audio; perhaps instead there is a need to promote useful products. If those products happen to need Linux (and ALSA & Jack) as a foundation, then Linux will get promoted as a side effect of successful products. Much like MacOS. So if you want Linux Audio to be promoted, either make broadly useful products or assist the companies that want to turn your work into broadly useful products. Len Moskowitz Owner, Core Sound http://www.core-sound.com
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] hel p for a levelmeter]
[ re: OSS ] >> code. It will >> soon be available only through emulation. It forces use of >> the blocking >> model. actually, it doesn't. nothing would stop the implementation of an OSS driver/client for JACK. >> ALSA is very powerful and complete, but very complex. This will make > > > > it is also pretty much useless for general users. I mean if I can't listen >to mp3 and browse the web at the same time ... (without sound servers which >were discussed recently and as far as I can tell the general consensus is >that they are bad and not to be used). Is there any rationale for the >blocking behaviour? I mean I can't imagine situation where I would want to clarify: the "blocking model" that joshua was describing has nothing to do with the "blocking behaviour" that you are describing. jaroslav (aka "mr. alsa") has justified the block-on-open model by reference to POSIX standards for the open system call. its a bit debatable, but his point of view on it is at least as close to standard POSIX behaviour as yours. applications can avoid this quite easily using O_NONBLOCK in the OSS open call (or its equivalent for ALSA), later followed by fcntl(2) if necessary. i personally it would have been better to make open return EBUSY, but the problem is that there is no flag for open(2) that says "block even if busy", so with that design there is no way to get "block-on-open" if desired. > except of the blocking of sounds (the problem mentioned above) I am quite >dissapointed by functionality of linux drivers I have tried, I have sb live >platinum and (last time I checked): "i am quite disappointed that a group of volunteers who work for no monetary compensation have failed to implement all the features i want. i haven't offered to pay them, but i really hope they get all these features working really soon because its really irritating not being able to ..." --p
[linux-audio-dev] Re: The Image (usablity) problem from a Musicians point of view
If I remember correctly, the guy that wrote the VQF (an mp3-like codec) plugin for xmms (home page here:http://www.csn.ul.ie/~mel/projects/linux/vqfplugin/ ) used wine to run the windows version of the audio codec under linux. Reading form his page he has now switched to a native version of the codec but perhaps he could share his experiences with us on this list. I'll try to concact him (if he isn't already on the LAD list) and send him the URL of this thread. cheers, Benno
RE: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] hel p for a levelmeter]
On Tue, 22 Oct 2002, STEFFL, ERIK (SBCSI) wrote: > except of the blocking of sounds (the problem mentioned above) I am quite > dissapointed by functionality of linux drivers I have tried, I have sb live > platinum and (last time I checked): Maybe you should buy cards from companies that care about Linux support. You seem to be forgetting that most of the drivers are written by volunteers working without documentation. Taybin -- http://www.piratesvsninjas.com
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]
>> > all, you basically have a box that wouldn't run an ASIO device >driver >> > under windows or macos. > >So, in essence Jack is yet another ASIO wannabe. If I wanted ASIO, I'd >be working on Windows or MacOS. 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"? >What about making it more like Core Audio on steroids where everything >can be low latency, or high latency, where USER HAS THE CHOICE? This >"Jackd is only for pro's" sounds too much like Apple die-hard fan >zealotry to me, something that I readily detest. 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. >of good PRO apps (contrary to your definition of OSS-based "toys" in one >of your previous e-mails) do not, and will not support it (i.e. RTcmix) 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? >This will create an unnecessary polarization in an already heavily >fragmented audio community (oss vs. alsa, esd vs. asd vs. artsd vs. >gstreamer vs. jackd etc.). Linux is supposed to be all-inclusive and 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. >Yet, in this case if the audio app does not support JACK, then it's >either a "toy" or basically whomever wants to use it is screwed and has 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. >If you really want the JACK to take off, then you should look not only as kai has noted, most of the apps i care about already have JACK support. from my point of view, its already moderately successful. >And if the only explanation to this problem is "they need to port their >apps to JACK", while there is no effort to meet the user needs at least >half-way by offering an easy interfacing for apps that may not be ported >to JACK in the recent future for whatever reasons, then I see that as >sheer arrogance. 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? >Case and point, I may want to use ardour, but if I take a break and want >to listen to some mp3's on an un-jackified player (such as xmms, for >instance), how user-friendly would it be to have to save session, close >ardour, close jackd, and only then start xmms, and then after 10 minutes >do all that in reverse? Why couldn't xmms simply connect automagically >to jackd by jackd detecting simple oss-open-dsp-resource call? 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 s
RE: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]
> -Original Message- > From: Joshua Haberman [mailto:joshua@;haberman.com] > > "Paul Davis" <[EMAIL PROTECTED]> wrote: > > >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. > > > > JACK *isn't* intended for general use, and i get tired of > suggestions > > that it should be. there are lots of people working on solutions for > > "general use". JACK is intended for people who are serious about > > audio. > > I don't understand this attitude. I think it hinders > acceptance of JACK > (even for serious audio) and it contributes to further > fragmentation of > the Linux audio world. > > If you would rather everyday applications not use JACK, what > should they > be using instead? OSS is simple but limited, and spotty > drivers/implementations make it difficult to write robust > code. It will > soon be available only through emulation. It forces use of > the blocking > model. > > ALSA is very powerful and complete, but very complex. This will make it is also pretty much useless for general users. I mean if I can't listen to mp3 and browse the web at the same time ... (without sound servers which were discussed recently and as far as I can tell the general consensus is that they are bad and not to be used). Is there any rationale for the blocking behaviour? I mean I can't imagine situation where I would want playback to wait for another playback to finish and play sound then... either report error (device busy) or just ignore the sound... (or do the mixing) as far as I know this behaviour is not configurable - am I mistaken? (rarely I wish to be proven wrong so much:-) maybe this is not the best place for a rant but since we are discussing the acceptance of linux in audio world, here's my own experience. except of the blocking of sounds (the problem mentioned above) I am quite dissapointed by functionality of linux drivers I have tried, I have sb live platinum and (last time I checked): - front panel midi connectors do not work - game port midi functionality - sort of works, works OK with one keyboard but does not work with another midi controller (yamaha drum toy) (both work fine with front panel midi under windows) - front panel RCA connectors do not work - infra red sensor probably does not work (at least I wasn't able to make it work and I got no responses on lasa mailing list) erik
Re: [linux-audio-dev] Re: The Image (usablity) problem from a Musicians point of view
>> But there are not very many "pro >> audio" plugins under DirectX - lots of instruments and wierdo >> enthusiast FX, but not the sort of stuff that ProTools, Nuendo and >> Logic users are inclined towards. > >Waaahh!!! I would disagree. The Waves bundles are seriously good and >goes for thousands of dollars. Hardly low end stuff. thats very true. i forget about the Waves guys.
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]
>> JACK *isn't* intended for general use, and i get tired of suggestions >> that it should be. there are lots of people working on solutions for >> "general use". JACK is intended for people who are serious about >> audio. > >I'd like to add that not all JACK developers are as strict about this as >Paul ;), but it's true that something more concrete than 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. >And I think you can run JACK using pretty much any ALSA-supported >soundcard. It's just that we cannot guarantee good performance or flawless >operation in these cases. These cards will also cause problems to other >applications. It's just that JACK makes these problems much more explicit. 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
Re: [linux-audio-dev] [ann] unmatched - a LADSPA amp tone
Steve Harris wrote:
>> currently, i'm looking at what a sine wave looks like after
>> it's been handled by a good distortion stomp box. the way it
>> shapes the wave form seems easy to grasp, but as usual, i
>> am hesitant to implement what i don't understand fully ...
>
>I've found that the precise shape of the transfer function is important to
>the sound, do you have a model for the transfer function or are you just
>going to smaple it?
i'll rather try and come up with a formula. a simple mapping
will not work, because the transfer function moves the peaks
of the sine to happen earlier (i guess looking at the derivative
of the signal may play a role here). i have some ideas, but i'll
need to read up on what's actually happening inside the
circuitry. and if it turns out to include fabs() and branching,
i'll try and combine it with a compression effect (if it isn't
some sort of already, which i suspect).
>Sadly heres where my zero knowledge of amps kicks in ;) I wouldn't know a
>fender form a hole in the ground.
they all sound like a stratocaster, whatever instrument is
plugged in. ;) no seriously, their sound is very bright; at
best you'll call it very 'electric'.
>> >I'm wondering if this technique can be used for reverbs too - generate a
>> >purely "white" synthetic reverb tail, and apply an IIR the aproximate
>> >shape of the rooms impulse to it to make it sound more real...
>>
>> very interesting thought indeed. do you have a good response
>> for trying this? (sorry, "steve's flat" doesn't qualify,
>> "albert hall" is more like it ;)
>
>I have some, but there not included because there 1) very long 2) legally
>dubious. I dont think that deriving an EQ curve form them can be dodgy
>though - the hard part is more likly to be getting a purly white reverb -
>I suspect that all those allpass's and combs dont even out very well.
i guess (don't know much about reverb design [yet]) that in
order to get a truly 'white' reverb the number of delay lines
approaches infinity. which turns a decent implementation into
a real programming challenge. :) nonetheless, one could start
with what we have -- usually people complain that there's not
enough 'color' in our digital reverbs ('gray'?).
>PS "Steve's flat" was captured with a half knackered monitor and a three
>quarters knackered mic. I should probably do it again, as I have moved :)
and i should really do the fender here and compare the original
to the convolved/iir-filtered emulation. but it's more important
to get the nonlinear parts right first i think.
tim
RE: [linux-audio-dev] Re: image problem
On Mon, 21 Oct 2002, Ivica Bukvic wrote: > And as long as you view JACK as that, it will have a very small user > base and hence very small pool of audio apps that will support it. All > this will lead to the fact that, no matter how good JACK is (or is > supposed to be), it will be always a questionable solution, since a lot I think that JACK will become a huge success not because of the server technology, but because of the applications. FreqTweak and Meterbridge are two very good examples of this. If these apps had read from /dev/dsp and wrote to /dev/dsp, they would have been interesting acquaintances, but it would have been difficult to actually use them in real work. But now with JACK, they are tools that you can really _use_! Few more apps like this and every Linux audio developer is going to be very tempted to port their app to JACK. Mark my words, JACK's going to be big. :) > This will create an unnecessary polarization in an already heavily > fragmented audio community (oss vs. alsa, esd vs. asd vs. artsd vs. > gstreamer vs. jackd etc.). Linux is supposed to be all-inclusive and Gstreamer already has JACK support btw. > If you really want the JACK to take off, then you should look not only > forwards, but also backwards, and find a relatively viable solution > (even if it is at the expense of the latency) that will work with 1000+ > decent apps that have not been ported to JACK framework, thus leaving > the issue of latency for the user to choose. This can be done, but we need someone to do it. I've already posted a message with a proposed design for an OSS-to-JACK gateway. But I don't have time to do this myself and I cannot force anyone else to do it either. What can I do? But I'm not too worried about this. I'm quite sure someone will do this sooner or later. > And if the only explanation to this problem is "they need to port their > apps to JACK", while there is no effort to meet the user needs at least > half-way by offering an easy interfacing for apps that may not be ported > to JACK in the recent future for whatever reasons, then I see that as > sheer arrogance. Well, please consider our side. We are trying to solve a problem that enables a new level of co-operationg between audio apps (see http://eca.cx/laaga )... This work is not finished yet. If you go and read recent jackit-devel messages from the archives, not everything is going just fine and dandy. We (especially Paul) have had to do enourmous amount of work to get where we are now and there's still work left. There are still issues that we don't know for sure how to solve and so the work has to continue. If this is arrogance, so be it. I really don't know how to reply to you here. > I am not only interested in using Ecasound, Ardour, > FreqTweak, and Pd for my music making purposes, neither is a majority of > other Linux users. Btw, it's many more than that: Alsaplayer gstreamer icsound iiwusynth MusE (since 0.6.0pre1) Rosegarden Rtsynth Spiral Synth Modular ... note that this list contains almost all lad "heavy-weights". I've never seen this level of co-operation between - some even directly competing - Linux audio projects, and it's a very exciting development! > Case and point, I may want to use ardour, but if I take a break and want > to listen to some mp3's on an un-jackified player (such as xmms, for > instance), how user-friendly would it be to have to save session, close Use alsaplayer and let xmms authors know why you made the choice. > do all that in reverse? Why couldn't xmms simply connect automagically > to jackd by jackd detecting simple oss-open-dsp-resource call? If it Because nobody has implemented 1) JACK-plugin for xmms, 2) JACK OSS gateway. We'd like to see both, but cannot force anyone to do them. > Neither will the commercial companies want to touch jackd with a 20-foot > pole if there will be an aura of limited hw it works with (that > automatically limits a pool of people that may potentially purchase an > app) and in addition requires a 100-page FAQ section to be shipped with Let's see about that. :) > What is yet to be determined is for example why am I getting xruns all > over the place after having jackd run for 10 minutes even at very high > buffer sizes and having it sit idle for most of those 10 minutes? Yes, that's why we are not working on OSS-to-JACK gateways. There's still work to be done in the core functionality. -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] Re: latencytest problem with 2.5.44-mm2
Hello Joern, Are you using ALSA right ? Perhaps an OSS emulation problem of ALSA ? I recall that I got grabled sound (even lockups) on the SBLive when using 128byte fragments (seemed like a driver or hardware problem). What kind of audio card do you have ? Anyway latencytest is completely outdated (does not compile cleanly on newer distros due to wrong includes etc). Now that I have some spare time again (seems unbelievable but I were able to finish my university degree in CS just a month before turning 30 ... better late than newer as we use to say :-) ) I'll try to rewrite some of the useful tools including latencytest, adding alsa support and new stress test methods and like one guy of the list asked , the possibility to chose the disks (or the path) on which perform the disk i/o tests. Anyway low latency came useful in my thesis since a part of the project consisted in a real time laser scanner that tracks a laser spot that you move over the object you like to scan that is filmed by two cameras that permit a 3D reconstruction of the surface. (at 25 FPS we have processing cycles of 40msec so it is quite easy for the low lat patch to keep up since there is basically no disk i/o present during the scanning activity). cheers, Benno. --- You wrote: i ran latencytest on kernel 2.5.44-mm2 yesterday, and the audio was totally garbled, just barely recognizable. strangely, i could aplay somesound.wav simultaneously, and it sounded ok. (except for dropouts here and there.) might it be an oss problem ? i'm stumped. i habe never seen this before with the 2.5 kernels. regards, jörn
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] helpfor a levelmeter]
On Mon, 21 Oct 2002, Paul Davis wrote: > JACK *isn't* intended for general use, and i get tired of suggestions > that it should be. there are lots of people working on solutions for > "general use". JACK is intended for people who are serious about > audio. I'd like to add that not all JACK developers are as strict about this as Paul ;), but it's true that something more concrete than suggestions/requests are needed. Technical proposals that extend JACK's usability without sacrificing the low-latency and synchronous-execution qualities, are very welcome. I don't think this is an impossible task. Btw; I also think the continuous flow of negative-ish comments concerning JACK is a bit unreasonable. There are still lots of work to be done in the low-latency area and this work of course has top-priority for current development team. > audio interfaces, its not intended to do so. if you can't run JACK at > all, you basically have a box that wouldn't run an ASIO device driver > under windows or macos. there's not much we can do about that except > to point you at kernel adjustments (like hdparm) and ask that you > check other mailing lists to see if your audio interface, video > interface, etc. are known to be horrible in some respect. And I think you can run JACK using pretty much any ALSA-supported soundcard. It's just that we cannot guarantee good performance or flawless operation in these cases. These cards will also cause problems to other applications. It's just that JACK makes these problems much more explicit. > JACK is not yet finished, and it has some definite usability issues > that need to be resolved. but it is not, and i hope will never be > (primarily) a general purpose sound server. In other words, development&testing help is welcome! -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] [ann] unmatched - a LADSPA amp tone
On Tue, Oct 22, 2002 at 03:09:52AM +0200, Tim Goetze wrote: > on average, the branched truncate costs more in this filter > than simply ignoring denormals. for this particular filter, > there doesn't seem to be a good reason to switch to floats > at least on the system i use. if i was pressed for a rule, > i'd say use doubles unless you need to store lots of them. No, there is no good reason to switch to floats here. I havn't found that doubles are generally better than floats though - but I also dont have a way of prediciting it either. It would save be a lot of time if I did. > currently, i'm looking at what a sine wave looks like after > it's been handled by a good distortion stomp box. the way it > shapes the wave form seems easy to grasp, but as usual, i > am hesitant to implement what i don't understand fully ... I've found that the precise shape of the transfer function is important to the sound, do you have a model for the transfer function or are you just going to smaple it? > the recording seems to be of decent quality, and the iir > response irons away most of the noise anyway. but the most > important thing is i like the sound of it, which i do a lot. > i've tried about every of your impulses and, would you > believe it, liked the fenders the least. i regularly play > a fender super 60, for ten years or so. :) got to take > a response from it someday myself. Sadly heres where my zero knowledge of amps kicks in ;) I wouldn't know a fender form a hole in the ground. > >I'm wondering if this technique can be used for reverbs too - generate a > >purely "white" synthetic reverb tail, and apply an IIR the aproximate > >shape of the rooms impulse to it to make it sound more real... > > very interesting thought indeed. do you have a good response > for trying this? (sorry, "steve's flat" doesn't qualify, > "albert hall" is more like it ;) I have some, but there not included because there 1) very long 2) legally dubious. I dont think that deriving an EQ curve form them can be dodgy though - the hard part is more likly to be getting a purly white reverb - I suspect that all those allpass's and combs dont even out very well. PS "Steve's flat" was captured with a half knackered monitor and a three quarters knackered mic. I should probably do it again, as I have moved :) - Steve
Re: [linux-audio-dev] [ann] unmatched - a LADSPA amp tone
Steve Harris wrote: >> a quick test (%s/double/float/g) shows the cpu usage doubling, >> but i'm unsure what may cause this huge performance drop. > >Lets just put it down to chache issues and ignore it ;) can't ... ;) here's the output of gcc -O2 -S. this is what is added for every coefficient in the float version wrt doubles: ... fstps -4(%ebp) flds -4(%ebp) ... afaict, it truncates the algorithm's accumulator to float. if we change the constant coefficients to come as floats (appended 'f') this truncation is omitted, and the cpu cost is the same (maybe a tad more) as for doubles. i conclude that constant real values really need the 'f' if operating with floats in gcc, and that there's little reason to use them in DSP on x87 anyway if memory effects aren't essential. >> doubles should, on average, mean we seldom hit the denormal number >> bounds, or at least less frequently than with floats. i also expect >> doubles to be beneficial to the filter stability by minimizing >> round-off error, though i may be wrong here. lastly, x87 uses 80 bits > >Yes, though can manually truncate the floats, and floats will give half >the cache footprint, so play better with other software. I dont really >have a feel for when doubles are neccesary for filters yet. on average, the branched truncate costs more in this filter than simply ignoring denormals. for this particular filter, there doesn't seem to be a good reason to switch to floats at least on the system i use. if i was pressed for a rule, i'd say use doubles unless you need to store lots of them. >Yes, you can always pep things up with a nonlinear effect of somekind >before the cabinet+speaker sim. In FFT convolvers you take several >impulses at different amplitudes and shift between them. currently, i'm looking at what a sine wave looks like after it's been handled by a good distortion stomp box. the way it shapes the wave form seems easy to grasp, but as usual, i am hesitant to implement what i don't understand fully ... >I wouldn't worry too much aboout being very close the the impulse, the're >only for a particular input amplitude and I can't remember when they came >from so may not be fantastic. the recording seems to be of decent quality, and the iir response irons away most of the noise anyway. but the most important thing is i like the sound of it, which i do a lot. i've tried about every of your impulses and, would you believe it, liked the fenders the least. i regularly play a fender super 60, for ten years or so. :) got to take a response from it someday myself. >I'm wondering if this technique can be used for reverbs too - generate a >purely "white" synthetic reverb tail, and apply an IIR the aproximate >shape of the rooms impulse to it to make it sound more real... very interesting thought indeed. do you have a good response for trying this? (sorry, "steve's flat" doesn't qualify, "albert hall" is more like it ;) tim
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] helpfor a levelmeter]
On Tue, 22 Oct 2002, Conrad Parker wrote: > it might save you some hassles if you changed the intro to jack's web > pages, which currently read: > > JACK is a low-latency audio server, written primarily for the > GNU/Linux operating system. It can connect a number of different > applications to an audio device, as well as allowing them to share > audio between themselves. > > that, by itself, sounds to the average user an awful lot like a general > purpose audio server. Perhaps what you wrote in the email below, comparing > JACK to ASIO, would be more appropriate. 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!
Re: Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]
On 10/22/2002 - 04:46:47, Richard Bown said: > On Monday 21 October 2002 20:21, Patrick Shirkey wrote: > > But am I just wasting my breath because the Agnula crew are going to > > do all the work for us? > > Oh well _now_ you come on to my pet subject. > > > Anyone from the Agnula project have a position on this? > > 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. > Too late :) So we are not wasting our time to debate this. There is a real problem that the professional side of this community is not really taking into account. I was sceptical that the Agnula team would be doing massive promotional campaigns. Peter you said that if we intend to make money out of Linux Audio we *should* be paying for it. Well doesn't that alsao apply to studios and professionals who intend solely to use the finished products to make money? Patrick. --
Re: [linux-audio-dev] The Image (usablity) problem from a Musicianspoint of view
On 21 Oct 2002, Lea Anthony wrote:
> 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.
This is something that has been proposed quite a few times here.
Who's the "we" here? I'd say this is something that has to be
done by a volunteer group (think of debian), company (think of redhat) or
a mixture of two. Currently the best example of this concept is Planet
CCRMA.
If this kind of project is succesful, it will motivate individual
development projects to improve their offerings so that their project
get included in the "promo-projects". If a company would do this, it
could allocate resources to those areas of development that are lacking.
Of course, one possibility is that this kind of group is formed
here on linux-audio-dev and linux-audio-user, but you shouldn't
expect too much help from the individual projects. In the end,
the reason why so much (high-quality) development is happening
here is that people are scratching their itches, not because developers
are trying to create a marketable whole. And I think this is
good for all involved. The other option is to have a group
of not-so-motivated developers aiming at a marketable whole... hmm,
sounds awfully lot like traditional commercial development. ;)
But of course, for any kind of promo, or Linux audio interest group,
it would be silly not to participate on linux-audio-{dev,user},
alsa-lists, and other central lists. I think this is why PlanetCCRMA has
been so popular. On the other hand, Demudi and Agnula seem, at least to
me, more like ivory-tower type of projects. They don't have much of
a presence on any of the mentioned lists.
And btw; it's good to note that participants in free/open-sw projects
are not just volunteers and/or enthusiasts. There can also be companies
involved that just want to scratch their itches, and don't have
a huge interest in marketing Linux audio. I think it's good to keep
these two interests separate.
--
http://www.eca.cx
Audio software for Linux!
Re: [linux-audio-dev] Re: The Image (usablity) problem from a Musicians point of view
On Tue, Oct 22, 2002 at 01:36:48 +0200, Benno Senoner wrote: > Indeed the ability to run DX and VST on Linux would be a good selling > point for pro audio on linux but there is still lot to do in the fields > of basic audio platform infrastructure and integration of the different > components. I'm not sure this would be a great idea. It looks good to say we support 90% of DX plugins (or whatever), but it might just disuade developers from porting to native linux binaries. You can bet DX emulation would be slower and less reliable than native Windows, giving the impression that Linux was slow and unreliable. Given that many of the respected plugin developers allready release for Windows, Macos and TDM, I dont think they would have a problem with adding Linux to that list. Not that there is an API for them to port to, but that is another matter... - Steve
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]
On Mon, Oct 21, 2002 at 08:51:01 -0700, Joshua Haberman wrote: > I fully understand that crappy consumer interfaces are not going to be > able to run JACK with 128 frames per period, but surely any card could > handle JACK if you bumped that size high enough. Is there any reason > that a particular card/computer could not handle JACK at all, at any > period size? I can't imagine why -- JACK is only making ALSA calls. If > JACK won't work on a crappy consumer card, does this mean no ALSA app > would either? 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. > What is the harm in all applications, XMMS up to Ardour, using JACK? I can > only see benefits. 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
Re: [linux-audio-dev] Re: The Image (usablity) problem from a Musicians point of view
Hu, in fact it's the other way around: VST is a C ApI based of a very small set of functions passing "opcodes" arround. It is wrapped with C++ on the plugin side but you can writte C only VST plugins (well, I don't know of any C only VST plugins anyway). DirectX/DirectShow is totaly COM based and thus C++ is almost mandatory. Of course you would be able to use COM objects in C by calling their methods thru the virtual functions table but COM allready being a pain in C++ I wouldn't advise anyone to go for this solution. MSVCRT is just the equivalent of the gnu libc, most functions are the same and the missing ones can be emulated quite easily with the corresponding set of call to the libc. The main problem would more be the dependency to the Win32 API thru gdi32.dll, user32.dll, kernel32.dll, etc... But all of these are allready well emulated by wine (you woulnd't be able to run word or winamp with wine without it). Just my 0.02 euros, Sebastien - Original Message - From: "Paul Davis" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 22, 2002 3:23 AM Subject: Re: [linux-audio-dev] Re: The Image (usablity) problem from a Musicians point of view > > VST is a C++ API, and thus its easy for plugins to end up having > dependencies on MSVCRT.dll or its equivalent with other compilers, > which is not available under linux, even with wine. > > DirectX is more of a possibility, since its C API (though i am not > sure if this avoid dependencies on unavailable MS system calls - i > don't know what state wine is in). But there are not very many "pro > audio" plugins under DirectX - lots of instruments and wierdo > enthusiast FX, but not the sort of stuff that ProTools, Nuendo and > Logic users are inclined towards. >
Re: [linux-audio-dev] Re: image problem [was Re: [Alsa-devel] help for a levelmeter]
On Monday 21 October 2002 20:21, Patrick Shirkey wrote: > But am I just wasting my breath because the Agnula crew are going to > do all the work for us? Oh well _now_ you come on to my pet subject. > Anyone from the Agnula project have a position on this? 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
Re: [linux-audio-dev] Re: The Image (usablity) problem from aMusicians point of view
On Tue, 2002-10-22 at 02:23, Paul Davis wrote: > But there are not very many "pro > audio" plugins under DirectX - lots of instruments and wierdo > enthusiast FX, but not the sort of stuff that ProTools, Nuendo and > Logic users are inclined towards. Waaahh!!! I would disagree. The Waves bundles are seriously good and goes for thousands of dollars. Hardly low end stuff. But I do agree that there is a lot of what you say. The instruments are DXi though. > the reason mplayer works is either: > > * they are using wine to help them out > * the codecs are free of all MS system calls > > i'd think that the second one was likely. unfortunately for plugins, > especially DirectX ones that come with a GUI, this is not likely to be > the case there. plugins are at least an order of magnitude more > complex than most codec modules. I never said it would be easy :) -Lea.
