Re: [linux-audio-user] Re: [linux-audio-dev] Hunt for old list archives.
Hello, On Thu, 22 Feb 2007, Eric Dantan Rzewnicki wrote: On Wed, Feb 21, 2007 at 06:12:19PM -0500, Ivica Ico Bukvic wrote: I did find the Stanford archives but unless I am missing something (and please do correct me if I am wrong) the early years (98 for instance), at least from what is available online, seems to be incomplete. Are the yes, I'm afraid nobody seems to have the very first messages (from 1998) archived. A similar discussion from 1999-2000, together with some list history, is available at: http://lalists.stanford.edu/lad/1999/05/0797.html http://lalists.stanford.edu/lad/2000/Mar/0001.html http://lalists.stanford.edu/lad/2000/Mar/0008.html This is sort of explained in this thread: http://lalists.stanford.edu/lad/2000/Mar/0001.html Kai recreated the archive using his mbox starting from the day he joined around June 1999. The messages from before that day must have come from someone else ... Yes, some people provided me with earlier messages from 1998-99 and I merged them to my archive (which was first at eca.cx/lad[adu] and now at lalists.stanford.edu). If someone can find even earlier messages, I'm happy to merge them to the online archive! -- links, my public keys, etc at http://eca.cx/kv
Re: [linux-audio-dev] Hunt for old list archives.
Hello all, On Wed, 21 Feb 2007, Joern Nettingsmeier wrote: Marc-Olivier Barre wrote: As discussed previously on this list, we are getting ready for a migration of the three LA* lists to linuxaudio.org. kai, do you still have copies of the old archive, or have they all been migrated to ccrma? yes, I still have the full archives for all the three lists (starting with LAD in 1998). I'm also maintaining the archives at http://lalists.stanford.edu/ ... plus I also maintain the URLs to the old LAA/LAU/LAD archives at eca.cx alive (they now refer you to the above stanford hosted site; try for instance http://eca.cx/lad/2004/12/ ). I'm using a simple rsync script for lalists.standford.edu, so I can easily upload the whole set elsewhere as well if needed (although preferably the continuous updates only to one place). I'm not that fond of moving the archives around very often, as you always risk breaking zillions of links (LAD/LAU/LAA archives contain a lot of useful stuff people can link to from blogs/articles/etc/etc). -- links, my public keys, etc at http://eca.cx/kv
[linux-audio-dev] Re: [linux-audio-user] donations or sponsoring?
On Tue, 6 Feb 2007, Leonard Ritter wrote: from http://www.leonard-ritter.com/donations_or_sponsoring I keep bouncing an idea in my head, thinking about how to strengthen the bonding between open source software developers and software users. Possibly old news, but in case you haven't read this yet, Luis Villa has some excellent insights on the topic -- and especially the point that paying volunteers can have a counter-intuitive effect: http://tieguy.org/blog/2006/06/18/crowding-out-of-intrinsic-motivations-aka-the-bounty-problem/ This is not to say the idea is bad, quite the opposite. It's just it seems to be really hard to find a sustainable balance. -- links, my public keys, etc at http://eca.cx/kv
Re: [linux-audio-dev] crossplatform atomics
On Thu, 25 May 2006, Lee Revell wrote: On Thu, 2006-05-25 at 19:57 +0300, Kai Vehmanen wrote: Does someone have a good reference on this? I think the writes just Do we still care about 32 bit sparc? Not necessarily much, but I'd like to understand this fully. There might be other archs affected as well. Again looking at the Linux kernel code - for instance armv6 atomic_set needs spinning (but not for armv4)... so it's not just sparc32. There might not be _that_ many sparc32s out there, but there are over 3 billion arm cores out there. ;) But, but, even on these platforms, it's just the writes. It'd be interesting to know if there are any cases where you could be reading bogus values due to concurrent access to an 'int'. -- links, my public keys, etc at http://eca.cx/kv
Re: [linux-audio-dev] crossplatform atomics
On Wed, 24 May 2006, Paul Davis wrote: sizeof(int) is your friend not sure what you mean, but on sparcs, int writes are not atomic unless you only use the lower 24 bits. Does someone have a good reference on this? I think the writes just are not atomic, but you can use some tricks [1] to implement atomic behaviour by spinning until the operation succeeds. [1] http://www.freepatentsonline.com/5666546.html?highlight=5434995 .. I'm not sure maybe this is just one variation... But, reading the Linux 2.6.16.17 code for sparc (atomic.h and atomic.S), only the writes are protected, not reads. So as long as you have only one writer, you should be safe. Also, the 24bit limitation only applies if you are using the low 8bits for spinning. Anyways, a good (accurate and available online) reference for this would be nice to have, to be 100% sure before making any architectural decisions. For me, I'd be happy to just exclude these platforms, or use mutexes as a crude workaround on the affected platforms (assuming there're only few of them). Cross-platform atomic integer operations would be nice, but you can do quite a lot with just atomic read/writes, which most of the platforms already provide for 'int's. For example, these are sufficient to implement a simple one-writer-one-reader lock-free queue (which is necessary in most audio apps). OTOH, it is probably wise to explicitly mark all code where ints are assumed to be atomic w.r.t. read/writes (or any other non-standard properties). Especially if sparc-style atomic properties become more widely used later on... -- links, my public keys, etc at http://eca.cx/kv
[linux-audio-dev] Re: [linux-audio-user] www.linuxdj.com - down!
On Fri, 12 Aug 2005, R Parker wrote: s. subject. down for me for quite a while already. And still seems to be. :( I guess Benno is still the admin contact for the site -- anyone got a more recent email address for him? Please somebody fix the server. I'm experiencing extreme lad mailing list archive withdrawl syndrome (elmlaws) disease. Fortunately the web archives are hosted on a different server: http://lalists.standford.edu -- links, my public keys, etc at http://eca.cx/kv
[linux-audio-dev] voice/video calls/conferencing and JACK (was: Re: Mix Minus with AM-Pitchshift; a study in LinuxAudio usability)
Hello all, sorry for cross-posting to lad -- this just in case there are any interested developers out there interested in this topic... On Fri, 29 Jul 2005, Dan Mills wrote: Imagine the ease and fun of having asterisk hooked up to jack and doing voip;) Does anyone know of a SIP or asterisk client that does jack? This is still very much work in progress, but FarSight project - http://farsight.sf.net - is working on to create a library for handling audio/video calls and conferencing, with multi-protocol (SIP, MSN, etc) support, and built on top of the gstreamer media framework. I'm involved with adding SIP support (very much standard compliant, and open-source) to the project. And, as gstreamer has JACK support (btw; Andy Wingo from gstreamer was one of the early members of the JACK team), you will be able to do lots of nice stuff with this technology (= with apps utilizing FarSight) once the project matures a bit more. It is still open who will first adopt FarSight, but it is targetted towards IM apps such as Gaim, aMSN, Kopete, etc... and who knows what in the end. If anyone is interested, come and take a look at the project and join the fun! :) I'm not an official FarSight developer (at least not yet :)), so detailed questions should probably be directed to the FarSight mailing lists... Ideally something command line that can be controlled via tcp messages? You can already do some basic audio/video streaming over RTP to/from JACK using just gst-launch (put together chains of rtp, codec and jack sink/sources). This can be easily controlled from the command-line. But, but, as mentioned already, this is still work in progress... -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] Best-performing Linux-friendly MIDI interfaces?
On Mon, 13 Jun 2005, Jay Vaughan wrote: i mean .. i've been using linux since the minix-list post, and i'll be damned if i can keep up with all this ALSA/esd/OSS/jackd/artsserver voodoo that is expected of anyone wanting to get audio working in linux, at the same/similar degree of operational status as we see under OSX .. even though, i'm very, very eager to see linux function as a working audio platform. there's gotta be -some- way to get it all working, and i dont just mean buy a Dell laptop I must admit, I had to double-check that I really am reading the year-2005 folder of linux-audio-dev, and not some old mails from the archives. ;) Now that SuSE, Mandrake, Fedora and others have started to use dmix as the default output plugin, basic desktop sound stuff should finally start to work, as people expect, out of the box. If anything, rants like the recent one from jwz, are a wake-up call for desktop/workstation-oriented distros that sound is important. Details like configuring dmix and other plugins, making sure the aoss-wrapper is used with OSS apps, etc are important... As for the API-jungle, yup, that's a problem, but it's something really, really hard to avoid in the FOSS world. Just look at the amount of options for video output when you type mplayer -vo help -- no unified API there either. That's not to say that we should give up, but getting majority of developers behind a single API will not be easy... But, but, this is just part of the whole package developers and users see. Fortunately there are other areas where FOSS systems have strengths over the closed competitors. And at least for me, FOSS systems still provide better overall value... (also for desktop use). -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] Other real-time options
On Fri, 8 Apr 2005, Lee Revell wrote: [realtime-lsm not going to be adopted to mainline kernel...] It's a tough call because although the LSM approach clearly is more immediately user friendly, the nice and RT prio limits are a better designed solution. If your distro sets everything up right (a big if), either way it will just work. Btw, on a more positive note, installing realtime-lsm from a separate tar-gz package is super easy. I just upgraded my kernel to 2.6.11.7, and adding the realtime-lsm-0.8.5 module was very, very easy. You do have to set a few /sys params, but this you have to do only once, not for every new kernel. Compared to the trouble I've had to go through sometimes to compile pre-2.4 alsa-driver packages, drivers for various out-of-kernel device drivers, etc, realtime-lsm is just a walk in the park! :) So even if none of the rt-audio enabling options end up in mainline 2.6 linux, I think we are still in a better position with 2.6+realtime_lsm than with anything we had for 2.4 and older kernels. -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] adm: list web archives have moved (was: Re: usb-asx2y on amd64 again)
On Mon, 14 Feb 2005, Mark Constable wrote: The new LA archives can be found at http://lalists.stanford.edu/. Yes, we were going to announce this a bit later, but yup, it's true, the archives have been succesfully moved to their new home! :) Only thing still left to do is to update the links at linuxdj.com. Thanks but I'm not sure that is going to help me all that much because it looks like it specifically searches thru the Finnish Google site... Oops, sorry about that. :) I'm used to the Finnish google.fi URL, and that slipped in by accident. The page is now fixed and submits the searches to google.com, which is probably the correct default behaviour. Hakusi - site:lalists.stanford.edu usb-asx2y - ei vastaa yhtään sivua. Is there an archive around that actually indexes the messages themselves ? Not that I'm aware of. We used to have a dedicated htdig search, but I'm not able to provide this service anymore (still a web based search, not limiting to message contents). And even if someone would offer to host the htdig service, I'm not volunteering for the job. :) Keeping the dedicated search up and running (and debugging why certain searches don't work as expected) can be a bit of a burden, so relying on google.com, search.msn.com (both of which have already crawled the whole new lalists site) and other competitors seems like a nice option to me. PS If you do put up your own archive sites, please apply some anti-spam measures to the email addresses before putting them online (and especially if you put whole mboxes online). The current mailman archives (only replacing @ with at ) are already an easy target for address harvesters. In the current archive at lalists.stanford.edu, I've chosen to hide the tail of email addresses completely to make sure no automated script can harvest subscriber addresses. This only applies to newer messages, older ones are protected by a weaker mechanisms (similar to the default mailman obfuscation). -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] support for non-root realtime scheduling; struggle continues
Hello all, on lwn.net's latest kernel page, under 'Quotes of the week', there's the following message from Jack (O'Quin) to linux-kernel: --cut-- We argued that the owner of a Digital Audio Workstation should be free to lock up his CPU any time he wants. But, no one would listen. We were told that we didn't really know what we needed, and were asking the wrong question. That was very discouraging. It looked like LKML was going to ignore our needs for yet another year. --cut-- The whole post is at: http://lwn.net/Articles/121652/ I hadn't been aware of these latest developments. I then found also this: http://lwn.net/Articles/120797/ Really interesting stuff. I just want to say a big thanks to Jack for pushing the lad requirements forward! As we can all see from the mail threads, it has been, and still is, quite a struggle. In any case it's great that this has now got more attention also outside lad/lau and linux-kernel lists. -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] solved: adm: list archives at eca.cx
Hello all, On Sun, 12 Dec 2004, Kai Vehmanen wrote: Ok, I've been now testing a new, semi-realtime, mechanism to archive the lists. What's important is that this is something I can support also in the future, so the archiving can continue for all three lists. [...] What I'm missing now is web space. I'd need: based on the replies so far, I've now accepted Fernando's offer to host the list archives at CCRMA. As they are already hosting the PlanetCCRMA website and repositories, I guess the LAA/LAD/LAU lists fit nicely there. And a big thanks to all who offered to provide hosting for the archives: - Oliver Thuns - Fernando Lopez-Lezcano - Paul Brossier - Eric Dantan Rzewnicki / Radio Free Asia As always, it's nice to see how the la? community reacts in these situations. ... but now back to the more interesting topics. :) -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] announce-list policy
Hello everybody, when linux-audio-announce was created, it was agreed that announcements should be crossposted to all three lists. The reasoning was that this way people wouldn't have to subcsribe to LAA if they were already on LAD+LAU. Now when you look at LAA archives, some people post only to LAA, some (like me) to all three lists, and some to either LAA+LAD or LAA+LAU. My suggestion is that we drop this policy altogether: announcements should be sent to LAA and optionally to LAD and/or LAU. At least I've always had the nasty feeling that I'm spamming LAD+LAU with my Ecasound release announcements. Of course, when announcing conferences, major new versions (JACK-1.0.0 maybe? :)), etc, I see no harm in cross-posting to all the three lists. So in other words, if you really want to see _all_ the announcements, you should subcsribe to LAA. Any comments? If no objections, at least I will from now on send non-major release announcements only to LAA. -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] Re: [linux-audio-user] Re: adm: list archives at eca.cx going away
Hi, a quick update on this issue. On Fri, 29 Oct 2004, Joern Nettingsmeier wrote: Kai Vehmanen wrote: this is not an urgent issue, but I'd like to warn in advance that the laa/lad/lau list archiving at www.eca.cx/la[adu] will stop some time next year. I'm not sure of the exact date, but sooner or later anyway. Note Ok, I've been now testing a new, semi-realtime, mechanism to archive the lists. What's important is that this is something I can support also in the future, so the archiving can continue for all three lists. What I'm missing now is web space. I'd need: * around +0.5G of web space - the LAA/LAD/LAU archives are currently 0.5G, growing by 15M each month - I'll have to move eca.cx to a new server soon and I won't have enough web space on the new server :( * update via rsync-over-ssh - mirroring the whole eca.cx/la[adu] tree * if at all possible, a separate host name like lists.foobar.org - possibility to use google to search the lists (by searching with site:lists.foobar.com keywords) - htdig is a bit painful to maintain, I'd rather use google ... I will build some server-side magic to make redirects from eca.cx/la[adu] to the new archive location so that existing links to the archived mails will continue to work (and not just temporarily). Now if anyone here is willing to donate some webspace for this purpose (only the list archives, nothing else), please contact me privately. -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] [ANN] Ecasound 2.3.5 released, website addr. changed
Hello all, here's version 2.3.5. Not too many changes, but still enough to warrant a new release. I also want to use this opportunity for the following: *IMPORTANT NOTICE* Ecasound website address has changed. The new address is http://www.eca.cx/ecasound This replaces the old (but still functional) website at http://www.wakkanet.fi/~kaiv/ecasound/. Note that also all the subpages have been modified. I've added some redirect pages, but the old site will only be available for a limited time. Please update any links that point to the old website. And also, my email address has changed (see from). /*IMPORTANT NOTICE** CVS is tagged with 'v2_3_5' as usual, and here are the full details: --- 1. Summary of changes Various Mac OS X specific build issues have been resolved. Minor changes have been made to the OSS soundcard support to avoid limitations of certain OSS drivers. Many minor updates have been made to user documentation and to build system scripts. --- 2. What is Ecasound? Ecasound is a software package designed for multitrack audio processing. It can be used for simple tasks like audio playback, recording and format conversions, as well as for multitrack effect processing, mixing, recording and signal recycling. Ecasound supports a wide range of audio inputs, outputs and effect algorithms. Effects and audio objects can be combined in various ways, and their parameters can be controlled by operator objects like oscillators and MIDI-CCs. A versatile console mode user-interface is included in the package. Primary platform for running Ecasound is GNU/Linux. Ecasound can also be run on many UNIX-derived systems such as FreeBSD, Mac OS X and Solaris. Limited support for Windows is available through Cygwin. Ecasound is licensed under the GPL. The Ecasound Control Interface (ECI) is licensed under the LGPL. --- 3. Changes since last release * With this version, Ecasound can now really be compiled for MacOS X. This has been tested on various 10.3.x systems. Also JACK support is reported to work under OS X. * Website address has changed: http://www.eca.cx/ecasound replaces the old http://www.wakkanet.fi/~kaiv/ecasound address. Please update any links that point to the old address. Full list of changes is available at http://www.eca.cx/ecasound/history.php. --- 4. Interface and configuration file changes None. --- 5. Contributors Patches - Accepted code, documentation and build system changes Berndtgen Manfred (1) -- ecasignalview build error Kai Vehmanen () -- various Bug Hunting - Reports that led to bugfixes (items closed) jcw (1) -- MacOS-X build errors. kito -at- gentoo-org (1) -- MacOS-X build errors. Stéphane Letz (1) -- Builds errors related to JACK and MacOS-X. Paul Marquardt (1) -- Mac OS X build errors. Raul Megelas (1) -- OSS-devices with no GETBLKSIZE support. --- 6. Links and files Web sites: http://www.eca.cx (fi) http://ecasound.seul.org (us) http://ecasound.sourceforge.net (us) Source packages: http://ecasound.seul.org/download http://ecasound.seul.org/download/ecasound-2.3.5.tar.gz md5sum: bbc0c4d12c1d21a7e71fc1bdb9fb0e2b Distributions with maintained Ecasound support: See http://www.eca.cx/download.php -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] [ANN] Ecasound 2.3.4 released
Hi, On Fri, 29 Oct 2004, Stéphane LETZ wrote: Trying to compile on MacOSX 10.3.4 gives : g++ -DHAVE_CONFIG_H -I. -I. -I.. -I. -I../kvutils -D_REENTRANT -D_REENTRANT -ffast-math -fstrict-aliasing -funroll-loops -DNDEBUG -DENABLE_DBC -g -O2 -c eca-chainsetup.cpp -MT eca-chainsetup.lo -MD -MP -MF .deps/eca-chainsetup.TPlo -o eca-chainsetup.o eca-chainsetup.cpp: In member function `void ECA_CHAINSETUP::lock_all_memory() yup, it seems the the -D_P1003_1B_VISIBLE flag is not passed properly to CPPFLAGS (do'h, I thought I had covered this already). Please, could you test the snapshot at: http://ecasound.seul.org/download/snapshots/ecasound-2.3.5-cvs-20041029.tar.gz eca-chainsetup.cpp:621: error: `::mlockall' undeclared (first use here) eca-chainsetup.cpp:621: error: `MCL_CURRENT' undeclared (first use this function) That should handle at least MCL_CURRENT. Hopefully Apple has not done any changes to gcc that would break the '::mlockall()' style of calling globally visible C functions. PS Could you also check that '#define HAVE_MLOCKALL 1' is defined in ecasound-2.3.4/config.h. -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] adm: list archives at eca.cx going away
Hello, this is not an urgent issue, but I'd like to warn in advance that the laa/lad/lau list archiving at www.eca.cx/la[adu] will stop some time next year. I'm not sure of the exact date, but sooner or later anyway. Note that I'm not going to take the existing archives offline, so all links pointing to mails at eca.cx will still work. Fortunately we nowadays have many other archives of the lists. We just now need to pick a new official archive and update the links at: http://www.linuxdj.com/audio/lad/archive.php3 I propose that we use the archives at columbia.edu: http://www.music.columbia.edu/pipermail/linux-audio-dev/ ... and so on. Very good archives can also be found at gmane.org: http://gmane.org/info.php?group=gmane.linux.audio.devel ... and so on. -- http://www.eca.cx Audio software for Linux!
Re: [ecasound] Re: [linux-audio-dev] Re: [Jackit-devel] Maybe I'm going at this wrong...?
Hello, to avoid too heavy cross-posting, I dropped jackit-devel from the cc-list... On Thu, 9 Sep 2004, Eric Dantan Rzewnicki wrote: seeing aren't reported by jackd at all. I only see them from the ecasound instance that is hosting the analogueOsc LADSPA plugins and only when it exits. The rtnull input object reports them when this ecasound instance exits. Every ecasound chain has to have an input and an output. Since I just want the audio from the plugin, which in ecasound's world is an effect attached to a chain between an input and an output, the rtnull input object serves as a place holder virtual audio device/file/thing. Maybe these xruns are red herring? Kai? Definitely! You should use null instead of rtnull if you have any JACK, ALSA, or other real-time objects in the same setup. Rtnull, or realtime null, consumes or produces data at real-time speed (unlike plain null that does the same as fast as it can). This is useful feature in some circumstances, for example when writing audio to a pipe and from there with netcat to network. Without rtnull, you'd overflow the network interface (and the receiving end). But if you have both rtnull and jack/alsa devices in the same setup, you will get xruns, as rtnull is driven by the system clock while jack/alsa are driven by the soundcard clock. Sooner or later the clocks will drift enough and you'll start to get constant xruns. -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] Read this after your first cup of coffee
On Fri, 20 Aug 2004, John Check wrote: I specifically said Cecilia because it's a GUI. IIRC correctly, the ecasound originator coded it up because he found the interface to GUI systems to be dense, which doesn't give me confidence he'd have been able to find his way around an analog studio. Now this I have to commment on. :) I'm the orinagor in question, and I actually do have an analog mini-studio (and had one before I started coding Ecasound) and very much like to use this gear. I don't like to use the DAW-GUIs, because to me they are cumbersome and slow to use when performing simple recording tasks (=those tasks that you do also on analog multitrackers). And this is why Ecasound has been developed to be what it is today. Of course nowadays people perform much more complex tasks when recording and especially when editing. For these, the Ardour/Protools style apps are better suited, no question about it. I also admit that I'm not a visual person in the sense, that I in many cases prefer textual descriptions over diagrams and drawings. This applies to sw architecture as well as to studio signaling -- and I guess to audio app UIs... :) The main feature of ecasound on which I base my opinion is it's signal path from scratch nature. Basically, it's a virtual kit and you have to put together what you want. This is true, but at the same time ecasound allows you to restore or reuse signalling paths from old projects very very easily (just copypaste or reuse old scripts). When I start a new project, I just copy the relevant script from the previous project, edit the filenames and do other minor changes, and start recording. That takes less than 15sec usually. :) And as I can express the whole state of the studio with a few lines of ecasond options, I can with a quick glance verify to myself that everything is in order. With complex GUIs, there are so many windows, menus and views that it takes time to verify all settings. Hmm, to me ecasound is much like the good old 'find' command. Its syntax seems cryptic (even for relatively simple searches), but when you finally decide to learn how to use it and play around with the different options for 15min-1h, you suddenly find yourself at home with the tool and you feel comfortable building even complex searches. Also much like ecasound, when you create a complex (but useful) find search, you can copy it to a text file or a script, and later on use it as a starting point for new (but similar) complex searches. And also, regular mortals do use find. It's not the first thing UNIX newbies start using, but still, it is used by a lot of (otherwise normal :)) people. I think same applies to ecasound. That's extremely useful, but if an average musician never used ecasound before and awoke at 2am with a great melody, (?|s)he'd never get it tracked because ecasound is too different from the traditional interface paradigm. Now that's not really a good example. No matter what the tool is (analog 4-track, protools, ecasound) you have learn how to use it. I doubt average musician could do much with protools either. Quite a few couldn't operate an analog multitracker. ... Now as for rest of your argument, I don't really disagree with it. Although Ecasound is designed for actual real-life use, it is still a niche product as: o the user-interface concept is unique to ecasound - people cannot reuse their experience from other apps o Ecasound's primary target platform is Linux which itself is still a niche product in the desktop-PC market o Ecasound does not offer a complete DAW feature-set ... and because of these, it will continue to be a niche product for the foreseeable future. And that's perfectly ok to me. :) And I don't think it's fair to use Ecasound as an example of state of Linux audio. Even I (!) rather use Ardour, Rosegarden, JAM et al when demoing to an audience I know are familiar with Mac/Win audio apps. To continue with my UNIX comparisons, that's like showing gdb, emacs and vi as the only options to an audience of .NET/Java developers, when you should be showing DDD, KDevelop and Eclipse as well. -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] /proc/sys var for mlock group-access in 2.6.6-mm1
Hi, this might be old news already, but just in case...: http://lwn.net/Articles/84566/ --cut-- The 2.6.6-mm1 tree includes, among many other things, patches which add two new /proc/sys variables. They are: /proc/sys/vm/hugetlb_shm_group If this value is non-zero, it is interpreted as a group ID which gives access to the the huge pages feature of the 2.6 VM. /proc/sys/vm/mlock_group This variable behaves similarly, but it controls access to the mlock() system call (which locks memory into physical RAM) instead. --cut-- And continues with comments from Andrew: --cut-- The problem, it seems, is that there are no better solutions on the horizon. Says Andrew Morton: Capabilities are broken and don't work. Nobody has a clue how to provide the required services with SELinux and nobody has any code and we need the feature *now* before vendors go shipping even more ghastly stuff. --cut-- This suggests that there is a good chance that realtime-lsm could be accepted to the mainline kernel tree, if submitted! -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] [ANN] Ecasound 2.3.3 released
Hello all, this year's first stable Ecasound release is now out! Most of the final tuning for this release was done last Sunday while watching and listening to the last sessions of 'laconf2'. Many thanks to all the organizers and participants! And special thanks for the excellant net coverage of the event! But now, back to the 2.3.3 release -- here are the details: 1. Summary of changes Bugs in ecasignalview, effect presets, NetECI protocol parser and the C ECI implementation have been fixed. Many build system issues, including errors in building against libsndfile-1.0.4 and older, have been resolved. A separate section covering ecasound.el, the ecasound emacs interface, has been added to the Ecasound Control Interface Guide. The Ecasound User's Guide has also been updated. --- 2. What is Ecasound? Ecasound is a software package designed for multitrack audio processing. It can be used for simple tasks like audio playback, recording and format conversions, as well as for multitrack effect processing, mixing, recording and signal recycling. Ecasound supports a wide range of audio inputs, outputs and effect algorithms. Effects and audio objects can be combined in various ways, and their parameters can be controlled by operator objects like oscillators and MIDI-CCs. A versatile console mode user-interface is included in the package. Ecasound is licensed under the GPL. The Ecasound Control Interface (ECI) is licensed under the LGPL. --- 3. Changes since last release * Preset handling fixes: When saving chainsetups containing presets, values of preset parameters were not saved correctly. Also problems with presets containing untitled parameters have been fixed. * New ecasoundrc(5) setting autodetect for default-output has been added. When selected, libecasound will check for JACK support and whether a JACK server is running, if not found, check for ALSA, then OSS, and finally fallback to using rtnull. This feature is especially useful to apps such as ecaplay. * Fixes to ecasignalview: Proper cleanup after receiving an interrupt from keyboard (SIGINT/CTRL-C) has been added. Originally tested on FreeBSD, but helps on Linux as well. * Ecasound Interactive Mode (EIAM) updates: Added new command 'map-ladspa-id-list' to allow listing the available plugins by their unique ID numbers. A special case value of '-1' is now understood by 'cs-set-length'. This allows undoing any previously set length value. * Ecasound Control Interface (ECI) updates: Added a section on ecasound.el - the Ecasound emacs interface - to the ECI Guide [1]. Several bugs have been fixed in the ECI C implementation. A serious bug in NetECI protocol parser, that caused parsing long (over 32 chars) commands to fail, has also been fixed. * Documentation updates: The Ecasound User's Guide [2] has been updated. Also, a bug in the groff source for the ecasound(1) man page that prevented man from showing the last five pages of the document, has been fixed. * Build system fixes: Problems in building against libsndfile-1.0.4 and older have been fixed. 'libecasound-config --libs' has been fixed to return the full list of external libraries. Based on recent discussions on linux-audio-dev, minor changes have been made to processing CFLAGS, CXXFLAGS and LDFLAGS. Full list of changes is available at http://www.wakkanet.fi/~kaiv/ecasound/history.html. --- 4. Interface and configuration file changes * ecasoundrc(5) - default-output: new value autodetect (default) --- 5. Contributors Patches - Accepted code, documentation and build system changes Michael Ewe (2) -- bugfixes to ecasignalview and ECI C impl Mario Lang (1) -- section on ecasound.el to ECI Guide Eric Rzewnicki (1) -- set of updates to Ecasound User's Guide Kai Vehmanen (n/a) -- various Bug Hunting - Reports that led to bugfixes (items closed) Pierre Lorenzon (1) -- bugs in ecasound's daemon-mode protocol parser Jan Weil (1) -- cs-save dit not save preset parameters Feature suggestions - Ideas that led to new features (items) Jan Weil (2) -- map-ladspa-id-list command, -t:1 option --- 6. Links and files Web sites: http://www.eca.cx http://www.eca.cx/ecasound Source packages: http://ecasound.seul.org/download http://ecasound.seul.org/download/ecasound-2.3.3.tar.gz Referenced documents: [1] - http://www.eca.cx/eci-guide [2] - http://www.eca.cx/eca-u-guide Distributions with maintained Ecasound support: Agnula - http://www.agnula.org AltLinux - http://www.altlinux.com Debian - http://www.debian.org FreeBSD - http://www.freebsd.org/ports/audio.html Gentoo Linux - http://www.gentoo.org Mandrake - http://www.mandrake.org PLD Linux - http://www.pld.org.pl SuSE Linux - http://www.suse.de/en
[linux-audio-dev] [ANN] Ecamegapedal 0.4.4 released
1. A short summary of changes Minor bugs in JACK support have been fixed. Now Ecamegapedal makes sure it won't launch the JACK daemon by accident when probing for available devices on startup. The manual pages have been updated with some new sections. --- 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. Contributors Patches Kai Vehmanen (various) --- 4. Links and files http://www.eca.cx/ecamegapedal http://ecasound.seul.org/download/ecamegapedal-0.4.4.tar.gz --- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] Linux audio presentation, 17.3. at Otaniemi, Finland
Hello all, this comes a bit late, but in case you happen to be somewhere in South Finland tomorrow... I'll be giving a short presentation on Linux audio tomorrow at Otaniemi (hut.fi) at 14.00 [1]. I'll talk a little about general issues of developing apps for GPOSes, introduce ALSA, JACK and LADSPA, and finally show a quick demo of well-known Linux audio apps (full PlanetCCRMA setup). The presentation is part of the Digital Signal Processors and Audio Signal Processing course [2] at HUT, but everyone is welcome to come and listen (and ask tricky questions ;)). The presentation is in Finnish, but I can translate on-the-fly if needed. :) [1] Auditorium S1, Otakaari 5 http://www.hut.fi/Current/getting_to_otaniemi.html http://www.hut.fi/Current/otaniemi_map.html [2] http://www.acoustics.hut.fi/teaching/S-89.510/ -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] Linux audio presentation, 17.3. at Otaniemi, Finland
On Tue, 16 Mar 2004, Taybin Rutkin wrote: What is a GPOS? GPOS = General Purpose Operating System ... Good point, have to remember that tomorrow. :) -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] Ecasound question
On Tue, 3 Feb 2004, Alfons Adriaensen wrote: I've been trying to use ecasound for multitrack recording with a Terratec EWS88MT. This card does not present the same number of capture and playback channels (12/10 or 10/12, I always forget since I'm only interested in the first 8 of each). Apparently, ecasound trips over this - whatever number of channels I try, the reply is always that the 'channel count is not available' or something similar. Is there an easy solution for this ? Try: ecasound -f:32,12,44100 -i alsa,hw:0 -f:32,10,44100 -o alsa,hw:0 ... it should work with all ice1712 cards (I have one myself). The ALSA plugin layer might be (nowadays) able to do the necessary channel conversions automatically so you could only access 8ch (or whatever less than 10/12). To try this, replace alsa,hw:0 with alsa,default or some other ALSA PCM plugin name. Second question: how do I connect an ecasound chain to a specific channel of my card ? There seems not to be any way to specify this. Two alternatives: 1) Connect to multiple chains, and then copy/move/mute channels: ecasound -a:1,2 -f:32,14,44100 -i alsa \ -a:1 -f:32,1,44100 -o foo_ch1.wav \ -a:2 -erc:7,1 -f:32,1,44100 -o foo_ch7.ch ... '-erc:src,dst' copies from channel to channel. 2) Use JACK This allows for more flexibility (you can have each Ecasound chain connected to different JACK port). -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] Ecasound question
On Tue, 3 Feb 2004, Fons Adriaensen wrote: Still trying to understand that. Could you give a practical example ? Say e.g. that I want to play t2.wav and t5.wav to outputs 2 and 5, and record from inputs 1 and 6 to t1.wav and t6.wav. This emulates an 8-track machine playing back two channels and recording two others. How would that be done ? This kind of setup is probably easier to handle with JACK, but anyways, still possible without it: ecasound -a:1,6 -f:32,12,44100 -i alsa \ -a:1 -f:32,1,44100 -o t1.wav \ -a:6 -erc:6,1 -f:32,1,44100 -o t6.wav \ -a:2 -i t2.wav -ea:200 \ -a:5 -i t5.wav -erc:1,5 -ea:200 \ -a:2,5 -f:32,10,44100 -o alsa Input object with the most channels determines the channel count of the chain it is attached to. On the other end of the chains, if an output has less channels than the chain it is attached to, extra channels are discarded when writing to the output. With these simple rules you can route audio between channels and chains, and without bloating the syntax too much. The '-ea:200' at the end of chains 2 and 5 helps to keep the volume constant. This is ugly, but unfortunately something I cannot fix at this point (I'd like to change the chain-mixing semantics from add'n'divide to plain add'n'saturate like in most other systems, but unfortunately doing the change now would break far too many existing scripts/sessions :( ...). With JACK the above would be something like: ecasound -f:32,1,44100 \ -a:1 -i jack -o t1.wav \ -a:6 -i jack -o t6.wav \ -a:2 -i t2.wav -o jack -a:5 -i t5.wav -o jack ... so cleaner, but OTOH you have to manage the connections externally. -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] Ecasound question
On Tue, 3 Feb 2004, Fons Adriaensen wrote: On Tue, Feb 03, 2004 Kai Vehmanen wrote: -a:2 -i t2.wav -ea:200 \ -a:5 -i t5.wav -erc:1,5 -ea:200 \ -a:2,5 -f:32,10,44100 -o alsa Shouldn't there be a '-erc:1,2' on the t2.wav chain (it should go to ouput 2) ? Yes, error in my example. The '-ea:200' at the end of chains 2 and 5 helps to keep the volume constant. This is ugly, but unfortunately something I cannot fix at this Why is this necessary ? Nothing should be mixed... unless alsa inputs 2 and 5 are also mixed in. If this is so, can it be prevented ? Ecasound has to combine chains 2 and 5. Former has 1 channel of audio, the latter 5 channels. Now the problem is two-fold: first, Ecasound does not know that only ch5 of chain 5 has audio and others are in fact silent. Secondly, Ecasound mixes chains by doing channel-by-channel add+divide. So without the '-ea:200', volume of channels 1 and 5 in the stream going to the ALSA device would be halved. It's ugly, but ensures backwards compability. -a:t2 -i t2.wav -erc:1,2 -f:32,10,44100 -o alsa,hw:0 -a:t5 -i t5.wav -erc:1,5 -f:32,10,44100 -o alsa,hw:0 [...] -a:t1 -f:32,14,44100 -i alsa,hw:0 -f:32,1,44100 -o t1.wav -a:t6 -f:32,14,44100 -i alsa,hw:0 -erc:6,1 -f:32,1,44100 -o t6.wav I kind of like this 'per chain' way of writing things. Unfortunately the above examples are not quite correct as '-a:t2 -o alsa,hw:0 -a:t5 -o alsa,hw:0' is not equivalent to '-a:t2,t5 -o alsa,hw:0'. The former creates two devices (which will fail in this case as you can open an ALSA hw-device just once), while the latter creates one ALSA device and connects it to two chains). For this reason, I like to write Ecasound setups with one input/output per line. This helps to write valid setups. Would adding '-erc:1,1' to the a:t1 chain hurt in any way ? It would be nice to have a uniform syntax. It wouldn't change the processing result in anyway, so it's ok. But it does add to CPU usage. -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] Re: Lionstracs.
On Tue, 20 Jan 2004, Doug Wellington wrote: The big difference is that when the job is done, the result is *really* yours to keep. You won't find yourself forced to move to a new environment a few years later, just because someone decides it's Heehee... I know plenty of people still using old environments and technology! Atari? Amiga? Moog? Sequential? Fender? Vox? How [...] old thing...? Heck, no technology is immune to the obsolesence due to latest and greatest syndrome. Look at my Waldorf Microwave XT... But with software it's not 100% the same situation. I've succesfully run my mixing sessions (requiring Ecasound plus various LADSPA plugins) from machines ranging a Compaq iPaq (PDA, the old H3600 model) and a 486SX/25Mhz desktop, to the latest and greatest P4/Athlon machines. I'm pretty confident that I will be able to run the audio sw setup I'm using now on modern hw in the future, too. All it takes is to someone to port Linux to the new hw, and keep the apps I use up-to-date. Both are tasks that I can (in the worst-case) do myself, or pay someone to do. Now as for the stuff I've recorded with Win95/98 audio apps, to access them from a modern PC, I need to buy new license for W2000/XP, and licenses for the W2000/XP compatible versions of the audio software I've used. And if the companies go out of business, I might have to resort to reverse-engineering their session-formats to get access to my old recordings. This can be significantly more difficult (and costly if I pay someone else to do it) than keeping my Linux audio setup running. -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] Re: linuxaudio.org
On Thu, 15 Jan 2004, Marek Peteraj wrote: So, the world of Linux audio developers is not one with a nice uniform viewpoint that's somehow encapsulated in this mailing list. Doesn't that suggest that if this were to be debated Jack, ladspa, does it ring a bell? See the lad archive. I promised myself not to get involved but now I just have to, although only commenting this one specific statement. JACK --- Paul Davis. Discussions happened on LAD but mostly concentrating on the n+1 different proposals and implementations on doing an audio server, and of course, making more proposals. Paul just went ahead and did it. LADSPA - Richard Furse. Although LADSPA is still _the_ example of LAD people working together, we were not closing in on any kind of solution in our discussions back in 1999-2000. Richard went ahead and put the pieces together, and ta-daa, we had a standard. LAD web site - Jörn Nettingsmeier. Again, this is another mostly one man show, that is run so well that others have silently approved it as the official frontend to LAD. ... so history shows (and personal memories of many endless discussions prove it), that Chris is very much right - LAD is not one unified community. We have personal agendas, ties to companies or developer groups, we want _our_ solutions to succeed, etc, etc... but that's not really new. But still, we desperately want to share our ideas about audio development on Linux, and that is something that we share - whether it fits our hidden agendas or not. IMHO the magic of LAD is that it has survived the overblown egos of us developers for so long, and even witnessed few cases of random collaboration. :) And perhaps most importantly, LAD has been a fun place to be - let's try to keep it that way. -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] rt irqs patch to 2.4.23
Hello all, here's a new approach to improving kernel RT performance. This specifically tries to improve interrupt latencies, so it's complementary to the existing preempt and lowlatency patches. # linuxdevices.com article http://www.linuxdevices.com/news/NS3235024671.html Metrowerks Senior Software Engineer and veteran real-time programmer Bernhard Kuhn has created a Linux kernel patch that he claims enables hard, real-time performance in the Linux kernel by adding priorities to interrupts and spinlocks. Kuhn believes his approach to be more natural and akin to traditional real-time operating systems (RTOSs) than the dual-kernel approach taken by real-time projects such as RTAI and RTLinux, and he is hopeful that his patch might one day win enough interest and support to become part of the official Linux kernel tree. # Kuhn's post to linux-kernel http://www.ussg.iu.edu/hypermail/linux/kernel/0401.1/0300.html # Kuhn's announcement http://linuxdevices.com/articles/AT6105045931.html # patch against 2.4.23 http://home.t-online.de/home/Bernhard_Kuhn/rtirq/20040108/rtirq-20040108.tgz -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] reminder about Ecasound Control Interface
Hello,
for those new to the API, Ecasound Control Interface (ECI) is a _simple_
API for controlling the Ecasound engine. It certainly is not, and is not
meant to be, a general purpose API, but it suits nicely to many
small-to-medium-size tasks. General info about ECI can be found at:
http://www.eca.cx/eci
I'm writing this because the recently released Ecasound-2.3.2 added
support for Ruby (contributed by Jan Weil). Prior versions already
provided support for C, C++, elisp, Perl, PHP and Python. So quite a few
in other words. :)
Another thing to remember is that ECI apps can interact with JACK
(including full transport support!), use LADSPA plugins for effect
processing, and perform native ALSA audio i/o.
Second reason I'm writing this now is that I just wrote a small app to
monitor JACK transport position (very much like jack_showtime that comes
with JACK), and it turned out to be an easy thing to do:
--cut--
#!/usr/bin/env python
from pyeca import *
from time import sleep
e = ECA_CONTROL_INTERFACE()
e.command(cs-add jackmon)
e.command(c-add jacmon)
e.command(ai-add jack)
e.command(ao-add null)
e.command(cs-connect)
e.command(start)
while e.last_type() != 'e':
e.command(get-position)
curpos = e.last_float()
if e.last_type() == 'e': break
sys.stderr.write('JACK system pos %6.2f secs\r' % e.last_float())
sleep(0.2)
--cut--
Converting the above to your favorite language is left as an exercise. :)
PS If you replace 's/null/jack/' and add the line
'e.command(cop-add -el:djFlanger,0,5,0.5,50)' ... you've
turned the script into a small JACK-Rack style app
that uses Steve's DjFlanger LADSPA plugin.
--
http://www.eca.cx
Audio software for Linux!
[linux-audio-dev] Ecasound 2.3.2 released
1. A short summary of changes Support has been added for libsndfile. This allows to access a number of new audio file formats such as W64, PVF and VOC files. Integration with libaudiofile and MikMod has also been improved. Bugs in the native Python ECI implementation have been fixed. Rubyecasound, a Ruby ECI implementation, has been added to the package. A serious memory-leak in list handling functions of the C ECI implementation was fixed. This bugfix also affects C++, Perl and PHP ECI implementations. Compiling Ecamegapedal works again as the header files missing from the previous 2.3.1 release are now again included in the dist-package. Many minor bugs have been fixed. --- 2. What is Ecasound? Ecasound is a software package designed for multitrack audio processing. It can be used for simple tasks like audio playback, recording and format conversions, as well as for multitrack effect processing, mixing, recording and signal recycling. Ecasound supports a wide range of audio inputs, outputs and effect algorithms. Effects and audio objects can be combined in various ways, and their parameters can be controlled by operator objects like oscillators and MIDI-CCs. A versatile console mode user-interface is included in the package. Ecasound is licensed under the GPL. The Ecasound Control Interface (ECI) is licensed under the LGPL. --- 3. Changes since last release * Rubyecasound, a Ruby ECI implementation, has been added to the package. Developer documentation can be found at http://eca.cx/eci. Rubyecasound was developed by Jan Weil. * Some files were missing from the previous 2.3.1 release dist-package. This caused the make check test procedure to fail, and also prevented from compiling Ecamegapedal against 2.3.1. In 2.3.2 the missing files are once again included in the dist-package. * Libsndfile support has been added to Ecasound (development item 'edi-33'). Support for libaudiofile has also been improved in this release. The user can now compile in support for both libraries at the same time. It is possible to use command-line options to select which library to use for a given file. Similar improvements have been made to the MikMod support. See the ecasound(1) man page for more details. * Some bugs in libsamplerate integration have been fixed. Upgrading to libsamplerate version 0.0.15 or newer is recommended. This release contains a few important fixes that affect Ecasound. A few examples of resampling with Ecasound have been added to the docs: http://www.wakkanet.fi/~kaiv/ecasound/Documentation/examples.html. * A severe memory-leak bug was found and fixed in the C ECI implementation. This bug affects applications that heavily use EIAM commands that return lists of strings. The C ECI is used by C++, Perl, PHP and Python ECI implementations. * Bugs in the native Python ECI implementation have been fixed. The C-based Python ECI implementation is still selected as the default, but you can override this with the '--enable-pyecasound=python' option to configure. Note, 'native' here means that ECI API is implemented without linking to any Ecasound libraries. Instead the ECI implementation forks 'ecasound' binary on the background and communicates with it using pipes. This allows for clear decoupling between ECI apps and specific Ecasound version. More information about ECI can be found at http://www.eca.cx/eci. Full list of changes is available at http://www.wakkanet.fi/~kaiv/ecasound/history.html. --- 4. Interface and configuration file changes None. --- 5. Contributors Patches - Accepted code, documentation and build system changes Jan Weil (2) -- rubyecasound ECI implementation, new docs Mark de Wever (1) -- typo in libecasoundc-config usage Kai Vehmanen (various) Bug Hunting - Reports that led to bugfixes (items closed) Fernando Pablo Lopez-Lezcano (1) -- preset.h not installed Jan Weil (1) -- the ecacontrol.py bug --- 6. Links and files Web sites: http://www.eca.cx http://www.eca.cx/ecasound http://www.eca.cx/eci Source packages: http://ecasound.seul.org/download http://ecasound.seul.org/download/ecasound-2.3.2.tar.gz Distributions with maintained Ecasound support: Agnula - http://www.agnula.org AltLinux - http://www.altlinux.com Debian - http://www.debian.org FreeBSD - http://www.freebsd.org/ports/audio.html Gentoo Linux - http://www.gentoo.org Mandrake - http://www.mandrake.org PLD Linux - http://www.pld.org.pl SuSE Linux - http://www.suse.de/en Contrib Packages and Add-On Distributions: AudioSlack for Slackware - http://www.audioslack.com PlanetCCRMA for RedHat/Fedora - http://www-ccrma.stanford.edu/planetccrma/software Thac's RPMs for Mandrake - http://rpm.nyvalls.se Apps.kde.com packages for Mandrake
Re: [linux-audio-dev] Tracker
On Wed, 26 Nov 2003, Thomas Webb wrote: As a general rule, musicians who don't care about proprietary vs. open source won't be running Linux to begin with. I hope this won't always be true. It if it, Linux has no future. But Linux is already here! Without guessing how big or small impact Linux will have in audio sw, in the long run, it will definitely have a role. I'm pretty confident that I can open my old recording sessions on a modern PC in let's say 2010. I can already open my sessions on both a 486SX bought in 1992, as well a laptop bought this year. I guess I could keep an old Win9x machine around to access the stuff I've written with old Win9x apps, but what if that machine breaks down - can I purchase an old machine capable of running Win95x, a license for it and all the required sw in 2010? Nopes, I don't want to count on that, I want to access my old stuff on a modern machine in 2010, and Linux allows me this. Knowledge of this - that I will be able to access my music even if I upgrade/change my hardware/distro - is one big reason why I want to record my music on Linux and using FOSS apps. No commercial company - no matter how benevolent - can guarantee me this. I don't personally have anything against commercial software (neither open or closed sourced, even though I personally prefer the former), but it is worth to note that FOSS (free-and-open...) has certain advantages that commercial players can never match, and similarly commercial side has certain advantages which are really hard for FOSS projects to compete with. -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] ecasound 2.3.1 released
1. A short summary of changes Ecasound's emacs mode, ecasound.el, has been updated to version 0.8.3. Due to severe bugs found in the native Python ECI implementation, the C implementation has been again set as the default. Minor interoperability problems with older JACK releases and Ecasound have been fixed. A bug that caused builds against an external libreadline to fail, has been fixed. Also recording problems with the WinTv 401Dbx and other bt878-based devices have been fixed. This release is compatible with the upcoming alsa-lib-1.0 releases. --- 2. What is Ecasound? Ecasound is a software package designed for multitrack audio processing. It can be used for simple tasks like audio playback, recording and format conversions, as well as for multitrack effect processing, mixing, recording and signal recycling. Ecasound supports a wide range of audio inputs, outputs and effect algorithms. Effects and audio objects can be combined in various ways, and their parameters can be controlled by operator objects like oscillators and MIDI-CCs. A versatile console mode user-interface is included in the package. Ecasound is licensed under the GPL. The Ecasound Control Interface (ECI) is licensed under the LGPL. --- 3. Changes since last release Full list of changes is available at http://www.wakkanet.fi/~kaiv/ecasound/history.html. --- 4. Interface and configuration file changes None. --- 5. Contributors Patches - Accepted code, documentation and build system changes Mario Lang (ecasound.el updated to 0.8.3, doc typo fixes) Junichi Uekawa (ecasound makefile bug, doc generation using Hevea) Kai Vehmanen (various) Bug Hunting - Reports that led to bugfixes (items closed) Hirendra Hindocha (2) -- recording problems with WinTv 401dbx, ecacontrol.py bugs Stefan Bundt (1) -- ecacontrol.py breaks under heavy load Dave Phillips (1) -- errors in EIAM help Junichi Uekawa (1) -- compability bug with older JACK versions --- 6. Links and files Web sites: http://www.eca.cx http://www.eca.cx/ecasound Source packages: http://ecasound.seul.org/download http://ecasound.seul.org/download/ecasound-2.3.1.tar.gz Distributions with maintained Ecasound support: Agnula - http://www.agnula.org Debian - http://www.debian.org FreeBSD - http://www.freebsd.org/ports/audio.html Gentoo Linux - http://www.gentoo.org PLD Linux - http://www.pld.org.pl SuSE Linux - http://www.suse.de/en Contrib Packages and Add-On Distributions: AudioSlack for Slackware - http://www.audioslack.com PlanetCCRMA for RedHat/Fedora - http://www-ccrma.stanford.edu/planetccrma/software Thac's RPMs for Mandrake - http://rpm.nyvalls.se Apps.kde.com packages for Mandrake/Redhat/SuSE - http://apps.kde.com/rf/2/info/id/2146 Note! Distributors do not necessarily provide packages for the very latest Ecasound version. -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] [PATCH] oss support for jack
On 14 Nov 2003, Jussi Laako wrote: I've written preliminary OSS driver for JACK. Patch for jack 0.80 [...] If you are compiling with OSS Lite, please comment out the non-S16 formats. Workaround for this: --cut-- #ifndef AFMT_S32_LE #define AFMT_S32_LE 0x1000 #endif #ifndef AFMT_S32_BE #define AFMT_S32_BE 0x2000 #endif --cut-- ... and so on. This should be added before committing this to CVS as most people have OSS-Lite. -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] linux-kernel comments on POSIX capabilities support (fwd)
Crossposting from jackit-devel to here... -- Forwarded message -- From: Kai Vehmanen [EMAIL PROTECTED] Subject: [Jackit-devel] linux-kernel comments on POSIX capabilities support Not too encouraging.. :( http://kt.zork.net/kernel-traffic/kt20031101_239.html#3 Quoting Albert Cahalan: The authors of our code seem to have given up and moved on. Nobody cleaned up the mess. Is it any wonder the POSIX draft didn't ever make it beyond the draft state? -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] distributed multitracking with JACK (fwd)
For those who are interested in JACK's transport functionality, the following message provides a step-by-step example of distributed (as in multiple independent apps participating in the same session) multitrack recording, plus some discussion about current limits and usability issues. Links to the latest snapshot tarballs are available at the very end of this message. For info about JACK transport, see: http://www.joq.us/jack/refman/transport-design.html http://eca.cx/lad/2003/08/0109.html The Feb'03 mail I refer below can be found at: http://boudicca.tux.org/hypermail/jackit-devel/2003-Feb/0052.html It's good to note that I could have used any transport-aware application in place of the Ecasound instance 'ecafoo' to provide audio tracks to record against [*]. The application could have been (assuming proper support is added to them at some point) Alsaplayer, Ardour, SoundTracker, CheeseTracker, Hydrogen, Gmorgan, etc, etc... you get the picture. Similarly the recording client 'ecabar' (an Ecasound instance in our example session) could be replaced by Ardour, Rosegarden, Muse, Audacity or any other multitrack capable audio recorder. Sounds good, doesn't it? :) So let's continue with the example: [*] As we are still developing the transport system and there are only few apps that follow bleeding edge development, I had to settle on using Ecasound. :) -- Forwarded message -- Subject: Re: [Jackit-devel] distributed multitracking It's more than six months now since I last tried this, time for another look at this use case: On Wed, 5 Feb 2003, Kai Vehmanen wrote: -- The good news: [...] I just managed to record a piece with three guitar tracks using three separate instances of ecasound, each instance handling one guitar take. I I did the same again with the new transport interface. Environment: linux-2.4.19-lowlatency-capabilities-tracepatches Midiman Delta44 as the soundcard latest 0.9.6 ALSA drivers latest JACK and Ecasound from CVS (2003-Aug-25) I set jackd to use the _maximum_ latency settings for Delta44 (-n 3 -p 1024) to create the worst possible environment for syncing clients. The test went through unbelievably smoothly. Not a single crash in any app during the whole testing. Unlike in the test in February, this time I didn't have to restart all the clients after each and every take and/or mixdown run. Also, I was now able to seek from any of the Ecasound sessions or from jack_transport and all the other clients would correctly follow the changes. Yay! Nice work Jack (J.O'Quin) and JACK! :D - The bad news: [...] Synchronization is a big problem. Let's say you have the following setup: ... and still is. alsa_pcm- ardour soundtracker- alsa_pcm [...] Jackd is run with -p 1024 -n 2, ST is the sync master, hw-monitoring is used for the alsa_pcm input. The big problem is that there's no easy way for ardour to learn how much non-valid data will come out of alsa_pcm in the start. In this distributed recording case ardour should ignore the first 2*1024 samples (maximum of ST output and alsa capture latency). There doesn't seem to be any easy way around this problem. Somehow we need to provide meta-information concerning how these independent connections between JACK ports are related (from user POV) to each other. To solve this for my test case, I added a new option to Ecasound for specifying explicit multitrack recording offset. The syntax is -z:multitrack,XXX, where 'XXX=n*p', 'n' jackd/alsa_pcm period count and 'p' jackd/alsa_pcm period size in samples. With this meta-info, the multitrack sync works comparably with a session without JACK. And finally, a test script for a minimal distributed multitracking session: --cut-- # 1. launch jackd and jack_showtime (_very_ useful if something goes wrong) # 2. test input levels (play something and verify that the meters #are moving); ctrl-c to exit ecasignalview jack_alsa # 3. create the monitor track to play against (15 secs) sh1 ecasound -i null -o monitor.wav -x -pn:metronome,120 -t:15 # 4. launch the slave client sh1 ecasound -i monitor.wav -o jack -G:jack,ecafoo,sendrecv -c ecasound1 engine-launch # 5. launch the master client (replace 3072 with value corresponding #to the -n/-p params you run jackd/alsa_pcm with) sh2 ecasound -a:rec -i jack_alsa -o recorded.wav -a:mon -i jack -o jack_alsa -G:jack,ecabar,sendrecv -z:multitrack,3072 -c ecasound2 engine-launch # 6. connect the slave client to the master client sh3 jack_connect ecafoo:out_1 ecabar:in_3 sh3 jack_connect ecafoo:out_2 ecabar:in_4 # 6. launch jack_transport and control the two multitrack-recorder #instances sh3 jack_transport jack_transport locate 0 jack_transport play # 7. record something against 'monitor.wav' (check jack_showtime output #if you have problems) # 8. listen to the result (note! we can let the slave client to run #all
[linux-audio-dev] RFC to developers: JACK transport BETA
Hello, we are finally getting close to reaching the original goals set for JACK. The last big step has been the transport interface (to refresh your memory, take a look at the initial JACK/LAAGA use-scenario [1]). Thanks to Jack O'Quin's recent efforts, JACK now finally has a transport interface (and implementation) that fulfills all the requirements, and one that makes it possible to realize the example case [1]. Now at this point we'd _really_ appreaciate your input. If you are short of time, at least take a look at our requirements list at the start of the design doc: http://www.joq.us/jack/refman/transport-design.html The big questions are: 1. Is this API sufficient for your application? If not what is missing and/or wrong? 2. Do you plan to add support for JACK transport to your app? If not, what is the main reason not to (no interest, not useful for your app, you prefer other solutions, etc)? In addition, comments regarding interface and implementation details are also welcome. [1] http://www.eca.cx/laaga -- Forwarded message -- Date: 13 Aug 2003 22:08:09 -0500 From: Jack O'Quin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Jackit-devel] CVS commit [0.77.0] new transport BETA test The new transport interfaces are ready for beta testing. Bring on your applications and give it a try. We will likely want to tweak a few things as problems are discovered. So, please don't release any applications that depend on the new API until the beta test is finished and we cut a new JACK release. But, the design seems stable right now. The reference manual is still at... http:www.joq.us/jack/refman If you don't want to wait for CVS to catch up, here's a tarball... http:www.joq.us/jack/jack-audio-connection-kit-0.77.0-beta.tar.gz Highlights... * new minor version, API version and protocol version -- to distinguish beta test level from earlier snapshots -- source compatible with recent 0.76 snapshots -- transport API not binary compatible: must recompile * functional test complete (except internal clients) -- if you have an internal transport client, try it -- it might work, but I still have no test cases * jackd -v option (--verbose) now prints useful transport state change information for debugging JACK and clients both * includes Bob Ham's makefile fix for the jackrec example client -- Jack O'Quin Austin, Texas, USA
Re: [linux-audio-dev] Linux 2.6 not a latency panacea?
On Wed, 13 Aug 2003, Joshua Haberman wrote: I am distressed. It was my understanding that the 2.5/2.6 kernel branch was undergoing significant scheduler and latency work, and that 2.6 would eliminate the kernel from the list of obstacles of low-latency on Linux. It will have the preemptable kernel patch, the new scheduler, and all of Ingo Molnar's low-latency work. Claims were being thrown around that 2.6 would be the lowest-latency operating system on the planet. Well, while there are plenty of nice improvements from lad perspective, many fundamental problems/features are still present in 2.6. So how is it that we're in the 2.6.0-test series and people are complaining about audio skipping in **XMMS**, which uses three second buffers by default?? If people are getting skips from high-latency playback, what hope is there for low-latency audio? Yup, fact that hasn't changed is that you need SCHED_FIFO to achieve any kind of reliable low-latency audio operation. The problems with XMMS skipping are - while still important - not directly related to the low-latency case. A series of patches are coming from both Ingo and Con Kolivas attempting to address this, but the fact they are just now throwing around potential solutions erodes at my faith that they really understand the problem or how to solve it. These might help the out-of-the-box behaviour (running audio apps without SCHED_FIFO), but will never be good enough for the low-latency case. Is 2.6.x going to be suitable for low-latency (or even reliable high-latency) audio? Or is it going to be more of the same: patching the kernel, tweaking parameters, reading magical incantations, and hoping for the best? I've done limited testing with 2.6.0-test2 on my laptop, and got fairly good results. In my tests it performed nearly as good as my 2.4.19smp-lowlatency, which is promising (as smp is a big advantage in this case). So it looks good, but still you absolutely need SCHED_FIFO. And I'm not aware of any developments in the kernel caps area, so we still probably need to patch the kernel to allow user apps to enable SCHED_FIFO. Yups, it would be great if someone of us would have the time and energy to participate more closely in linux-kernel discussion, and even better, in kernel development. We'd need someone to actively push low-latency improvements to the kernel and keep the issue on the table. For example, one new approach to the problem SCHED_SOFTRR, see: http://www.xmailserver.org/linux-patches/softrr.html http://www.ussg.iu.edu/hypermail/linux/kernel/0307.1/1729.html It's unlikely to get something like this enabled by default in the vanilla kernel, but we might be able to get a kernel option (no patching!). But, but, as you can see from the discussion, they are talking about totally different things (how XMMS/realplayer performs)... ... basicly a way to get benefits of SCHED_FIFO but without need for root privileges. Now we just need to push these to the standard kernel somehow. -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] link: Sound on Sound: Cutting Edge : The Future of Music Technology
Nothing new really, but it's on SoS so I guess it's worth a read ;) http://www.sospubs.co.uk/sos/apr03/articles/cuttingedge0403.asp -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] ecasound 2.2.2 released
1. A short summary of changes A new native Python implementation of the ECI API has been added to the package. Ecasound.el (ecasound-emacs) has been updated to version 0.8.2. Oggs and mp3s can be now streamed directly from network. Author information is now visible in the LADSPA plugin descriptions. Changes in ALSA-0.9 support improve usability of ecasound with the new ALSA dmix PCM plugin. There have been many important bugfixes including correct handling of short parameter fades, broken chainsetup level looping, problems with creating temporary files and minor build system issues. --- 2. What is ecasound? Ecasound is a software package designed for multitrack audio processing. It can be used for simple tasks like audio playback, recording and format conversions, as well as for multitrack effect processing, mixing, recording and signal recycling. Ecasound supports a wide range of audio inputs, outputs and effect algorithms. Effects and audio objects can be combined in various ways, and their parameters can be controlled by operator objects like oscillators and MIDI-CCs. A versatile console mode user-interface is included in the package. Ecasound is licensed under the GPL. The Ecasound Control Interface (ECI) is licensed under the LGPL. --- 3. Changes since last release Full list of changes is available at http://www.wakkanet.fi/~kaiv/ecasound/history.html. --- 4. Interface and configuration file changes None. --- 5. Contributors Patches Janne Halttunen (the new Python ECI implementation) Mario Lang (ecasound.el 0.8.2) Junichi Uekawa (pyecasound.so build) Kai Vehmanen (various) Bug Hunting (items closed) William Goldsmith (2) Michael Hellwig (1) Janno Liivak (1) Raoul Megelas (1) Feature requests (items implemented) Oliver Thuns (1) --- 6. Links and files Web sites: http://www.eca.cx http://www.eca.cx/ecasound Source packages: http://ecasound.seul.org/download http://ecasound.seul.org/download/ecasound-2.2.2.tar.gz Distributions with maintained ecasound support: Agnula - http://www.agnula.org Debian - http://packages.debian.org/unstable/sound/ecasound2.2.html DeMuDi - http://www.demudi.org FreeBSD - http://www.freebsd.org/ports/audio.html Gentoo Linux - http://www.gentoo.org PLD Linux - http://www.pld.org.pl PlanetCCRMA - http://www-ccrma.stanford.edu/planetccrma/software SuSE Linux - http://www.suse.de/en Contrib Packages for Distributions: Mandrake - http://rpm.nyvalls.se/sound9.0.html Note! Distributors do not necessarily provide packages for the very latest ecasound version. -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] Fwd: CSL Motivation
On Thu, 27 Feb 2003, Stefan Westerfeld wrote: [ Paul's msg I forwarded ] I am glad you did write JACK, although back then I thought it was just another try to redo aRts (and we had some heated discussions back then), because some people seem to like it. If some people will like CSL, why not? And just to give you kde-multimedia people a view of the current status, take a look at: http://jackit.sourceforge.net/apps/ JACK has been really been quite a success. The ability to run multiple apps and route audio freely (and easily thanks to qjackconnect!) between them, with reliable low-latency is something that has attracted a lot of developers and users to JACK. A few screenshots (sorry about the eca-emphasis :))...: http://eca.cx/screenshots/jack_and_ecamegapedal_under_heavy_load-20021102.png http://eca.cx/screenshots/qjackconnect_ecamegapedal_ecasignalview_jack-20021102.png What I'm personally most impressed and proud about is that we've been able to get developers from different (some directly competing) projects to work together on this. Although linux-audio-dev is an active communicty, actual code-level sharing so far has not been common. It would be great if KDE (and GNOME) users could join the fun without having to completely abandon desktop multimedia while doing this. The next step would be to close the bridge between kde-multimedia and linux-audio-dev... ;) If you added CSL support to JACK right now, you would never need to bother with any of the sound server guys like me again, because you could always say: support CSL in your sound server thing, and then JACK will support your sound server. Yup, I guess it wouldn't be too big of a task to adapt (for instance) the ALSA's JACK PCM-plugin for the CSL API. Hopefully someone will do this. Do you have any code in place that handles the backend detection for CSL? -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] BruteFIR + jack = crackling noise?
On Thu, 27 Feb 2003, Patrick Shirkey wrote: But it would be very nice if I could use my usb quattro to manipulate the sounds of my bandmates in realtime at lowlatency. I tried with ssm at 64 bytes and there was noticible lag so we couldn't do anything live. [...] The best I can get out of jack is 1024 but 2048 is more reliable. Hmm, that sounds strange. How long is a noticable lag? :) Have you tried with ecasound? I've personally tried a few USB audio devices and didn't experience any unusual latency problems. Something like ecasound -b:256 -z:nointbuf -i alsa -o alsa should be enough for effect-box type real-time processing. Maybe I should test that again... PS Although I must say, due to old USB-related work projects, I have a real love-hate relationship with USB. Nowadays whenever I see someone (un)plugging a USB-device, I automatically expect the machine to halt completely or plain just not work. :) Fortunately there are exceptions, my Rio500 and Midisport2x2 have almost changed my mind.. they actually do work. :) But, but... don't take these words too seriously. -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] ecasound 2.2.1 released
1. A short summary of changes The JACK slave mode code has been completely rewritten. As a new feature it is now possible to use libsamplerate for resampling. Using JACK has been made more user-friendly as ecasound can now automatically configure the runtime parameters to match the current server settings. And thanks to build system and signal handling updates, it's now possible to compile ecasound for win32 under Cygwin. --- 2. What is ecasound? Ecasound is a software package designed for multitrack audio processing. It can be used for simple tasks like audio playback, recording and format conversions, as well as for multitrack effect processing, mixing, recording and signal recycling. Ecasound supports a wide range of audio inputs, outputs and effect algorithms. Effects and audio objects can be combined in various ways, and their parameters can be controlled by operator objects like oscillators and MIDI-CCs. A versatile console mode user-interface is included in the package. Ecasound is licensed under the GPL. The Ecasound Control Interface (ECI) is licenced under the LGPL. --- 3. Changes since last release * If configured with JACK-support, ecasound will now fetch the correct buffer size and sampling rate parameters from the JACK server when connecting a chainsetup with JACK inputs or outputs. In other words you don't have to manually match these settings between the JACK server and ecasound. * Support for Erik de Castro Lopo's libsamplerate resampling library added. If libsamplerate is not installed, ecasound will fall back to the old resampling algorithm. * Rewritten the code that handles JACK slave-mode operation. Ecasound is now able to more quickly and reliably follow transport state and position changes, as initiated by the current JACK timebase master. * Ecasound for Windows! :) With help of the Cygwin environment, you can now compile win32 ecasound binaries straight from the standard source package. As of 1.3.1, Cygwin also contains basic /dev/dsp emulation, so even audio playback works. * Fixed many, more or less serious, bugs. The most annoying ones were incorrect handling of the '-t' option, excessive DBC warnings with JACK inputs and outputs and failing to properly reset the terminal after a CTRL-C while in interactive mode. Full list of changes is available at http://www.wakkanet.fi/~kaiv/ecasound/history.html. --- 4. Interface and configuration file changes None. --- 5. Contributors Patches Junichi Uekawa (build system) Kai Vehmanen (various) Bug Hunting (items closed) Janne Halttunen (2) Eric Amundsen (1) Antti Boman (1) William Goldsmith (1) Andrew Reilly (1) Oliver Thuns (1) --- 6. Links and files Web sites: http://www.eca.cx http://www.eca.cx/ecasound Source packages: http://ecasound.seul.org/download http://ecasound.seul.org/download/ecasound-2.2.1.tar.gz Related sites: http://jackit.sf.net (JACK) http://www.mega-nerd.com/SRC (libsamplerate) http://www.cygwin.com Distributions with maintained ecasound support: Agnula - http://www.agnula.org Debian - http://packages.debian.org/stable/sound/ecasound.html http://packages.debian.org/unstable/sound/ecasound2.2.html DeMuDi - http://www.demudi.org FreeBSD - http://www.freebsd.org/ports/audio.html Gentoo Linux - http://www.gentoo.org PLD Linux - http://www.pld.org.pl PlanetCCRMA - http://www-ccrma.stanford.edu/planetccrma/software SuSE Linux - http://www.suse.de/en Contrib Packages for Distributions: Mandrake - http://rpm.nyvalls.se/sound9.0.html Note! Distributors do not necessarily provide packages for the very latest ecasound version. -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] (OT) C++ flame war
Ugh, OT for sure, but I just cannot resist the temptation to reply to this thread any longer. ;) On Thu, 6 Feb 2003, Paul Davis wrote: conceptually, i am not creating a distinct type of object - i want to provide a particular set of objects with access to a limited set of member functions belonging to an otherwise unified object. C++ won't let me do that - it forces me to use an abstract class, multiple I'd say just use comments to express the access rules. Even though C++ provides public/protected/private, there's no way to actually enforce them - if someone wants to access the private members, it's certainly possible no matter what you do. So you might as well use public for these targeted-for-certain classes sub-APIs and describe the intended audience of the functions in comments. Of course, when public/protected/private are enough, they should be used. Standard language level concepts are always better, as the semantics are known by majority of (competent) developers. -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] List still up?
Hi, no messages so far, so something's up. The archives are up at: http://eca.cx/lad/2003/01/ http://eca.cx/lad/2003/02/ (although no messages) Replaces 'lad' with 'laa' or 'lau' for the other lists. On Mon, 3 Feb 2003, David Olofson wrote: (Well, it got silent again, and I can't check the archive...) Appears that the LAD site is down, and the list archive gives me the PHP code as text/plain... What's going on? -- http://www.eca.cx Audio software for Linux!
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN:k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote: What does cat /proc/asound/card0/pcm0[cp]/sub0/[hs]w_params output I'm at work now, and we ~only have delta cards. At home I use a built-in sound-card on an nforce chipset. But I get nearly the same good performance in pd here as at home. So here is delta44 parameters: Could you also send an output of pcm0[cp]/sub0/status...? Anyway, this is very good info. kjetism@hensten /proc/asound/card0/pcm0c/sub0 $ more hw_params [...] period_size: 64 buffer_size: 1728 So I guess this explains a lot. This equals to running jackd with -p 64 -n 27 (and not as root or otherwise it will throw clients out if they miss one 64 frame deadline). I'm quite sure you get much more reliable performance this way, although JACK doesn't take advantage of multip-period buffer configurations very well. And this has its reasons. With a setup like shown above, you either get a huge latency (64*1728/44100*1000=2500ms), or you get latency jitter (latency varies between 1.45ms-2500ms). Both are something we'd _really_ want to avoid. Because of the above reasons, JACK is designed for two or three period operation (-n 2 or -n 3). This way we can achieve both low latency and avoid latency jitter. We could improve reliability by sacrificing one or both of these goals, but for many of the use scenarios we are aiming at, this is simply not acceptable. -- http://www.eca.cx Audio software for Linux!
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN:k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Paul Davis wrote: period_size: 64 buffer_size: 1728 So I guess this explains a lot. This equals to running jackd with -p 64 -n 27 (and not as root or otherwise it will throw clients Well, this is still true. well. And this has its reasons. With a setup like shown above, you either get a huge latency (64*1728/44100*1000=2500ms), or you get latency jitter not that large. you don't multiply the period size by the buffer size and the 1000 is extraneous too. the maximum latency is 1728/44100 = 39ms, i think. i don't of any h/w that has a 2.5 second buffer!! Arrghghthghhg! :D 2500ms would have made a nice pro-jack argument, though.;) So the correct one is the 64*27/44100*1000=39ms you mention. this is still pretty long, and as you note, pd is not subject to per-period time limits with this configuration. it can take too long on up to 26 of 27 periods before there is an xrun. Hmm, this is quite interesting. With a period size of 64 frames, you'd get quite a lot of context switches with jackd. Kjetil, does your ipc-lib make the context switches this often? Another interesting this is how this high interrupt frequency affects scheduling of (non-root) processes. I'd guess it could have a notable impact on reliability... have to try this later today with jackd. -- http://www.eca.cx Audio software for Linux!
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN:k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Paul Davis wrote:
no, there's likely not much latency jitter in pd either. after the
first 27 periods are filled (which happens in about 39ms), every chunk
of audio delivered by pd to the hardware will be output by the
hardware about 38ms later. the jitter is limited to about 1.45ms,
assuming that pd is roughly keeping up with the hardware. of course,
But there's no way a normal user-space can reliably wake-up every 1.45ms
and manages do finish i/o for next period. The application is bound to
late, much of the time. This is not necessarily fatal if the application
is able to catch up. This is precisely the reason why you can get very
reliably processing with ecasound using -z:intbuf option (maximize use of
soundcard hw buffering).
However, as Kai pointed out, nobody runs JACK with -p 64 -n 27, and if
they did, I suspect that they'd get similar performance to pd. it
Actually, with current jackd you cannot use -p 64 -n 27, as it will
throw the delay of %.3f usecs exceeds estimated spare time of %.3f;
restart ... error and stop the alsa_driver. I made a patch that bypasses
this check and managed to get jackd running with -p 64 -n 27. And indeed,
it runs reasonably well on my laptop (normal user space), but I still
get xrun from ALSA. Below are some stats. As you can see from the
'delay' values, the latency jitter is considerable, even though the test
machine was not doing anything else than jackd+ecasound playback.
--cut--
[xxx]$ cat /proc/asound/card0/pcm0p/sub0/{sw_params,hw_params,status}
tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 64
xfer_align: 64
start_threshold: 0
stop_threshold: 1728
silence_threshold: 0
silence_size: 0
boundary: 1811939328
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 64
buffer_size: 1728
tick_time: 1
state: RUNNING
trigger_time: 1043423501.808278
tstamp : 1043423507.253736
delay : 1204
avail : 524
avail_max : 704
-
hw_ptr : 240268
appl_ptr: 241472
[xxx]$ cat /proc/asound/card0/pcm0p/sub0/{sw_params,hw_params,status}
tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 64
xfer_align: 64
start_threshold: 0
stop_threshold: 1728
silence_threshold: 0
silence_size: 0
boundary: 1811939328
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 64
buffer_size: 1728
tick_time: 1
state: RUNNING
trigger_time: 1043424884.923610
tstamp : 1043424886.101041
delay : 1678
avail : 50
avail_max : 1728
-
hw_ptr : 51762
appl_ptr: 53440
--cut--
--
http://www.eca.cx
Audio software for Linux!
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN:k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote: I'm at work now, and we ~only have delta cards. At home I use a built-in sound-card on an nforce chipset. But I get nearly the same good performance in pd here as at home. So here is delta44 parameters: But how do you know you are not losing any data? I mean... kjetism@hensten /proc/asound/card0/pcm0c/sub0 $ more hw_params [...] stop_threshold: 1811939328 ... there seems to be no xrun detection enabled. At least pd-0.36 seems to set snd_pcm_sw_params_set_xrun_mode(alsa_device.inhandle, sw_params, SND_PCM_XRUN_NONE);. This means that you could be having small xruns all the time! Of course, really long breaks are always audible, but shorter ones are sometimes quite subtle. Still, you are losing audio data. -- http://www.eca.cx Audio software for Linux!
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN:k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote: This means that you could be having small xruns all the time! Of course, really long breaks are always audible, but shorter ones are sometimes quite subtle. Still, you are losing audio data. I guess so. But its not necesarrily very import, at least not for (most kinds of) live performance. Is there a quick way to patch pd so that it detects xruns? Yup, replace the set_stop_mode call with: snd_pcm_sw_params_set_stop_threshold(handle, sw_params, XXX); ... where XXX is the buffersize (ie. 64*27=1728). The difference is definitely notable. I've just patched jackd to ignore all xruns the way pd does, and yup, I can do all kinds of stuff as a normal user (with ./jackd -p 64 -n 27). I'm currently running ecasound+jackd+freqtweak+qjackconnect as a normal user, with the same 1.5-39ms latency as with pd, and while there are occasional audible artifacts, it does indeed work! Also more common jackd setups like 'jackd -d alsa -p 1024 -n 3' work more reliably this way. But of course, as I noted in my previous message, we are definitely losing samples even though no errors are reported. -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] pd/k_jack-ish soft-mode patch for jack (was: k_jack v0.0.0.5 andMammut v0.15)
On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote: Yup, replace the set_stop_mode call with: snd_pcm_sw_params_set_stop_threshold(handle, sw_params, XXX); I'm not able to make that work. Just gets a message about stock audio, no matter how big buffer it is. But thats not important. Hmm, what's the exact error you get? One thing that will cause you trouble is that audio playback will stop after the first xrun. You have to restart the stream (stop-prepare-start) to recover from an xrun. This is also the source of the longer audible breaks that occur with current JACK's ALSA driver when xruns occur. The difference is definitely notable. I've just patched jackd to ignore all xruns the way pd does, and yup, I can do all kinds of stuff as a normal user (with ./jackd -p 64 -n 27). I'm currently running Thats very nice. How about an option for jack to ignore xruns then? True, I just posted a patch that does this to jackit-devel. So, so, as I said, competition is a good thing! ;D So thanks for releasing k_jack and helping with the debugging/tracing work. And, are you absolutely sure its not a bug in alsa, reporting to many xruns? :) This is very unlikely. The code in alsa-kernel/driver that handles this logic is _very_ robust. I haven't done much driver work, but I've still gone through those functions at least a hundred times, and I bet many other developers have done the same. The common PCM subsystem used by all ALSA low-level drivers is really high-quality code. The fact that all drivers can benefit from this common code library is IMHO one of the biggest benefits ALSA brings! -- http://www.eca.cx Audio software for Linux!
Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 andMammut v0.15
On Wed, 22 Jan 2003, Kjetil S. Matheussen wrote: For two years (or somethings), people have complained about the bad performance of the jack system. And I don't think it has been solved. I dont know about alsa; and doesn't understand the driver-code, so it was easier for me just to reimplement jack. First of all, I must say I have nothing against k_jack. I don't think I fully understand the motives (or the mechanims or design features that enable better performance), but as Ron Kuper wrote today, competition is good. I don't think it's fair to expect commercial companies to deal with competition from FOSS groups, while not welcoming competition from other FOSS developers. ;) And yes, there are performance problems with JACK in certain use scenarios: 1. Running with root privileges (and -R) but with a standard kernel (no low-latency or preemption patches). In RT-mode jackd doesn't tolerate client failures. But if you don't have a low-latency kernel, you will get 50-100ms stalls during normal use. In other words, running jackd with period size less than 50-100ms (-p 2048 = 46ms at 44100Hz) _WILL_NOT_ work reliably. Solution1 = Patch the kernel. Solution2 = Increase period size (-p 1024 or higher). Solution3 = Increase period count (-n 4 or higher) and run without root privileges. 2. Running complex setups without root privileges (and -R). If you have X clients participating in one JACK setup, those X clients have to get the CPU during each engine cycle. Without root privileges (and SCHED_FIFO scheduling policy), there's no magic that makes sure that all clients get enough CPU time. So the more the processes you have, the larger the chance of a client failure. Solution1 = Increase the period size or period count. These _HAVE_ to be notably higher than with single-thread audio apps. Solution2 = Run as root (see previous problem scenario). Solution3 = Patch the kernel and run as root. k_jack performs okey. You dont have to run things with realtime priority. What does cat /proc/asound/card0/pcm0[cp]/sub0/[hs]w_params output while you are running k_jack? This information should help us understand the benefits of k_jack over current jackd. -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] python sound
On Wed, 22 Jan 2003, david casal wrote: Just wondering whether people can point me towards any python+sound activity out there, other than OMDE/PMASK and Thomas Grill's 'pyext' for PD. Anybody playing with real-time concerns? Pyecasound is one such package. Basicly it's an implementation of the Ecasound Control Interface, which allows you to control the real-time signal processing core of ecasound from python. It does _not_ allow you to modify, generate or consume the actual audio data in python. But you can control effect parameters in real-time, start/stop/seek, and issue other such control operations easily from python. More info at: http://www.eca.cx/ http://www.eca.cx/eca_links.htm - check for instance 'heteca' and 'ecaenveloptor', both written in python using pyecasound http://www.wakkanet.fi/~kaiv/ecasound/Documentation/ -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] ecamegapedal 0.4.0 released
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!
Re: [linux-audio-dev] Re: [vst-plugins] Plugin server
On Sun, 8 Dec 2002, Paul Davis wrote: you also haven't addressed kernel scheduling issues; the context switch doesn't happen till the kernel has decided what task is going to run next. if it picks the wrong one, for whatever reason, then you/we lose. right now, it picks the wrong one too often, even with SCHED_FIFO+mlockall. Btw; have you tried the O(1) scheduler? It has a number of interesting charasteristics from an audio app developer's pov [1]: - RT-scheduling is, too, O(1) (less cache use, quicker context switches...) - RT-scheduling is separated from non-RT scheduling - perfect SMP-scalability (no shared run-queue lock) And of course, as O(1) is under active development (in 2.5, in 2.4-ac and patches for latest 2.4 kernels), a possible bug in SCHED_FIFO semantics might receive kernel-hacker interest. ;) Do you have any simple test cases to reproduce the problem... only with ardour+jackd or perhaps also simpler setups like jackd+capture_client or some such? [1] http://www.uwsg.iu.edu/hypermail/linux/kernel/0201.0/0810.html -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] LADSPA output controller?
On Tue, 12 Nov 2002, Mario Lang wrote: So I'd need to connect a audio/controller output to a controller input of another LADSPA plugin. Do ladspa hosts like ecasound support this? Or am I taking a completely wrong route here and it should be done differently? A bit complicated, but possible: ecasound -b:128 -f:16,2,44100 \ -a:generator -i null -o null -el:analogueOsc,1,5,0.5,0.5 -eS:1 \ -a:target -i foo.wav -o alsa -el:pitchScale,1.0 -ksv:1,0.5,2,1,1 -c - analogueOsc generates audio data (5Hz sine wave, warmth=0.5, instability=0.5) to the otherwise silent 'generator' chain - -eS:1 stores the passing audio data to an audio stamp (ie. allows other parts of the network to access the audio data it sees) - chain 'target' reads from foo.wav, applies the pitchScale LADSPA plugin and writes the processed data to the default ALSA pcm output - -ksv converts the audio data from stamp 1 (-eS:1, ie. the analogueOsc output) into control data, scales the value to range [0.5,2.0], and uses the resulting value to control the pitchScale coefficient - the audio-control conversion is done by calculating RMS-volume for each 128 (-b:128) sample block which is then used to update the LADSPA plugin parameter value Of course, it's possible to use any audio input source (files, real-time inputs, LADSPA plugins, effect presets, etc) in the 'generator' chain. PS Ecasound has had this functionality since 1.9dev1 (Feb/2001), so for once (!) you don't have to get the latest CVS version to try this out. ;) -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] Re: [Jackit-devel] questions about diskthread/process() synchronization
Btw; I'll cc'd this to lad, as this is a topic that has been discussed there _many_ times. More specifically the SMP-sparc case has been mentioned quite a few times but without specific details. For lad-only readers, see the jackit-devel archives for the whole thread. On Wed, 13 Nov 2002, Tim Goetze wrote: it should be noted that this relies on accesses to the r/w buffer indices to be atomic. that's no problem on common workstation hardware, though. [...] /usr/src/linux/include/asm-target/atomic.h gives more info. Actually I've spent some time studying this issue and my conclusion is that the level of atomicity provided by linux asm-arch/atomic.h is not needed to implement single-reader-single-writer lock-free buffers. More specifically, asm/atomic.h provides guaranteed ordering of reads and writes. This is not really needed in handling the l-f buffer indices. In the worst case reported write-space is larger, or read-space smaller, than the actual situation. The only problematic scenarios are that a) read returns an invalid value, and b) write stores an invalid value. These could possibly happen if reads/writes were not atomic. But so far I haven't found any platforms (with publically available specs) which don't guarantee this level of atomicity (even in the case of complex processor cache arrangements). The two architectures for which asm-xxx/atomic.h contains special code even for plain reads and writes are SMP-sparc and s390. I haven't studied s390, but at least in the case of sparcs (ref: sparc v8 arch manual), reads and writes are atomic even in a SMP configuration, although ordering is not guaranteed. More specifically, if TSO (Total Store Ordering) memory mode is selected, loads do not necessarily appear in order. If using PSO (Partial SO), stores as seen by the issuing processor can be executed out-of-order. But these restrictions aren't really a problem for l-f buffers. If I've interpreted the situation incorrectly, or someone has better information, I'd be very interested to know! Even better, example code that demonstrates atomicity problems... I have currenly access to both IA32 and Sparc-v8 multi-processor machines. -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] Re: [Jackit-devel] questions about diskthread/process() synchronization
On Wed, 13 Nov 2002, Paul Davis wrote: my conclusion is that the level of atomicity provided by linux asm-arch/atomic.h is not needed to implement single-reader-single-writer lock-free buffers. this is true unless the pointer/index isn't atomic. since on SMP sparc systems, the arrangement of the cache lines means that you can't guarantee better than 24 bit atomic values, you do have to be careful about the potential size and memory position of the pointer/index variables. I've browsed through the sparc arch manuals and couldn't find anything that would limit atomic access to 24 bits nor any directly related cache line limitations. The Linux asm-sparc/atomic.h provides only 24bits as it uses the lower 8bits to implement a low-overhead spinlock. Spinlock is required to guarantee memory ordering (also with mixed usage of various atomic_* ops). If you just read/write 32bit ints, this is atomic even on SMP-sparcs. in handling the l-f buffer indices. In the worst case reported write-space is larger, or read-space smaller, than the actual situation. actually, the worst case for both metrics is that they are *smaller* than they should be. this happens on two occasions: Ugh, true, my mistake. its not so much atomicity as ordered that is needed here. because read/write will only use that part of the buffer indicated as available by the r/w pointers, all we have to know is that the writes to the buffer complete before the write pointer is updated. it would be good to use a so-called memory barrier somewhere there to make sure this is true. Ok, this is a real problem, but I don't think using asm-arch/atomic.h (which can guarantee ordered access to the buffer indices) helps to solve this issue, so you might just as well use regular ints as the atomic indices. And this really is a corner case as the buffer would have to be close to empty (something has already gone wrong!) to read old data from the buffer, even on a SMP sparc or s390. -- http://www.eca.cx Audio software for Linux!
RE: [linux-audio-dev] image problem
On Wed, 13 Nov 2002, Mark Knecht wrote: Let me ask another question in this area. Could someone explain the implications of GPL/LGPL WRT proprietary applications that interface to Alsa Jack, along with their incumbent support programs like kaconnect and qjackconnect? Both ALSA (alsa-lib, ie. libasound) and JACK (libjack) are licensed under LGPL and thus allow their use even from proprietary applications. Btw; ecasound's control interface (EC) is licensed under LGPL (recently changed), so it's possible to write closed-source apps that use ecasound as the audio engine. Other parts of ecasound are still under GPL, so if you want to improve or extend the audio engine, you'll have to release your changes under GPL. If Jack and Alsa were pushed in technical business development circles as a way for Company A to enter the Linux market and be able to work together with other existing applications, do the GPL/LGPL licenses of Alsa Jack create issues for Company A's proprietary code base? No. Glibc is also LGPL licensed, so if there were any problems with using LGPL libraries from closed-sourced apps, this would affect _all_ applications that run on Linux. I see the open nature of Linux as best exemplified in the lower level portions of the audio stack, and less so at the application level for the reasons we've been discussing. As a person who is in business, but not in this area, I have suspicions that these are the issues that are keeping retail applications out of the Linux markets. At least I wouldn't mind if some commercial entity used ecasound in their product. I would get improvements and fixes to the engine code and they could keep the interface to themselves. I'm fully content using the user-interfaces that are already available for ecasound, so this would be a win-win situation for me. Of course, a completely different thing is whether anyone wants to use ecasound...:) -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] GUIless friendly applications
On Tue, 5 Nov 2002, Mike Rawes wrote: plugins in the network) would be a nice feature. Another idea which I've seen discussed is the creation of 'meta' plugins - subnetworks 'wrapped' into a single plugin. Combined with cut,copy,paste, you could create a nice patch, and then decide 'I want six of them, each slightly detuned' or something, and simply replicate the meta plugin five times. Btw; ecasound provides these. Ecasound's meta plugins, or in ecasound's terms, effect presets, can combine native and LADSPA plugins, and locate them in parallel and serial chains, and it's also possible to parametrize the meta plugins (ie. one meta-plugin parameter can control multiple real-plugin parameters). See more info at: http://www.wakkanet.fi/~kaiv/ecasound/Documentation/users_guide/html_uguide/users_guide.html#SECTION0083 Or alternatively: eca.cx/ecasound - documentation - user's guide Realtime control of parameters such as frequency cutoff, reverb room size and such could be via MIDI controller values. I think these allow quite a bit of resolution - 14bit? Must check. This is also possible with ecasound. ecasound -f:32,1,44100 -i jack -o jack \ -ef3:800,1.5,0.9 -km:1,400,4200,74,0 -km:2,0.1,1.5,71,0 This creates a JACK client that has one input and one output port. During process() ecasound will take the data sent to its input port, process it with a lowpass filters, and write it to the output port. The lowpass filter is controlled in real-time with MIDI-CC 74 (cutoff) and 71 (resonance). The whole -km syntax is: -km:parameter,range_low,range_high,controller_number,midi-channel Support for 14bit MIDI controllers is not yet available, but has been on my todo-list for a while (see edi-4 at eca.cx/ecasound - EDIs). Although ecasound is not an optimal platform for creating audio generating apps, it can manage quite a few simple cases. For instance: ecasound -f:32,1,44100 -i null -o jack \ -el:analogueOsc,1,440,1,1 -km:2,40,16000,74,0 ... creates a JACK client that outputs sine wave (using the analogueOsc LASDPA plugin) to its output port. The osc frequency is controlled using MIDI-CC 74. If you don't have MIDI-equipment at your use, you can test the above by replacing -km with -kos:2,40,16000,0.5,0 ... Also, if you are not running JACK, replace 'jack' with either '/dev/dsp' or 'alsa,default'. For more complicated MIDI-control, you could write an ECI app in perl/php/python/lisp (or even in C/C++ :)) that reads from /dev/midi00, interprets the MIDI messages in some way, and then sets the LADSPA plugin parameters (in real-time) by issuing ECI commands. The ECI API might look a bit too simple, but it has proven to be quite versatile. For instance, last week I implemented a VU-meter (ecasignalview) using nothing but ECI. And even better, soon after, Mario Lang implemented a similar real-time VU-meter to ecasound's emacs-mode using the (e)lisp ECI API...! Do that in vi! ;) But, but, implementing a full MIDI-controllable synth this way is probably not a good idea. :) Ecasound has a few critical limitations that can cause problems: - impossible to freely route data between plugin audio ports - changing object connections cannot be done in real-time (ie. you'll hear a clear break) - no direct access to actual audio data, just the object parameters -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] console JACK metering using ecasignalview
Hi, yesterday I released ecasound-2.2.0-pre4 (approaching next stable release, yay!), which has a few JACK-specific improvements: - new command-line syntax for specifying inputs and outputs, see: http://www.wakkanet.fi/~kaiv/ecasound/Documentation/users_guide/html_uguide/users_guide.html#SECTION0086 - uses the new alsa_pcm:capture_x + playback_X syntax (requires JACK 0.40 or newer == CVS!) You can find the package at: http://ecasound.seul.org/download/ecasound-2.2.0-pre4.tar.gz And now to the main point: 2.2.0-pre4 comes with an updated version of ecasignalview. Combined with the new JACK syntax, ecasignalview now suits quite well for monitoring JACK-clients. The basic syntax is: ecasignalview -b:XXX -f:32,YYY,ZZZ jack_auto,foo_client null ... where: XXX = buffersize (jackd's -p:XXX) YYY = number of channels you want to monitor ZZZ = sample rate (jackd's -r:ZZZ) foo_client = any JACK client which uses out_X style port names The meters are drawn with ncurses, while values are queried through the ECI API (ie. ecasignalview is only linked against libc and libstdc++, not for instance against libjack). The output looks like: http://eca.cx/screenshots/ecasound-2.2.0-pre4_ecasignalview.png ... there are a few known bugs, but in general it works quite well. While not really a huge challenge for Steve's meterbridge ;), should be of interest to some of you. -- http://www.eca.cx Audio software for Linux!
Re: [Alsa-user] Re: [linux-audio-dev] Re: image problem [was Re:[Alsa-devel] help for a levelmeter]
Takashi, thanks for these corrections! It'd be great to see yet more reports about successes, failures, suspected problems, etc, etc concerning different soundcards and chipsets on alsa-user (and other lists)! It's much easier to make purchasing decisions if you know that at least someone has had success with the desktop/laptop/soundcard model (and not just the chipset!) you're about to choose. On Wed, 23 Oct 2002, Takashi Iwai wrote: - snd-intel8x0 (nice chipset, is suitable for low-latency use) the real-time response is dependent on the system. some notebooks have problems in this regard. How is it different...? And do you happen to remember what notebooks (brand, possibly any IBM models)? - 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) no, instead, the interrupts are generated in the fixed time-length, not at the period boundary or the end of buffer. thus, this chip doesn't suit for low-latency purpose at all. Ugh, not good. Thanks for the clarification! -- http://www.eca.cx Audio software for Linux!
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: 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: [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, developmenttesting help is welcome! -- http://www.eca.cx Audio software for Linux!
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!
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] 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!
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
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] 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!
[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] 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/da/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!
[linux-audio-dev] from the who needs protools when you have emacs department
On Thu, 10 Oct 2002, Kai Vehmanen wrote: PS Oh yes, there's no need to leave your emacs session if you just want to do some multitrack recording (and w/ full JACK and LADSPA support)! :) An old screenshot of ecasound-mode can An update. Here's a newer screenshot where I'm playing a file using ecasound+JACK, adding reverb using freeverb, and editing the freeverb parameters in real-time from an emacs buffer (w/ a nice text interface [1]): http://www.eca.cx/screenshots/ecasound-2.2.0-pre3-emacsmode-0.7.5.png [1] http://www.emacswiki.org/cgi-bin/wiki.pl?EcasoundMode -- http://www.eca.cx Audio software for Linux!
RE: [linux-audio-dev] Quick and efficient sound daemon idea -- whynot do it this way?
On Wed, 16 Oct 2002, Ivica Bukvic wrote:
Jack works only with Jack apps and from what I heard, does not tolerate
many simultaneous apps running concurrently, furthermore it permanently
drops a stream if it is late for whatever reason, which basically means
it is useless for the real-time performance (last thing I need in the
middle of the concert for JACK to drop one of my streams --
I guess it's a time for little marketing speech. :)
JACK should be just fine for your use. Basicly JACK can also be used for
the not-so-hard-core-low-latency tasks. JACK just makes the real-time
deadlines much more explicit - both to users and developers.
One way of dealing with real-time deadlines is to ignore their existance.
This the approach used in many existing audio apps (and I'm not just
talking about Linux). If on the other hand the deadlines are explicitly
taken into consideration, then there remains to be two alternative design
approaches: 1) missing a deadline is an error, 2) missing
deadlines is possible, so software implements a recovery mechanism.
Now as it is, many of the active JACK developers and users are mostly
interested in (1). For an application like Ardour this really is the only
possible approach. It just isn't tolerable for the recording to skip once
in a while. It's better to let the user know that the system simply
doesn't work reliably enough (ie. client can be disconnected from
the system during processing).
But it is also possible to use JACK for (2). Currently, if you run jackd
without the -R option, it will run in so-called soft-mode. In this mode
clients are not kicked out, unless they are _really_ late (over 5 secs).
There's room for improvement (for instance, make it possibly to have -R
but with soft-mode timeouts), but this doesn't change the fact that
that JACK is also viable for (2).
I'm currently running jackd with 2x8192bytes of buffering ('-d hw:0 -r
44100 -p 2048 -n 2' w/ 24bit samples) and it works quite well as a
general-purpose audio server. With these settings the latency is ~46ms,
which is not bad (I'm not running it as root). I think this is just the
kind of use most people use esd for. But what esd cannot do is to route
the mp3 playback through an app like Freqtweak. ;) With JACK you can do
that.
Another source of trouble is utilization of buffering. Generally you
should use much higher period/fragment sizes with JACK than what you are
used to with other audio apps. While in many apps the total buffersize (x
blocks of y samples each) is used to control latency/reliability, in JACK
the effective block count really is always 2. So this means that you
should increase the period size if you want to use JACK as a soft-realtime
audio server.
assuming I am only interested in using JACK apps, which is a huge
assumption in itself), and this mix plugin is yet to be seen at work.
Yes, this really is a huge problem for all audio application frameworks
that are not OpenSoundSystem. Technically it's not possible to get old OSS
applications to work in a multi-app network like JACK without noticable
increase in latency. On the other hand, it _is_ possible to write an
LD_PRELOAD-based OSS-emulation for JACK. The basic idea:
** OSS-emulated calls **
- open() connects to the JACK server
- create two buffers, each with room for
one buffersize() worth of what_ever_OSS_format of data
(only needed for
- temp buffers for f32le non-interleaved data
- read()
- read data from the OSS-buffer at appl_ptr
- write()
- write data to the JACK-buffer at appl_ptr
- ... and so on
** JACK-callback **
- process()
- inputs: read from JACK client buffer, write and convert to the
OSS-buffer at jack_ptr
- outputs: read from OSS-buffer at jack_ptr, convert and write to
the JACK client buffer
... that's it. If the emulated app is late, the JACK-client should
behave just like a normal soundcard - overwrite the (or read old)
data or stop.
The only big problem is who will implement this. Similarly lots of
interesting stuff could be done using alsa-lib's PCM-plugins, but again,
who will do the work. But still, these are all much easier/smaller tasks
than writing yet another audio server from scratch.
--
http://www.eca.cx
Audio software for Linux!
Re: [linux-audio-dev] freqtweak release 0.4.3
On Wed, 16 Oct 2002, Richard Bown wrote: http://freqtweak.sourceforge.net/ try to connect anything to freqtweak or start it with the defaults (alsa_in to alsa_out). The input monitor appears to work but the output one is dead and whine whine whine (varies with the fft size). I presume some horrible feedback type thing but any clues for me? Same happens on my machine. Connection to JACK seems to work ok, and CPU-usage stays within reasonable limits, but the resulting audio sounds just like what you've described above. Hmm, I have the latest JACK-CVS plus fttw-2.1.3 installed from source. Any ideas what could be causing this? -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] freqtweak release 0.4.3
On Wed, 16 Oct 2002, Jesse Chappell wrote: Ooh, this also sounds like what might happen if it compiled in the double version FFTW, but I would have thought that would fail on compile. This was it. Recompiling fftw with './configure --enable-float' fixed the problem. Works perfectly now (I'm ready to join the addicted-to-freqtweak group ;D)! PS It might be good to detect this in freqtweak's configure-script... -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] writing JACK and LADSPA apps with the ECI Cimpl
On Sun, 6 Oct 2002, Steve Harris wrote: I've just reinvented remote-procedure-calls, strings, linked lists and bunch of other stuff while writing the new standalone C implementation of Ecasound Control Interface (ECI) (ugh, C, ugh ;)). But I think the work Kai, that is a thing of beauty. Thanks, although I think this is better ;) ...: http://www.wakkanet.fi/~kaiv/ecasound/ecasound-list/2002/10/0053.html ... Mario Lang implemented the equivalent functionality in elisp to ecasound's emacs-mode, and instead of the hundreds of lines of code I needed in the C impl, Mario only needed one elisp function to parse the wire-protocol. Result... 'elisp 1 - C 0'. Pretty neat, I must say. :) PS Oh yes, there's no need to leave your emacs session if you just want to do some multitrack recording (and w/ full JACK and LADSPA support)! :) An old screenshot of ecasound-mode can be found at: http://www.eca.cx/screenshots/ecasound-2.1dev6_emacsmode.jpg -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] writing JACK and LADSPA apps with the ECI C impl
I've just reinvented remote-procedure-calls, strings, linked lists and
bunch of other stuff while writing the new standalone C implementation of
Ecasound Control Interface (ECI) (ugh, C, ugh ;)). But I think the work
was worth it. Next I'll demonstrate how to develop a simple app taking
advantage of both JACK and LADSPA (with real-time parameter control) with
a minimum amount of developer effort. If you are now wondering why I'm
writing about this, jump to (6). ;)
--
1. Requirements (for this specific example)
- jack-CVS installed and running
- Steve's plate reverb LADSPA plugin installed
- ecasound-CVS installed
--
2. The Application
--cut--
#include ecasoundc.h
int main(int argc, char *argv[])
{
eci_init();
/* create the chainsetup and one chain */
eci_command(cs-add jackdemo_chainsetup);
eci_command(c-add chain1);
/* add the audio inputs and outputs */
eci_command(ai-add foo.wav);
eci_command(ao-add jack_alsa,out);
/* add an LADSPA plate reverb */
eci_command(cop-add -el:plate,50,0.5,0.5);
/* select the 3rd param (wet/dry) for real-time control */
eci_command(copp-select 3);
/* connect the setup and start */
eci_command(cs-connect);
eci_command(start);
while(1) {
double curpos;
sleep(1);
/* fetch current play position */
eci_command(get-position);
curpos = eci_last_float();
if (curpos 10.0) {
/* at pos=10sec, quit playing */
break;
}
else if (curpos 5.0) {
/* at pos=5sec, set reverb length to 80% */
eci_command_float_arg(copp-set, 0.8);
}
}
eci_command(stop);
eci_command(cs-disconnect);
eci_cleanup();
return(0);
}
--cut--
---
3. Compiling
gcc -o jackdemo jackdemo.c -lecasoundc
---
4. Running
./jackdemo
---
5. Dependencies
--cut--
###| ~|$ ldd ./jackdemo
libc.so.6 = /lib/i686/libc.so.6 (0x4200)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000)
###| ~|$ du -h jackdemo
52k jackdemo
###| ~|$ file jackdemo
jackdemo: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses
shared libs), not stripped
--cut--
---
6. The Catch
The created binary, jackdemo, does not rely on any external libraries. No
dependency to ecasound libraries, JACK libraries, C++ runtime, threading
support... just the basic C runtime! In other words jackdemo does not
create depency-hells. ;)
...
PS Although the example looks simple, a lot happens underneath.
'foo.wav' is read using a double-buffering disk i/o subsystem.
If jackdemo is run with root privileges, all memory is locked
and realtime scheduling is used. In otherwords, jackdemo
takes advantage of all known tricks to achieve reliable
audio performance in Linux.
--
http://www.eca.cx
Audio software for Linux!
Re: [linux-audio-dev] meterbridge 0.0.4
On Fri, 4 Oct 2002, Steve Harris wrote:
I'm not sure that you'd want to do this with the meterbridge but it's
something that needs to be handled if we want to be able to save and restart
a jack session.
I dont like using pids because it looks messy, maybe jack could provice an
eqivalent to tmpname (or whatever its called), so you could call
jack_unique_name(bridge) and get back bridge-1 the first time and
bridge-2 the second for example.
This might be a good addition. In any case using pids is not optimal.
This is basicly the same problem as with port names. Either we maintain
two sets of names (one for programs, one for the user-interfaces) or
make a compromise and have something that is usable for both. Requiring
users to map the application instances to pids does not fill this
requirement.
Having a basename with a standard way of labelling/iterating instances
is the way to go IMHO. Ecasound does the following now:
--cut--
for(n = 0; n AUDIO_IO_JACK_MANAGER::instance_limit; n++) {
client_repp = jack_client_new (client_name.c_str());
if (client_repp != 0) break;
client_name = jackname_rep + _ + kvu_numtostr(n + 2);
}
--cut--
Ie. it tries ecasound, ecasound_2, and so on. The exact syntax doesn't
really matter, just as long as all client apps use the same one.
--
http://www.eca.cx
Audio software for Linux!
[linux-audio-dev] ADM: problem solved (was: Re: adm: problems with mailing list webarchive)
Hi, searching the laa/lad/lau web archives is back online! Let me know if you notice any problems. links: http://www.eca.cx/laa http://www.eca.cx/lad http://www.eca.cx/lau On Sat, 24 Aug 2002, Kai Vehmanen wrote: The htdig-installation that is responsible for the search functionality of LAD/LAU/LAA web archive, is temporarily disabled. -- http://www.eca.cx Audio software for Linux! ___ linux-audio-dev mailing list [EMAIL PROTECTED] http://music.columbia.edu/mailman/listinfo/linux-audio-dev
Re: [linux-audio-dev] swh plugins 0.2.8
On Fri, 19 Jul 2002, Steve Harris wrote: http://plugin.org.uk/releases/0.2.8/ And of course, I now include LADSPA 1.1 default hints and a (fixed) ladspa.h. Due to the fierce feature race between our projects, both gstreamer and ecasound (plus ecamegapedal) now have initial support for this default hints API in the CVS-trees. Check the whole story at... http://eca.cx/lau/2002/07/0480.html http://eca.cx/lau/2002/07/0484.html http://eca.cx/lau/2002/07/0495.html ... :) -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] App intercomunication issues, some views.
On Wed, 24 Jul 2002, Andy Wingo wrote: [JACK transport control] I've been meaning for some time to make a universal transport control, a separate app whose sole purpose would be transport control. This would be rad (TM) for a number of reasons: 1) Get your whole rig to start at once, even if you're not using ecasound or ardour Yup, I agree, a generic (and simple) transport master client would be a very valuable addition. Even though works out-of-the-box is a very high priority item in ecasound development, I must admit that achieving this goal is anything but easy with applications of this size. If nothing else, broken soundcard hardware, kernel drivers (and sometime the kernel itself) and libraries make it practically impossible to prepare for all situations. And the last thing people developing new client apps need is to worry about bugs and misc problems of other large client apps. In other words there should be enough jack_simple_client style apps to cover all JACK functionality. Getting these apps to work should require no more effort than that required by jackd. This is critical for getting more developers writing JACK clients. Requiring installation and use of ardour/ecasound/someotherbigapp is not good. 3) funny tricks with beats -- speed up, slow down the tempo. Loop the last 4 beats. All the GDAM tricks, but on a system-wide level.* [...] * You'll run into some buffering issues here when streaming from disk. Oh well. Actually the JACK transport API is quite flexible in this way. Ecasound doesn't yet (if ever, ecasound prefers per-audio-object looping to session-level looping) support the loop transport mode, but it does support live seeks (ie. random-access style changes in transport position during successive callbacks). If the disk-i/o subsystem can't keep up with the changes, the rt-part (callbacks) will ignore it until it has caught up. Of course for sample-accurate looping, the looping transport mode is still the only real solution. It's also true that transport-change patterns involving regulars jumps (like skipping x samples during each callback) will cause trouble to clients with slow non-rt i/o subsystems. But anyways, the most important feature IMHO is the basic transport control (ie. start, stop and non- or near-rt fw, rw and setpos). Most importantly this solves the old LAAGA use-case with drum-machine+soft-synth+multitracker (http://eca.cx/laaga). -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] App intercomunication issues, some views.
On Wed, 24 Jul 2002, Richard Bown wrote: What apps have an example implementation of the JACK transport controls? Neither ecasound or ardour appear to but I'm probably a bit out of date with them. And again, why should I care about the JACK transport? http://cvs.seul.org/cgi-bin/cvsweb-1.80.cgi/sound/ecasound/libecasound/plugins/audioio_jack_manager.cpp?rev=1.25content-type=text/x-cvsweb-markuponly_with_tag=MAIN It's just not perfect yet, but it's quite well commented and all basic use-cases are covered. Start from eca_jack_process(), ecasound's JACK process() callback implementation. -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] App intercomunication issues, some views.
On Wed, 24 Jul 2002, Richard Bown wrote: because the transport time is the only important global time it indicates what you should be playing/doing right now. But of course at the moment we've also got the ALSA sequencer clock running to schedule our MIDI alongside our JACK callbacks - so external control of our audio streams (RG as a client) wouldn't really make much sense unless we could do the same to our MIDI. Not necessarily. If nothing else, just by implementing support for 'start' and 'stop' JACK transport state changes, you allow softsynths/etc to be run in sync with Rosegarden. Of course without support for transport position the user has to set the position in all apps manually before issuing start (in the JACK timebase master client), but to me this is just a minor annoyance if I can use multiple independent, sample-synced apps to create my music! And even more so as it very unlikely that you have 2 apps that care about sample position in one setup. Another approach is to propage the state changes to the ALSA sequencer (just like you do when a user presses the 'Go to begin' (or similar) button in Rosegarden's UI. -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] priority inversion inheritance
On Thu, 11 Jul 2002, Martijn Sipkema wrote: I agree with you that the only real solution is to rewrite the application. Still, as others said that was not going to happen, the mentioned solution will work as long as the hardware period size isn\'t too different from the number of samples the application processes per read/write. I mentioned this before because I did not think these (read/write) applications are a good reason to have the process() callback use a constant nframes (during jackd lifetime). There're two separate problems here. Constant nframes might be required even if the application supports engine iteration from outside sources (ie. all audio processing happens inside the process() callback). Ecasound is one example of this. Of course with no locking involved, there's no need for priority inheritance. A different problem is apps that have their own loop based on blocking read/write ops or driven by select/poll. In this case the easiest way to add JACK support is to put a FIFO between the engine and the process() callbacks. Although priority inheritance could be used here, it's doesn't buy as much. First of all, due to the extra context switch involved, this approach just is not efficient. Secondly, the application loop must still be deterministic (to avoid missing deadlines caused by blocking on paging or disk i/o) and there's thus no reason to run it without SCHED_FIFO. In other words priority inheritance is not needed. Again, I agree with you. That\'s also why I am against a constant nframes, because there is hardware that really doesn\'t want nframes constant. What hardware? You've mentioned this quite a few times on jackit-devel, but so far without examples. D/A or D/A hardware always runs at a constant speed (at least I haven't heard about variable rate sampling). Either the software continuously polls the audio hw buffers (not really an option) or is waken up periodically using interrupts. And nframes should be equal to the period size. -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] priority inversion inheritance
On Thu, 11 Jul 2002, Martijn Sipkema wrote: There\'re two separate problems here. Constant nframes might be required even if the application supports engine iteration from outside sources (ie. all audio processing happens inside the process() callback). Ecasound is one example of this. But why is this needed? The only valid argument I heard for this is optimization of frequency domain algorithm latency. I suggested a One simple reason, whether a valid design or not, is that there's a lot of code that handles audio in constant size blocks. For instance if you have a mixer element in the signal graph, it is just easier if all the inputs deliver the same amount of data at every iteration. In ecasound the trickiest part is that the i/o subsystem uses buffer objecs to store audio. Each buffer object contains nframes of audio. These audio slots are allocated before real-time processing is started and cannot be resized on-the-fly. But the important point is that for low-latency processing, the design described above has no real negative sides and I see no need to change it. With the current JACK implementation this design delivers optimal results both in terms of efficiency and latency... _if_ I ignore the non-const-nframes issue. If I want to add correct support for the current API, I either have to a) change the engine design (basicly from using ringbuffers of audio blocks into ringbuffers of audio samples), which involves making changes to majority of the interfaces in ecasound's codebase (multiple MBs of code!), or b), make a compromise on efficicientlatency and add a intermediary buffer between the JACK process() and ecasound engine. Now, as I've said before, if this is just me, then that is not reason enough (- keep the non-constant-nframes), but if there are lots of projects like ecasound, this will a serious issue. The worst case scenario is that majority of apps implement JACK support in a suboptimal way. And so far nobody has come up with any real good arguments for non-const-nframes. So to me non-const-nframes just means lots and lots of extra work without any benefits. capability interface for JACK as in EASI where it is possible to ask whether nframes is constant. The application must still handle the case where it is not. Yup, this is one solution. read/write ops or driven by select/poll. In this case the easiest way to add JACK support is to put a FIFO between the engine and the process() callbacks. Although priority inheritance could be used here, it\'s doesn\'t If the FIFO uses a mutex, it should use some priority inversion prevention mechanism, unless both threads run at the same priority. Otherwise there is a potential unbounded block on the mutex. The two threads must run with SCHED_FIFO as they both need to complete their cycle before the next soundcard interrupt. As Linux is not a real-time OS (and probably even if it was), priority inheritance would only solve half of the problem. Calls to disk i/o, network, user i/o and other subsystems block without deterministic worst-case bounds. No amount of priority (given by priority inheritance) will save your butt if the disk head is physically in the wrong place when you need it. On a dedicated system you can reserve a separate disk for the audio i/o or prevent other processes from using the disk, but in a GPOS like Linux, it is always possible that some other process can affect the kernel subsystems (for instance, access a file and cause the disk head to move at the worst possible time). The correct solution is to partition your audio code into real-time capable and non-realtime parts and make sure that the non-real-time part is never ever able to block the real-time part. In essence this very close to the RT-non-RT separation advocated by RTLinux, just done on a different level (between interrupt-driven SCHED_FIFO code and timer-interrupt/scheduler driver SCHED_OTHER code). There is hardware that just interrupts at a constant rate. With this hardware the frames that or ready isn\'t exactly constant. You might assume some value, but if it isn\'t exactly correct then you\'ll drift. Yes, the interrupt intervals and how much data actually is available when the software is woken up are two different things. But as the nframes count in any case has an upper bound, you are not free to directly use the avail_samples count anyways. And natural choice is to always use the period_count. I've posted one alternative approach to this to jackit-devel, but at least to me it really didn't seem like a viable approach. And nframes should be equal to the period size. This hardware doesn\'t have a period size in samples, but time based. And so I think it is wrong to have the driver export an interface that is not used by the hardware. Hmm, ok, now we're talking! :) Still, you can always calculate the theoretical period size in samples and use that as the nframes count. Like I already mentioned above, in any case you
Re: [linux-audio-dev] priority inversion inheritance
On Thu, 11 Jul 2002, Martijn Sipkema wrote: For instance if you have a mixer element in the signal graph, it is just easier if all the inputs deliver the same amount of data at every iteration. Hmm, why? I can see that it is a requirement that at every iteration there is the same data available at the input(s) as is requested on the output(s). I don\'t see what makes a mixer that much easier to implement if the amount of data to process is the same for every iteration. If all JACK inputs have x samples of audio and non-JACK input y samples, 'x != y' and you need to mix to a JACK output with x samples of space, you have a problem. Redesign is needed to make sure that this never happens. And my problem is that if JACK goes over to constant nframes there will be no need to change it. Even worse, new applications will also use assume nframes == constant. In any case it's good that this is now discussed. And you could still for all the cards that have nframes == const. Just add some buffering for nframes != const. I guess I could live with this, but we do need a flag to relay this info to the clients. The two threads must run with SCHED_FIFO as they both need to complete their cycle before the next soundcard interrupt. What I meant was a traditional application not running SCHED_FIFO but using a large FIFO to communicate with JACK\'s process() callback. And even if they both run SCHED_FIFO, they should then also run at the same priority. If using a large FIFO between a non-rt and rt threads, then the best solution is to make the FIFO nonblocking using atomic operations. This is an essential technique when making robust user-space audio apps. Real-life implementation cans be found from ardour (disk butler subsystem), ecasound (classes AUDIO_IO_BUFFERED_PROXY and AUDIO_IO_PROXY_SERVER) and EVO (formerly known as linuxsampler). other subsystems block without deterministic worst-case bounds. No amount of priority (given by priority inheritance) will save your butt if the disk head is physically in the wrong place when you need it. On a When the disk is not able to supply the samples in time, then there is a problem :) Using a fast disk and buffering will normally be sufficient. Aa, but that is a different issue. The question is about response time, not bandwidth. For instance ecasound's current disk i/o subsystem (run in a non-rt thread) sometimes stalls for multiple seconds (!) on my machine (two IDE-disks on the same bus), but still the audio processing keeps on going without xruns. The disk i/o system just has to buffer huge amounts of data to cover even the longest delays. Of course if you are really running out of disk i/o capacity, then fancy locking mechanisms won't save you. With full-blown priority inheritance and mutual exclusion between the threads, the rt-thread would then block for seconds in the above example and who knows about the worst-case upper bound! The correct solution is to partition your audio code into real-time capable and non-realtime parts and make sure that the non-real-time part is never ever able to block the real-time part. In essence this very close As I see it, it isn\'t a problem when the non-realtime part blocks the real-time part, as long as there is a worst case bounded block time for it. But as is is, theoretically speaking the worst-case time is 'infinity'. ;) the software is woken up are two different things. But as the nframes count in any case has an upper bound, you are not free to directly use the avail_samples count anyways. And natural choice is to always use the period_count. I\'ve posted one alternative approach to this to It is not that easy. Say period_count is constantly smaller than the available data on each interrupt, you will start to get behind and will have to eventually do an extra callback that then has more samples/time to process. I admit, this is a real problem. If the sampling_rate/interrupt_period is fractional, the only way for a JACK driver to keep up is to set JACK's buffersize to ceil(srate/iperiod) and then alternate between process(nframes) and process(nframes-1). Ok, I guess here's the first real case against const-nframe. On the hand at least with ALSA you'd be in trouble anyway as ALSA will wake your driver only when period_count samples are available. If you set period_count to floor(srate/iperiod) you will be woken up on every interrupt but you will slowly fall behind and eventually issue two process() calls per iteration (as you described). I period_count is set to ceil(srate/iperiod) you app will be waken only every other hw interrupt (at least every now and then). So like Paul said, do we need to support these soundcards...? For JACK-style operation both the above scenario are really, really bad. Not a problem as there\'s no 2^x limitation. Isn\'t there? for FFT? The trick is that with majority of available soundcards the user is able to set period_count
Re: [linux-audio-dev] priority inversion inheritance
Forgot one thing... :) On Thu, 11 Jul 2002, Martijn Sipkema wrote: The two threads must run with SCHED_FIFO as they both need to complete their cycle before the next soundcard interrupt. And even if they both run SCHED_FIFO, they should then also run at the same priority. Not needed. The SCHED_FIFO protects against from other tasks taking the CPU. If we have two SCHED_FIFO threads communicating with a mutex protected queue, different priorities are not a problem as for priority inversion to happen, one of them needs to block on the shared mutex. And if the thread is blocked, it then isn't in the run queue, and thus cannot get the CPU. -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] priority inversion inheritance
On Thu, 11 Jul 2002, Martijn Sipkema wrote: CPU. If we have two SCHED_FIFO threads communicating with a mutex protected queue, different priorities are not a problem as for priority inversion to happen, one of them needs to block on the shared mutex. And if the thread is blocked, it then isn\'t in the run queue, and thus cannot get the CPU. Not true as far as I know. FIFO only means that the thread won\'t be preempted after a certain time in case a thread of the same priority is ready to run. AFAIK all threads running either SCHED_FIFO or SCHED_RR will always be preempted by higher priority SCHED_* threads. Please correct me if I am wrong in this. Let's say we have threads A (SCHED_FIFO/50) and B (SCHED_FIFO/90). If both threads are runnable, B will always be selected and it will run until (quoting the man page) ... either it is blocked by an I/O request, it is preempted by a higher priority process, or it calls sched_yield. But if B blocks on a mutex currently owned by A, B will then become blocked and A will be selected to run. A can now run until it unlocks the mutex, B becomes unblocked and once the next scheduling decision occurs, B will again be chosen to run. But it's true that if we have more threads the situation gets complex pretty quickly. Let's say we have C (SCHED_FIFO/70) that holds a resource needed by B, and is currently blocked by a long i/o operation. Then all three threads will be stuck for an unbounded time. Do correct me if this seems wrong to you. Btw; great day today on lad - lots of very interesting discussion! ;) -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] priority inversion inheritance
On Thu, 11 Jul 2002, Martijn Sipkema wrote: Oh, you mean a mixer that doesn\'t only mix jack ports? Is that a common situation? Yes. I really can't say how common this is. It does seem that majority of the bigger audio apps seem to have a relatively complex internal signal flow. It is common to access all audio data producers (files, soundcard devices, ausio server, network connections, etc) and consumers (basicly the same list) through generic interfaces. And as all nodes are equal, a configuration setting is needed to determine how many samples the graph will process at a time. Hmm, you could of course pick a random input node at every iteration, check how many samples it has available and then let the engine process that many samples and restart the lottery, but this doesn't exactly sound very good. The bad side is that this design, although elegant (abstracting is one weak spot all cs people share ;)), is not optimal for low-latency operation. As the numerous (and volumenous) discussion here on lad have shown, it's actually needed to select one node to be the master node. For instance to implement proper JACK support, you just can't add implement a JACK source/sink object and connect it to your graph, but you need to have the JACK callback control the whole graph. But even if you do this, all assumptions and restriction defined by your internal interfaces remain. It's good to remember that most apps will continue to support the read/write audio APIs. I don't think the Csound project will drop support for all other audio APIs once it's ported to JACK. ;) For instance, in theory it's perfectly possible to construct an ecasound setup which simultaneously accesses ALSA, JACK, OSS and aRts nodes. This of course doesn't make any sense, but it is possible and I'd like to keep it this way. If using a large FIFO between a non-rt and rt threads, then the best solution is to make the FIFO nonblocking using atomic operations. This is Actually using mutexes (or better spinlocks as Victor noted) is a portable way to build an atomic operation. POSIX does not offer atomic_add stuff (yet) AFAIK. Unfortunately no, POSIX doesn't provide them. But with the current Linux kernel it's the only robust solution. Spinlocks as used in RTLinux are not of much use to us as we can't disable hw-interrupts at will in user-space. Mutual exclusion doesn't work either as we can't guarantee that the non-rt thread can release the mutex in time. With full-blown priority inheritance and mutual exclusion between the threads, the rt-thread would then block for seconds in the above example and who knows about the worst-case upper bound! I don\'t fully understand this. Let's say that the non-thread causes a page fault before it manages to release the mutex - no way to calculate the upper bound. But as is is, theoretically speaking the worst-case time is \'infinity\'. ;) That is a long time. :) I think even Linux can do better than that for worst case latency. But I'm not sure if this is something we want to limit. Letting Linux use non-deterministic algorithms has many benefits. Currently my view is that by clearly dividing audio software into rt and non-rt parts, we can get the best of both worlds. Let's say you have a JACK setup with clients (suprise, surprise) A, B and C. A and B are fully deterministic (DSP-processing only) while C is a file input client. If the disk i/o subsystem stalls for a long period of time (buffers are being flushed, etc), C will still finish its process() on time but it must deliver a silent buffer of audio. The rest of the setup will continue operation without timeouts. This is IMHO what we should aim at. -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] priority inversion inheritance
note! cross-posted to alsa-devel; some questions about the korg1212 driver... On Thu, 11 Jul 2002, Martijn Sipkema wrote: Ok, I guess here\'s the first real case against const-nframe. I thought i had already mentioned this several time :) You didn't say it loud enough.. ;) [soundcards for which 'sample_rate/interrupt_frequency' is fractional] at least with ALSA you\'d be in trouble anyway as ALSA will wake your driver only when period_count samples are available. If you set Perhaps this could be changed/added in ALSA? Well... I wish you luck in getting that change accepted. :) So like Paul said, do we need to support these soundcards...? For JACK-style operation both the above scenario are really, really bad. I don\'t have hardware that behaves like this :) But still, the yamahas are a common hardware. Is the korg card the 1212? I think it would still be nice to support these. But even with a non-const-nframe, these might still be hopeless cases. As for the korg 1212, it doesn't be a similar case as the yamaha. Its current driver in ALSA CVS seems to have hardcoded values for total buffer size and interrupt frequency. The used values are 8 blocks of 1024 sample frames (ie. period_size=1024, buffer_size=8192). This is a pretty sucky configuration. Unfortunately as part of the driver is implemented as DSP-code, changing the default might not be easy. Anyways, I don't have this card myself and have never tested it so the above analysis might be totally wrong. So correct me I'm wrong here... Basicly same approach is now in used in regards to the nframes issue. If you try to use ecasound with a JACK driver (well, if there was such an driver) with non-const-nframes, ecasound would just raise an error and exit. In a way this makes sense as until I rewrite ecasound (which will Is adding an intermediate buffer for drivers with non-const nframes much work? Some. I'd have to add code for the ringbuffer. Doesn't sound bad, but for me it's a few hundred lines of new code that I have to maintain but very likely nobody will ever use. The worst thing is that it would ruin my beautiful codebase. ;) I hate having multiple code paths that do essentially the same thing. The logic for handling JACK i/o is already pretty hairy (connecting the JACK inputs and outputs to the ecasound signal graph, masterslave timing modes, handling commands from the ecasound ui, commands from jackd, etc, etc). But again, the problem is really not what I have to do. All major ecasound subsystems have been rewritten multiple times. If it needs to be done again, I'll do it. But I'm not sure if it as likely that someone will rewrite csound, pd, insert-big-app-here just to support JACK. -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] 1000HZ ticks for x86 in the 2.5-tree
On Tue, 9 Jul 2002, Paul Sladen wrote: RTC is still more accurate, but on the other hand, you don't need root privileges to take advantage of the 1kHz ticks! Kernel space only; userspace is still at 100Hz on x86 Not a problem. Timing sensitive user-space apps benefit from this change because with 1kHz ticks, kernel will be making scheduling decisions much more often. AFAIK, keeping the user-space visible HZ-value as 100Hz is more of a convenience feature (ie. it's possible to change the kernel HZ value without the need to recompile glibc and some user-space apps like top). In other words user-space apps will get full benefit of the higher tick frequency even though the user-space exported HZ is set to 100. -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] 1000HZ ticks for x86 in the 2.5-tree
Here's one interesting commit in the 2.5-tree: --cut-- D 1.2 02/07/01 14:41:36-07:00 [EMAIL PROTECTED] 3 2 6/4/00020 P include/asm-i386/param.h C Make Linux/x86 tick at 1kHz instead of 100Hz. C C Export the deprecated clock_t frequency (100HZ) as USER_HZ. -- RTC is still more accurate, but on the other hand, you don't need root privileges to take advantage of the 1kHz ticks! -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] Poll about linux music audio app usability
On Tue, 11 Jun 2002, Billy Biggs wrote: The same holds for software as well: interface is almost everything. I would much rather have a sequencer with less features and a good UI than a fully-featured one that's annoying to use. When composing it's important to forget technology: think music. I just couldn't agree more! This was the thought behind my sequencer: ttrk (http://div8.net/ttrk). I did a UI that I'm pretty proud of for the target platform: basically it's an Alesis MMT8 meets a tracker in 80x50 textmode on an old PC, low enough latency to have really smooth drumrolls even at high bpm, and it syncs happily to external MIDI clock (essential for my setup). [...] Of course, since I have a market size of 1 (myself), and pretty much no interest from the open-source community, the project hasn't gone anywhere else. But I'm quite happy with it. :) Make that two!! :) ttrk has been one of my favorite audio apps for a while now. Thanks to the well-defined set of functionality and the way it is implemented, there just isn't much to complain about. ;) -- http://www.eca.cx Audio software for Linux!
[linux-audio-dev] Re: [linux-audio-user] Audio routing issues for linux..
On Mon, 10 Jun 2002, Juan Linietsky wrote: Here's a problem I commonly find in existing audio apps or in programming audio apps: Audio routing. Over a year ago (Sat May 05 2001) I wrote the following message: http://www.eca.cx/lad/2001/May/0071.html ... pretty close isn't it? The next step was http://eca.cx/laaga and then http://jackit.sf.net ... [problems of JACK and aRts] 1-The application has to be able to proovide inputs and outputs, which may be used or not. By default an app may connect directly to the output or just not conect at all, expecting YOU to define the audio routes. Most of the times, unless using a direct output or known audio modifier objects, an app will not want to connect somewhere from whithin it. You will do that from an abstracted interface. I don't really see a problem here. There are already JACK clients that allow you to modify the set of published ports during runtime. JACK apps can either let the user specify what ports to publish or it can query the running JACK system and create its ports based on this information. It's just like communicating with any other rt-subsystems (direct soundcard access, network, etc). 2-Jack is great, but if you want to run a certain synthethizer that doesnt use jack, together with one that does and you have a consumer soundcard that doesnt support multichannel output, you are dead. You've been dead so far, are dead and will be until a real solution to this problem arrives. JACK is one promising project (my personal opinion of course), but it's still an open game... who knows, maybe Steinberg will announce Rewire/Linux next week and we can pack our bags and go home. ;) 3-You may also want to put just any program that uses native OSS/ALSA through this. Imagine running xmms and wanting to put the sound thru a better equalizer than the one included. Instead of botherering in writing a SPECIALIZED equalizer plugin for xmms, you just redirect the output to an equalizer program that takes many inputs/outputs. http://eca.cx/screenshots/jack_alsaplayer_and_ecamegapedal_20020302.jpg Notice the date. In other words this is certainly possible with JACK and has been for a while! 4-I know jack likes to give root privileges to apps that need low latency I imagine that for normal apps this isnt an issue, so this should be considered. Yup, this is a problem, but it's a problem for all apps. And btw, JACK nowadays has a soft-mode which allows you to run it without root-privileges. You'll get the occasional xruns, but it'll run. The choice is yours. 5-You know you cant force application owners to convert their stuff to jack/arts/etc. You'd also rather not waste your time converting their applications to that, and the application owners would rather not having to support multiple apis. So, this saves us time to all. Maybe you are right, promoting JACK (or any other new framework) is a very difficult task indeed. On the other hand I really think JACK is something very exciting. I've already started to work on adding JACK support to a few of my favorite linux audio apps so I can use them in combination with ecasound. What can I say... it's like a whole new ball game! :) Like it or not, JACK as it is now can do things that simple weren't possible before. It's here, it's real and it works! :) Probably the easier and more natural approach to this is just integrating JACK to ALSA in some way. This is not as easy as it sounds. I've thought about this a few times when I was working on Ladplex (my own implementation of the LAAGA concept which I later abandoned in favor of JACK). You could implement most of jackd's functionality in the alsa-lib layer, but not without problems: - you'd need a separate server (and with it all the installation/user-support problems you mentioned as problems of JACK); otherwise you'd have no sane way of resolving the user-privilege problem - only with ALSA apps that behave like JACK-clients would efficient low-latency operation be possible (in other words the ALSA API, although certainly allows it, doesn't force app writers to make their apps efficient for lowlatency operation) - no transport control - you'd need a separate API for making connections and querying current network configuration - it's a big task; even with a very limited interface, JACK has required quite a lot of developer effort; ALSA PCM API is, well, it's just larger If we don't worry about low-latency too much, then the situation changes. It shouldn't be too big of a task to write an ALSA PCM plugin that interfaces with jackd using libjack. This would allow all ALSA and OSS apps to interact with JACK. I'm certain someone will write this bridge sooner or later. A simplified version would do: - lock the ALSA hw parameter space to the values given by jackd - treat JACK like a soundcard - pcm plugin layer is used to convert between formats used by JACK and ALSA (here JACK is the 'hw'
Re: [linux-audio-dev] LADSPA v1.1
On Tue, 21 May 2002, Richard Bown wrote: Tim Hockin wrote: No need to get on the defensive, really. I don't deny the usefulness or importance of LADSPA _AT_ALL_. It is, by and large, a very good system. Well why don't you stop being such a dick and just get on with it rather than posting under-informed, inflammatory comments? Ok guys, calm down a bit. As has been already stated, new ideas and proposals are always welcome here. But it's also good to remember that creating a widely used API is a bigger task than writing a technically good API. You need a bit of social engineering to get people on your side, or even just to get them to go through your proposal in detail. Downplaying the meaning of previously done work of this group (search for LADSPA at www.eca.cx/lad and you'll get thousands of matches) is not a good way to start your campaign.;) Anyways, new ideas (and members!) are always welcome. And I'd also like to maintain the relaxed atmosphere that this list has. There has never been a real flamewar here - let's keep it that way.:) -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] Ecasound frontend enquiry (and a bad link onSound MIDI page)
On Tue, 21 May 2002 [EMAIL PROTECTED] wrote: The link on linuxsound page http://www.bright.net/~dlphilp/linuxsound/; to EcaEnveloptor in Multitrack Recorders/Mixers is bad. You'll find all the frontends at: http://www.eca.cx/eca_links.html Or directly to ecaenveloptor's new site at: http://www3.wakkanet.fi/artoh/software/ecaenveloptor/ -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] LADSPA Specs ?
On Sat, 11 May 2002, Likai Liu wrote: Please consider my proposal for array extension of the LADSPA: As the one who encouraged to show the code, I feel obliged to give at least some feedback, but I'm afraid it's not very positive this time. The proposal itself looks fine, but I'm not sure how much interest this gets from developers of current LADSPA hosts. For instance ecasound's own plugin system (on top of which LADSPA plugins are mapped) doesn't support arrays, so it would be a major change to add support for this feature. On the other hand ecasound already has a mechanisms in place for representing envelopes (sequences of control data changes) and large parameter sets (ecasound plugins can change their parameter interface dynamically during runtime). So this is my view on the issue. Let's see what other people think... -- http://www.eca.cx Audio software for Linux!
