On Saturday 30 July 2005 04:46, Lee Revell wrote: Would you care to elaborate on why Portaudio would be a good system for both professional audio and casual desktop users ? What does it offer that ALSA and jack do not, or in conjunction with ? --markc

On Saturday 30 July 2005 06:51, Christoph Eckert wrote: This is an explanantion from kde-multimedia(a)kde.org as to just why it would seem to be a problem... The design is basically flawed for desktop audio since it delegates real-time low-latency work loads through unix pipes to the audio applications. You cannot expect all audio applications to run real-time and you can not expect users to apply custom patches that allow jack to hand out real-time privileges. As far as I can envisage, by the time KDE4 beta starts shipping that all/most distros will also be shipping at least a 2.6.12 kernel with a rtlimit patched PAM. Certainly by the end of this year. If that means "least problematic" then sure, if "most mature" also means most widely deployed for any audio work that matters then the choice probably should be JACK. It runs on Mac OSX and probably other unices using Portaudio and consider the timeline for KDE4. An extra complex layer on top of the one that really counts. KDE4 has the opportunity (maybe) of doing this. Once another subsytem gets into the SVN repository then JACK will never become the default option. Right now, in mid 2005, there is a small window of opportunity for JACK to become the default sound server for one of the major linux desktop systems. If this were to happen then we'd (linux) have half our future desktops come by default with a world class professional audio subsystem second to none. Hello Hollywood. It kind of half solves both the audio and video issues. Does anyone on this list use gstreamer to get Rosegarden, hydrogen, ardour and JAMin to work together ? Does gstreamer allow kino and cinelerra to work together ? Fear the fear of a decision like this being made by folks that do not use the wonderful ALSA/JACK enabled audio toolset that we are all so familiar with on this list. Thanks. --markc

I think the same. Surely desktop bells and whistles don't need low latencies, but would it hurt? No. Best regards ce

On Wed, 2005-08-03 at 02:24 +0000, Steve Fosdick wrote: I believe it kicks them out (the error is something like "CPU usage exceeded"). Kicks them out. Lee

Mark Constable <markc(a)renta.net> writes: For the record: this problem is finally solved in recent 2.6.12 kernel sources, which now allow realtime privilege assignment via rlimits. Once mainstream distributions add the necessary PAM and shell patches to go with that, *no* custom patches will be required for handing out realtime privileges. -- joq

On Fri, 2005-07-29 at 15:43, Lee Revell wrote: Hmmm, seems to work here in 2.6.12. If I understand the bug correctly it does not work when you limit the max rtprio but it does/should work when it is equal to the max available (ie: 100). Is that right? -- Fernando

Hi all, as Scott Wheeler isn't a subscriber to this list he was not allowed to send it to the list directly. Instead, I'll forward it for him: ====== As I haven't seen the rest of this discussion, but it seems out of place to me. Pretty much any discussion on the future of KDE multimedia should happen on the KDE multimedia list (kde-multimedia(a)kde.org). Discussions anywhere else -- for better or worse -- are likely to be fruitless. Correct. is Well, it's a step back from that in a sense. We're kind of punting on this one for KDE 4. Matthias Kretz has been working on a generic API for "typical" user applications (think players and maybe some basic recording) that will load plugins which implement the API. GStreamer will certainly be one of those and may be the default, but also as was noted GStreamer isn't a soundserver or collection of drivers. It's a framework for creating multimedia pipelines that handle demuxing, decoding, processing and then dump them somewhere -- there are "sinks" for various audio and video systems. The same goes for NMM, which is another likely candidate for a plugin in mentioned API. because Actually it won't be an option because it's a soundserver. We're not looking for a soundserver, we're looking for a multimedia framework. How the sound gets to the soundcard/soundserver is up to that framework. something a had Just to repeat again -- KDE most likely won't be choosing a soundserver. At the very most we may have some recommended defaults. I said it above, but it's worth repeating -- Jack is a soundserver; the problems that Jack solves aren't really all that relevant to KDE's multimedia decisions -- they're orthogonal to them. -Scott -- Three words: you have no clue -Slashdot

sorry, wrong. What about the gamers? What about keeping audio and video in sync? What about the (still missing) Garage Band clone on the KDE desktop? All of these will need low latency, and especially Garage Band is a product for Amateur use. We're on free software, and there's no need (at least from a technical POV) to deny desktop users the use of low latency audio and video. We're at an important "point of no return": We can make the right decision *now* or the audio and video struggle will continue. Best regards ce

On Saturday 30 July 2005 07:44, Lee Revell wrote: The need for podcasting may even preempt a Garage Band clone. Two points... the "95% of (KDE) apps" that just want to beep to the sound card have evolved on pre-JACK enabled systems and therefor have had no chance to be used in a more savvy way. It is not customary to plug and play various native KDE audio apps together because historically there has been no facilities to do so, hence that genre of audio software remains "dumb". Second.. if Skype for linux was JACK enabled right now I could use it for two way recording interviews for podcasting. I can't, even on a hardware mixed commodity SBlive card. The point solidly remains in my mind that if a future KDE4 was fundamentally based on JACK, for audio, then even the crappy dumb tools could become far more useful when used together in ways that we have currently not even thought of.... and in a way that is not strictly ONLY the realm of pro/serious audio users. --markc

Any recordings?!? ;) Have fun ce

Christoph Eckert wrote: Sorry, no... We were just talking via Skype... (too bad Gnomemeeting doesn't work with Jack or oss2jack or jacklaunch or .asoundrc plugins... I would have set up some effects to try to brighten the voice...) :( you all too! ciao -- salvuz POST FATA RESVRGO Linux registered user #291700 | machine #174619 get counted on ---> http://counter.li.org/ <---

On Sat, 2005-07-30 at 19:32 +0200, Esben Stien wrote: File a bug report in the ALSA BTS, this is what it's for. Lee

Agreed. Best regards ce

Hi Arnold and others :) , Heh, without any doubt the current KDE games don't need realtime for audio. What I'm talking about are shooter games or even car races, maybe with force feedback joysticks. You press the fire button, the enemy dies and after that you hear the sound of your gun? You play a car race, crash your competitor and after 2 seconds you'll hear the audio? Currently not, but AFAIK the design of JACK allows any kind of streaming data. Likely. Why isn't JACK the default? But OTOH it would be nothing bad to also play bells and whistles with low latency, right? OK, that's an argument. Hehe. I don't think that JACK will die soon ;-) . OK, still there's no video support, but decoding counts. It's not the Job of JACK. [...] The goal is not to change any decision. I'm interested in drawing a picture to compare what we need and what we already have to simplify and improve the Linux desktop experience. In theory, yes.It's a fairy tale as the tale about open file formats. Can I open a Rosegarden file in MusE? No... Best regards ce

Arnold Krille writes: How do you know it doesn't need it? Because no one has required it before? Maybe it doesn't need it because it was never available to be used? This argument reminds me of so many silly ideas in history--the world is flat, char-based consoles is all we need for our powerful mainframe computers -- why should we connect unrelated computers from around the world together in a network, what would they possibly have to share. Once upon a time the planet had not been circumnavigated, all computers used line printers for output, and the Internet was someone's strange idea. Is that a reason for not going around the world? Is that a reason for saying no to GUI and pointing devices? Is that a reason to keep computers isolated?? After all, an isolated computer is certainly secure from viruses, spyware and other malicious invasions. This word keeps coming up. Professional. It's stated over and over in these messages as the reason why KDE cannot adopt Jack. Jack is for "professional use." And KDE isn't? Did I miss the policy statement somewhere that says: "KDE is for amateurs?" "For casual, and occasional computer users?" "For children?" And I thought we were all about building an environment that facilitated anyone's ambition. Want to be a casual user of games when you're 6 years old? Great, we want Linux (and all it's various subparts) to be for you. Want to program C++ when you're 10? No problem, we've got all the tools--no extra price. Want to emmulate Mozart and write a 21st Century multimedia opera when you're 16? No probl .... ..... Wait, it seems you can't use KDE. That would be "professional." Please explain what's wrong with being professional, with supporting professionals, with professionalism. Because these complaints are voiced so much I am coming to believe you are against "professionalism." Maybe your decision is the right one for KDE--maybe it is unfortunate. But you really must come up with better explanations. Even a simple "We don't want to" would make more sense than the than this "not needed" and "it's for professionals" rationale. In point of fact the question, as someone in this thread said, is not whether KDE does X Y or Z at this particular time, but whether KDE has the vision and leadership to step up and forge progress toward a solution the wider community desparately needs. The problem won't go away. Sound management on the Linux platform is a shameful disaster, imho, today. It seems too many decision makers just don't regard audio as important. Well we are sensient beings, we humans. We (most of us) hear, see, smell, touch, and feel. Telling us that any one of these abilities is marginal may make your current task simpler, but it will not engage the wider population of children, casual users, amateurs -- or professionals. This thread has not come about because LAU desperately needs KDE. It has come about because the audio professionals in your Linux familiy see an opportunity to move the Linux environment forward in an area where it currently lags and languishes in indecision and neglect. KDE can choose to say "We're not interested," but that will only push the problem on for the next group which comes to a major rearchitecting. But, sooner or later, the issues will be addressed -- or this environment will wither. I'm convinced it's that fundamental--but that's another email. The only question for KDE is whether they want to be leaders or followers. Janina -- Janina Sajka Phone: +1.202.494.7040 Partner, Capital Accessibility LLC http://www.CapitalAccessibility.Com Bringing the Owasys 22C screenless cell phone to the U.S. and Canada. Go to http://www.ScreenlessPhone.Com to learn more. Chair, Accessibility Workgroup Free Standards Group (FSG) janina(a)freestandards.org http://a11y.org

(snip) (snip-done) So here's the "but that's another e-mail"... I'm curious on the general direction LAU contributors feel Linux audio in general is taking. Obviousley, there has been growth and with that there are natural associated "growing pains". With the "professional vs non-pro" piece removed from the discussion...where are we going? By that I mean should the nature of open source be the driver in Linux audio and leave it such that there a *many* options (applications) for you to do the same job but none of them really "talk" to each other well or play nice together. should more cohesive methods of application development be created? WOuld that remove a fundamental reason / motivation that developers even bother to pour thru code in Linux in the first place? What would the comgregational effort look like if it were warranted without it looking / smelling like a M$ type solution (It's mine...i'll do it my way because I can...not because I think it will be usefull to you) To the current Linux audio devs...Muse, Jack, Ardour, Rosegarden, Csound, Wired, etc all and any...what motivates you to create these apps? Surely it's not money? :) So what is it? Are you genuinely magnanamous? Did you have a need for yourself and decided to share? Are you a visionary? Do you do it just 'cause without need for acknowledgement?? This is not a judgemental statement on my part. If you will indulge me, I want to know what makes you spend the time you do on this stuff so guys like me can pilfer legally and freely your hard works and then subsequently bitch at random about how it doesn't work! :)(tongue in cheek bit). If you had your druthers and were tasked with organising one desktop dev group, along with the full crew of audio related devs and any other individual or clustered components needed (RT capable kernels, file systems, etc), how would you propose it be done. What parts might you organise and others leave as is? Is doing this in Linux a mutually exclusive based wall that was never intended to be scaled? Personally, I don't think it can or should be done in large scale...but the "low hanging fruit" in this topic could generate some interesting perspective. And as the originating topic demonstrates, there certainly seems to be conflicting conceptual opinion between development groups in different corners of the OS in general... R~

Last Saturday 30 July 2005 18:01, Jan Depner was like: I understand the tongue in cheek-ness of this remark, but I think you've muddied the waters by using this analogy. JAMin is a good example. I'm really impressed with the way it was developed collaboratively, starting from a discussion here & on LAD AFAIU. I like the fact that it's not a drop-in replacement for anything I've ever seen before (my experience of music software outside Linux is limited) I like what it does, the way it does it and I LOVE the way it looks. In fact, the only thing I don't like is its heavy use of resources on this machine, but I suspect that's a direct result of the sort of processing involved and I'm not expecting that to change. Soon I will own a computer that was made this century. Describing yourselves as those who "bitch at random" is self-deprecating to say the least. I'd like to see more projects happen this way. cheers, tim hall http://glastonburymusic.org.uk

JAMin is one of the many apps I think is very versitile and generally just works. I have used apps in windows such as Ozone for the same thing. It's expensive and has nice eye candy...other than that it offers nothing that JAMin and the suite of LADSPA plugins cannot do. The "bitch at random" statement along with the other was probally better pointed to a Windows community! I officially retract these implied actions and stand corrected. I resign my post as ....as....well...nothing! I don't have a post! Simply put, I wish to understand more about the reasoning and interactions of the "ecosystem" so that I might attempt to convey it to the many nae sayers I relay interesting Linux audio banter to. They tend to look at me like the "deer in the headlights" when they understand that there is literally little or no financial motive.

Certainly not my intent. They say bad humor is better than none. Perhaps not...

On Sunday 31 July 2005 07:04, hanaghan(a)starband.net wrote: Very well put, thanks. This is indeed the question I hope the core KDE multumedia devs contemplate. Like I mentioned, once some non-JACK based system is decided upon then it's all over and only fragmented retrofits will be available after that. I can well imagine the "KDE" focus of the previous thread would irritate the Gnome, and otherwise, folks but the point is that if one of the 2 main desktop systems get a chance to explore a "deeper" and "better" sound susb-system then the other will benefit as a co-absorber of any positive results without going through the exploratory development pain. It's all about standards. Look at the world of disparate web browsers from various open and closed sources... they all mostly work with most web pages remarkably well. Anyone can point out the exceptions where this analogy falls apart but that "they all work" is by dar the greater attribute. Why ? Extensive W3C and IETF standards. You make it sound like a one way street all about the developer(s). A "project" cannot survive without users. If users do not use the software the developers are sweating over then that software project will go nowhere and die. Every bit as much as us users leach the efforts of developers is the developers need us as users or else their efforts will come to nothing... they also need to pay homage to their userbase... or another project, that does so, will succeed in the long term and their baby will not. There are so few documented "standards" in our open source audio world that there is no, or very little, glue to bind us all. Somehow "fixing" this issue will, I believe, sort out a lot of a the other issues you raise. --markc

Seems to me in my limited foundational understanding of all this, and with ALL due respect, that the point has been missed...or rather...there are many points being made without recognizing the synergies. Your outline of what KDE will or will not do is ok with me. If it doesnt work great for me....I have options...I use another window manager or desktop! There are quite a few to choose from now...but what I don't understand is this; one of the underlying themes in this DL is the attraction of Linux audio systems to Windows converts. To make that easier, it obviously is a requirement to simplifiy som things. It would seem to me the KDE (and don't get me wrong here...I love KDE!) Desktop has become quite advanced in the 4 yrs I have used it....It used to have no clue what file I clicked on in say...Konqueror! It has many memory sucking background "services" running to improve it's intuitiveness...why is audio and for example, the point Davis made (and I believe he demonstrated clear Un bias in his comments for and against one of his own developments) with regard to Coreaudio or something with as much versitility, NOT a consideration when it would appear to be directly in line with the other optimizations KDE has included in their wonderful Desktop? Not a flame in anyway or intended to agravate; I DO love KDE!!! But the limits that seem to apply in thinking here as to what gets in or not in development almost sounds M$ esque on some levels... Just food for thought. R~