Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

4 participants
7542 discussions

[linux-audio-dev] MMA memebership [was XAP: Some thoughts on control ramping]

by Patrick Shirkey

> digidesign, we had the whole group in that room. i used to have > friends who could have bought most of the companies represented there > out of their own personal accounts :)) people planning on getting rich > in this field are out of their minds. In this context it's seems a little ridiculous that the MMA is requiring members of the mailing list to sign on with $450. Wouldn't it be better for them to either start up an open mailing list or just do it here? I get the impression that the forces involved in making this happen (Ron Kruper and other lurkers may want to speak up here) are missing the point of open source development. Sure it was ok to do what you seem to be doing with this new standard 20-30 years ago when the MIDI standard was created. Times have changed and now the world has open source development. Applying closed methods of communication, or at least requiring a sum of money to be paid to have discussion rights is the equivalent of telling us Open Source developers that either you don't understand what we are doing and why or you totally disagree with the paradigm we work in. Look at the development of the Kernel these days. In a total of 1000 (approx) highly active developers roughly 500 of them are employed by major corporations like IBM, HP, Intel, AMD... The list is obviously very large. It is high time that the professional audio community got involved in the open source process. Your absence has become extreemely noticable. By attempting to make a protocol/specification that aims at providing cross platform functionality you cannot justify using closed, old economy methods of communication. Not when there is a large number of developers who are already communicating on mass in the Open source community. If you want an example of this paradigm working in an audio context you only need to look at the port-audio project. If you want to see the power of the Linux Audio Developers then the best example is JACK. We have created a protocol that neither M$ or Mac developers can provide a better option. If it is the name of the mailing list that is putting you off from being involved around here, just ignore it. All we are doing is making machines work. The Linux part plays a very small role in the wider scheme. Instead of spending the money on hiring someone to do the book keeping and running the mailing list etc... You could be channeling that into Open source. If those other companies can justify it then why can't you? -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide ======================================== Being on stage with the band in front of crowds shouting, "Get off! No! We want normal music!", I think that was more like acting than anything I've ever done. Goldie, 8 Nov, 2002 The Scotsman

23 years, 1 month

[linux-audio-dev] Re: [Jackit-devel] Re: k_jack v0.0.0.5

by Robert Jonsson

Dave Griffiths wrote: >>>It shouldn't be a problem, iwht only a few apps running the overhead is >>>very small. If by "isn't perfectly tuned" you mean not running SCHED_FIFO >>>or a patched kernel that its not that supprising, the context switch will >>>be causing big problems. But, at worst it should just make xruns a bit more >>>frequent, not go from none to some. >>> >>> >>What I have noticed is subtle, I have xruns in both situations but >>the rate increases noticeably. I've been running patched kernels but >>there are all kinds of parameters >>(as I'm sure you know) to tweak before it is sufficiently solid. I >>would consider my findings pretty much expected behaviour with a >>less then perfectly tuned system. >> >> > >I thought I'd pipe up here, as I use jack on a totally unpatched, untuned >system (with SCHED_FIFO) and get rock solid performance. > Hmmm, that's annoying, I've never had that happen to me >:-| ;-) no, seriously, that's really great! Sadly this is not the case for all of us... Would you care to describe your setup, hardware/kernel versions etc...? Regards, Robert

23 years, 1 month

Re: [linux-audio-dev] Re: [Jackit-devel] Re: k_jack v0.0.0.5

by Robert Jonsson

Steve Harris wrote: >On Wed, Jan 22, 2003 at 03:57:40 +0100, Robert Jonsson wrote: > > >>What I have noticed is subtle, I have xruns in both situations but the >>rate increases noticeably. >>I've been running patched kernels but there are all kinds of parameters >>(as I'm sure you know) to tweak before it is sufficiently solid. >>I would consider my findings pretty much expected behaviour with a less >>then perfectly tuned system. >> >>The real problem is that it's so very very hard to tune a system >>sufficiently without hours and hours of work. It would be very nice if >>there was some way to automate, atleast parts of, the process. >> >> > >I didn't have to put any real effort in on my PC (RH8, ide, athlon), >I just installed a patched kernel from Planet CCRMA and rebooted. > >I get xruns at 64 samples/period (and 128 with heavy disk load), but I >think that's a problem with the ext3 filesystem - others have reported this >too. I'm happy at 256 so I haven't bothered remounting the partition to >find out. > >JACK/no JACK makes no noticable difference to the xruns. > Well, as I asked David, care to describe your setup that provides such wonderful performance? /Robert

23 years, 1 month

[linux-audio-dev] Re: [Jackit-devel] Re: k_jack v0.0.0.5

by Steve Harris

On Wed, Jan 22, 2003 at 03:22:42 +0100, Robert Jonsson wrote: > Atleast I have noticed that performance is worse running with jack than > running without it. My evidence is basically running MusE with alsa vs > jack output. Running with jack it is much more prone to produce xruns. > > I have not talked so much about this because: > > a) jack is in development Well, technically, but I regard it as stable in its behaviour. Paul, Kai? > b) I thought it was common knowledge It seems not :) > c) I thought that because the extra weight(scheduling etc) that jack > adds this was perfectly justified. > My system isn't perfectly tuned and that might be the reason I notice > the difference... It shouldn't be a problem, iwht only a few apps running the overhead is very small. If by "isn't perfectly tuned" you mean not running SCHED_FIFO or a patched kernel that its not that supprising, the context switch will be causing big problems. But, at worst it should just make xruns a bit more frequent, not go from none to some. IMHO any runtime xruns at all makes audio software unusable. - Steve

23 years, 1 month

Re: [linux-audio-dev] Additional LADSPA hints

by robbins jacob

>>To my own surprise I have to object to the suggestion: /* >>AUDIO_RATE_CONTROL. Hints than an audio control should/could be controlled >>by a high time res. slider or control data, but shouldn't be connected to >>the next audio signal by default. I can't think of any simple examples off >>hand, but combined with MOMENTARY it could be used for sample accurate >>tempo tapping. */ >> >>As is see it, this declares that an audio port should be used for control >>data. >Yes. At present, ladspa allows two types of port: LADSPA_PORT_CONTROL (one >value per block) LADSPA_PORT_AUDIO (array of values per block) However, >some plugin authors (myself included) wanted finer control over the >parameters, so we 'overloaded' the AUDIO port to allow per-sample control >data. This has been used in many libraries: cmt, swh-plugins, blop, and it >works fine in hosts that allow direct wiring: SpiralSynthModular, >AlsaModularSynth, gAlan. >However, other hosts such as Ardour and Ecasound do not have the same >direct wiring functions, and instead treat any AUDIO ports as exactly that >(making them available as Effect Sends or similar). The purpose of the new >hint is to accommodate these hosts: >LADSPA_PORT_CONTROL (one value per block for control data) >LADSPA_PORT_AUDIO (array of values per block for audio data) >LADSPA_PORT_CONTINUOUS_CONTROL (array of values per block for control data) This is what I'm getting at: the original suggestion was to introduce a LADSPA_HINT for continuous control which would be applied to ports of type LADSPA_PORT_AUDIO. I think that this is misleading because I interpret port type = audio to mean that the port is for audio content as opposed to control content. I agree with the proposal as you present it here, adding a new port type (not a new hint). However, it seems that plugin writers are more comfortable interpreting port type=audio to mean that the rate of the port is audio rate. Steve suggests that it is splitting hairs to try to absolutely determine whether an audio-rate port is for audio or control content. If this is the case then we should just leave 2 port types and add a hint for audio-rate ports that they should be used for control data. I feel I must warn that this will make the ladspa_port_types audio vs control a little misleading to people when they first read the header. If the port type is chosen to be audio and not data then the port should be for audio and not data, right? In short I think adding a third port type would keep the header self-consistent, whereas adding a hint that overrides and reverses the port type is twisting the standard to match current useage. --jacob robbins..... _________________________________________________________________ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail

23 years, 1 month

[linux-audio-dev] RTMix/Linux featured in the latest edition of Organised Sound

by Ivica Bukvic

Hi all, Just to share the good news that Linux got some exposure in the latest edition of the Organised Sound journal (pub. by UK's Cambridge Journals). Stuff covered is RTMix, as well as JACK/Linux audio. Big thanks go to Paul Davis for the help with the benchmark info, as well as everyone else in the Linux community who have made Linux a formidable multimedia platform. For more info on the journal see (it's just an abstract page about the actual journal -- I am still trying to find out how to locate the darn article online :-) http://titles.cambridge.org/journals/journal_catalogue.asp?mnemonic=oso Cheers! Ivica Ico Bukvic, composer, multimedia sculptor, programmer, webmaster & computer consultant http://meowing.ccm.uc.edu/~ico ============================ "To be or not to be" - Shakespeare "To be is to do" - Socrates "To do is to be" - Sartre "Do be do be do" - Sinatra "2b || ! 2b" - ? "I am" - God

23 years, 1 month

[linux-audio-dev] OpenSynth Eko supports Linux ?

by Vincent Touquet

Check this out: - http://www.opnlabs.com/ - http://www.opnlabs.com/ekochart.php [comes with XP or LINUX !] Does anyone know more about this synth ? It really strikes me that you can choose between XP or Linux, its just great :) regards v

23 years, 1 month

[linux-audio-dev] UK Sound-on-Sound article on Linux audio software

by Jim Peters

Just in case no-one else has noticed, the UK number one magazine for professional/semi-professional/serious-amateur sound engineers has carried a long article in their Febrary 2003 issue about using Linux for audio and production. They cover (with links): AGNULA, Ardour, Audacity, LADSPA, CCRMA, Rosegarden and Sweep, along with ALSA card support. A large chunk of the article deals with introducing the concept of Free Software and Open Source, however, as this is probably strange to most of the readers. The closing paragraphs basically mark the Linux audio scene as 'one to watch'. Unfortunately, the web-version of the article is only available to subscribers. I have the print edition. In any case, the Sound-on-Sound web-site is here: http://www.sospubs.co.uk/ It seems a fairly significant happening to me, that the Linux audio scene has got big enough and respectable enough to get the attention of SoS. Also, with this kind of exposure (even though it is only in the UK), maybe more hardware support will become possible. If you are all already aware of this, I'm sorry for the dup, but I did scan the last 300 messages or so to check. Jim P.S. [Off-topic] Maybe some people will remember me from discussions a long while back. I remained subscribed to this list, although I haven't been following discussions. Instead, I've been busy putting my time into DSP stuff and analysis for handling EEG data, as part of the openEEG project: http://openeeg.sf.net/ I developed a wave-viewer for brainwave files that pushes the analysis about as far as I could. It is just about possible to use it for audio, but it is really a bit too slow for that. It is more designed for looking at things that happen on the scale of 1000-10000 samples, say: http://uazu.net/bwview/ I have also recently adapted Tony Fisher's "mkfilter" tool-set to create a GPL'd digital filter design tool. There are still quite a few things I plan to add to this (i.e. it is still in development): http://uazu.net/fiview/ My SBaGen binaural beats tool has also seen some activity recently, although it is really in need of an overhaul now: http://uazu.net/sbagen/ That's about all the news from me. Good to hear that things are progressing so well here, though. -- Jim Peters (_)/=\~/_(_) jim(a)uazu.net (_) /=\ ~/_ (_) Uazú (_) /=\ ~/_ (_) http:// B'ham, UK (_) ____ /=\ ____ ~/_ ____ (_) uazu.net JUST SAY NO! to corrupt audio CDs. For details: http://uazu.net/CD

23 years, 1 month

[linux-audio-dev] Re: [Jackit-devel] hangs with 2.4.20, jack and clients... one tiny patch latter

by Fernando Pablo Lopez-Lezcano

> > >The hang is not happening in any of these processes, as far as I can > > >tell. It is not always in exactly the same place, although it happens > > >always around the same area. I can see time suddenly jumping up, there > > >are xruns printed (huge underruns, not the usual stuff - I assume this > > >is before rt_monitor degrades the priorities and things return to > > >normal). This usually is right after ardour's process function returns. > > >So I have to see which process is actually interrupting all of this and > > >hanging the whole thing. > > > > > >Very confused at this point. > > > > can you check the signalled/awake/complete timestamps in the client > > struct/debug output? these tell you whether/when: > > > > (1) jackd woke the client with write() > > (2) the client woke up from poll > > (3) the client wrote to the next fifo > > > > these are 3 critical steps that tell you whether or not the hang > > happens between the two processes, or within one of them. each > > situation is drastically different from the other and we need to know > > which it is. > > If I understand things correctly the problem seems to be happening in > the alsa_driver_process function (or in alsa itself). Here a list of > what happens just before the hang with some comments, please correct me > if I'm wrong: [very long printout of trace deleted] Just by chance I stumbled on this message: http://www.redhat.com/mailing-lists/ext3-users/msg08990.html (I was looking at latency issues on a 3ware controller - no matter what I do I get 12-18 mSec hits - google for vm.bdflush and look at the second link) "This patch fixes an inefficiency and potential system lockup in the 2.4 kernel's ext3 filesystem. The problem has been present since 2.4.20-pre5." Aha!! pre5 is when I started having problems! Latter Andrew tells us: "Unless task A and task B happen to both have realtime scheduling policy - if they do then kjournald will never run. The state is never cleared and your box locks up." The problem always happens with realtime scheduling :-) So, I patched the kernel and I've been running jack+ardour SCHED_FIFO for more than an hour (previously it would die at most in a couple of minutes). Even stressing the disk with a nice tar. I would hate to have to post in 1/2 hour saying that it locked again, so this time I will _not_ say the problem is solved :-) Try it out. -- Fernando

23 years, 1 month

[linux-audio-dev] ecamegapedal 0.4.0 released

by Kai Vehmanen

1. A short summary of changes Sliders for parameter control and text inputs for lower and upper bounds have been added as well as support for LADSPA-1.1 and ecasound effect parameter hints. There has been some user interface improvements and a native JACK support has been added. Updated to use the new ecasound-2.2 libraries. --- 2. What is ecamegapedal? Ecamegapedal is a real-time effect processor software with a graphical user interface for controlling the effect parameters. It is meant to be used as a virtual guitar-fx or studio effect box. In addition to real-time operation, ecamegapedal also supports reading from and writing to audio files. All audio object and effect plugin types provided by the ecasound libraries are supported. This includes ALSA, JACK, OSS, aRts, over 20 file formats, over 30 effect types, LADSPA plugins and multi-operator effect presets. Ecamegapedal's implementation is based on ecasound and Qt libraries. Ecamegapedal is licensed under the GPL. --- 3. Changes since the last stable release * Added native JACK support. If compiled with JACK support enabled, ecamegapedal will upon startup fetch the current engine parameters from the JACK server, and initialize the ecamegapedal configuration to work with JACK. In practice this means that you don't have to manually set the buffersize and sample rate parameters to use ecamegapedal with JACK. * Support for LADSPA-1.1 and ecasound effect parameter hints. * Text inputs for overriding default upper and lower bounds for parameter values. * Sliders for controlling parameter values. * Pixmaps for transport control buttons. * Takes advantage of the newly released ecasound 2.2.0 libraries (does not work with older ecasound releases). * Should work with all released Qt2 and Qt3 versions. Tested with qt-2.3.2, qt-3.0.5 and qt-3.1.1. --- 4. Contributors Patches Kai Vehmanen Arto Hamara Bug Hunting Jaakko Prattala Justin Rosander Junichi Uekawa Feature proposals Dan Lyons --- 5. Links and files Web sites: http://www.eca.cx http://www.eca.cx/ecamegapedal http://jackit.sourceforge.net Source and binary packages: http://ecasound.seul.org/download http://ecasound.seul.org/download/ecamegapedal-0.4.0.tar.gz -- http://www.eca.cx Audio software for Linux!

23 years, 1 month

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev