Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7516 discussions

[linux-audio-dev] Re: [linux-audio-user] Setting up linux computer

by ChristianH

Hi all, I'm in a similar situation. Within a couple of weeks I'll be buying a new PC which (besides still running Windows) should be, say, at least Linux friendly. Since in this case I'm not tied to given legacy hardware, I'd rather put in some components that are particularly suitable for Linux. >From what I heard, culprits can be - audio card - graphics card (hi resolution, 1280+, no 3D game capability needed) - and I assume MIDI interface as well (6 to 8 ports in+out) Are there cards with rather good Linux driver support? Are there cards better to avoid in Linux world, due to their poor driver status? Is there a Linux hardware FAQ site somewhere, with some recommendations? Until now I've been using an Emagic AW8 audio card, which perfectly fits my needs (don't really need 24/96k or oodles of audio ports). For Windows I was considering an Emagic AMT8 or Unitor8 interface, but I don't remember seeing any Linux drivers on their site (well, they may call'em OS X drivers... ;-) Another component may be somewhat outside this list's topics, I'm thinking of adding a video MPEG input/encoder card as well - maybe somebody can give me any pointers on that...? regards Chris On Tue, 24 Aug 2004 04:16:39 +0000 Thomas Pickett wrote: > >On Sunday 22 August 2004 04:37 pm, Frank Barknecht wrote: > > > Hallo, > > > > > > There are many more (pci cards), a very popular one being the RME card. > > > Can anyone suggest a good RME Card? I have looked at their website but was > wondering if anyone had personal preference. I preferably would like a > sound card with mutilple in/outs, mic in/outs, midi, spdif. > > Once again I appreciate all the feedback. As for distros, I'm leaning > towards debian, but I will do some more research. > > Thanks, > Thomas

21 years, 2 months

[linux-audio-dev] Re: [linux-audio-user] Linux Audio Human Interface Guidelines, 0.01 (was Re: mouse wheel behavior and RFC: human interface, guidelines)

by Lee Revell

On Wed, 2004-08-25 at 17:52, Paul Winkler wrote: > On Wed, Aug 25, 2004 at 06:02:44AM +0000, philicorda wrote: > > Paul Winkler wrote: > > > > "I could swear I remember seeing an old tube compressor that > > had a gain reduction meter with "more" to the right, so it > > moved in opposition to the corresponding VU meter. > > No idea what model it was, and this was about 6 years ago > > so I could be mistaken. > > > > I wonder how consistent this is in the world of hardware? > > maybe I'll pop a question on rec.audio.pro." > > btw, i had myself turned around again :-) > If the gain reduction meter is moving in opposition the VU meter, > then "more" gain reduction is to the left, not right. > > > I built a tube compressor like that, an Altec436c. > > The 'gain reduction' meter measures the bias current of the vari-mu > > valve, which is reduced when gain reduction is required. > > The meter goes from right to left. (Any other way would require more > > circuitry, so I think it may just be a lucky accident.) > > ah, that's an interesting point. > > > Talking of meters, don't some phase meters often go left *and* right > > from a centre point to show averaged phase difference between the channels? > > think so. >From the wide variety of responses describing all types of meters, it seems that the HIG should steer clear of this topic and leave it the developer's responsibility to make your meters intuitive. HIGs are not about restricting the range of functionality you can implement, they are just there to prevent needless usability regressions (aka usability bugs). An example of a usability regression would be when a user expects the leftmost menu to be 'File' and the 'Save' option to be found in it, but then encounter some app which puts the 'Save' option on the 'Edit' menu. Since neither way is intrinsically better, the former is the correct choice, because that is the way users expect it to work. Is there any known broken meter behavior that we should prohibit? So far I have not seen an example in this thread. Lee

21 years, 2 months

[linux-audio-dev] a new patent to worry about

by Paul Davis

http://news.harmony-central.com/Newp/2004/L3.html

21 years, 2 months

Re: [linux-audio-dev] Hello - FYI - intro

by Taybin Rutkin

Just out of curiousity, what optimizations did he suggest and which ones were a good idea? Taybin -----Original Message----- From: Erik de Castro Lopo <erikd-lad(a)mega-nerd.com> Sent: Aug 25, 2004 3:58 AM To: The Linux Audio Developers' Mailing List <linux-audio-dev(a)music.columbia.edu> Subject: Re: [linux-audio-dev] Hello - FYI - intro On Tue, 24 Aug 2004 19:56:27 -0400 Paul Winkler <pw_lists(a)slinkp.com> wrote: > On Tue, Aug 24, 2004 at 06:35:12PM -0400, John Check wrote: > > > > It's completely dwarfed by compile time. > > > > > > > Are you sure you wanted to say that ;) > > Yes. First rule of optimization: don't optimize something that's > statistically irrelevant. <vent=11/10> I wish that attitude was more prevalent in the ricer community. I've been getting emails from a Gentoo ricer suggesting a whole bunch of "optimisations" for libsndfile. A small number of these were valid, but the vast majority were not measurably faster as measured by the benchmark program shipped with libsndfile. </vent> Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ "The X-files is too optimistic. The truth is not out there." -- Anthony Ord

21 years, 2 months

[linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines

by Lee Revell

I just installed jack-rack and find the mouse wheel behavior a bit odd. The sliders are horizontal, and turning the wheel 'up' (away from you) decreases the slider value, and vice versa. This seems backwards to me. What does everyone else think? This is one of those things that will *have* to work the same way in every app, otherwise it's maddening for users, so we had better agree on it now. Alternatively, there has to be one place where this behavior can be set for all apps. What is not acceptable is for 50% to do it one way and 50% the other. What is really needed is a set of human interface guidelines for Linux audio apps. Better to do this now, while much of the code is not mature, than later, and have a bunch of different apps which work, except that the widgets work completely different from one app to another for no good reason other than that person A felt like doing it like this and person B like that. You can talk about freedom all you want but the users do not care about this kind of thing, it just looks like the left hand is not talking to the right. Professional users (rightfully) demand a consistent interface, unless there is a good reason (extra functionality) not to provide one. I would like to start putting these guidelines together. A good place to start is to document the behavior of the most popular and mature existing apps. Any suggestions are welcome. Lee

21 years, 2 months

Re: Re: [linux-audio-dev] Hello - FYI - intro

by Tom Molesworth

John Check <j4strngs(a)bitless.net> wrote: > "what the hell, there couldn't be any more major > updates". Wrong - one the updates in the batch that > took 2 days to build got rolled back, and since > there's no binaries Tell it to build binary packages, include the relevant flags to emerge to say "use binaries if you got 'em", and downgrades are almost as fast as rpm/deb systems. I love having the source archives to hand when I want to make changes - sure, not everyone wants this, and gentoo might not be suitable for them... and getting the source isn't always that difficult... but if you've ever been severed from the internet and want to change or fix or just look at a bit of code on your running system, chances are that it's in /var/distfiles ready to be used. I might carry around a Knoppix CD for luck, but Gentoo has a permanent home on every one of my computers. emerge is dead slow on anything less than a P-III though - especially searching and the last stage of a sync (index regeneration or whatever it is). Got a P-II that takes about ten minutes after the last bit of data has rsync'ed across before the prompt comes back. Compilation time is even longer? Sure, but I'd expect that. I don't expect the package manager to waste valuable compilation CPU cycles :) (no, it's not a big problem. yes, one day I'll even try rewriting portage in C if no one else has) TM

21 years, 2 months

[linux-audio-dev] Read this after your first cup of coffee

by John Check

Good Morning, Here's the position paper I drafted up. As usual I'll request that responses be well considered. I'll post this to my webserver after I have a chance to mark it up and hopefully, I can stop repeating myself and get things implemented. Apologies in advance for the length. Comments on what I propose to do are welcome, but it may take a while for me to reply. -------- Legitimizing Linux As an Audio Platform. The current state of affairs WRT to Linux as a platform for audio production is an open question, but in my considered opinion it is technically adequate to start getting some real traction. At the current pace, there will be some truly excellent applications in a years time, but it must be understood that everybody has time limitations and not taking that into account is counterproductive. Bottom up penetration (simmer down now) is the most likely to succeed path, however there are some issues which need to be addressed to improve on the chances and avenues. These issues are outside of the scope of interest for most developers. The pattern seems to be the people with the highest level of technical expertise are the least interested in these issues and that is as it should be. Coders should code, EE's should handle the physics, etc. In short, we all need to play to our strengths, especially since most of what goes on is done voluntarily. The issues that are playing against the community at large are not insurmountable obstacles and I intend to do some heavy lifting to try and change things. There are several phases to getting where we need to go, but here are the primary stumbling blocks. First I'll layout the issues, which fall into two categories, then I'll reveal my strategy for tackling them and why I think these opinions matter. The Issues: 1) Too Much Information A) Unclear development status and suitability of offerings. B) Unreasonable requirements for list monitoring. C) To much time spent on repetition of information in the wrong places. D) Disorganized and inadequate documentation. 2) There's Only 24 Hours In A Day A) Unnecessarily high time requirements for building code to evaluate. B) A somewhat distorted sense of what musicians and pro audio need/want C) Nobody cares about Linux except the converted. D) No compelling business case. Let's break it down: Too Much Information Unclear Development Status And Suitability Of Offerings http://linux-sound.org There is in excess of 36 categories of applications listed at the above URL. The "Sound Editors" category alone has 35 entries just in it's "General" sub-category. Each of these has their own particular raison d'etre and diversity is a good thing, but 3 of the first 10 listed projects according to timestamps on tarballs, haven't had a release in over 12 months. Two of the ten are Java based and one is a KDE app which means artsd. This particular sub-category has a relatively good ratio of active projects, but even so this means 7 pieces of software to evaluate when looking for a wav editor. We could extrapolate that number, but 7 is a good start and it includes some of the best candidates. Unreasonable Requirements For List Monitoring We've got 7 candidates for evaluation, 2 are unavailable as Debian packages. This isn't a problem because I use Debian, it's just an example. This is two out of 7 packages that need to be built from source. Again, it's not a problem for me, but assuming the user isn't comfortable with that, we're down to 5 on Debian and probably less on some other general purpose distros. So we install our 5 binary packages and have a pretty good idea what they can do, but if the user wants in depth info that's not covered in the documentation that comes with the package it's time for mailing lists. Most have at least 2 lists one for developers, one for users. That's potentially 10 lists subscriptions and 5 Wikis. 15 sources of information for 5 programs, not counting the man page and whatever is in the help menu. The key to making the lists useful is participation. If there is no traffic on the users list, it's a safe bet it's not because the programs UI is so intuitive that nobody has a question. There is a threshold of tolerance for user questions on the developer lists and that is also as it should be. Too Much Repetition of Information In Too Many Places See Unreasonable Requirements For List Monitoring ;) There is an interesting corollary here with the LA lists. I'm guessing that LA is supposed to be among other things, a sort of clearinghouse so that everybody has a place to get an overview of the big picture. I have personally seen a developer quote one of his own postings to an LA list in order to answer a specific on-topic question asked on his own project's list. Searching that project's list archive for this bit of info (which was pretty crucial) came up dry until the question was asked on the project's list and the person replying was helpful enough to find his LA post and answer what the question was. Not only was that aggravating to watch, but it was duplicated effort on the part of the developer answering the question. Disorganized And Inadequate Documentation It is not reasonable to expect coders to spend a lot of time on documentation. They can either improve the code or improve the documentation and even if we disregard the moving target factor, the latter isn't playing to their strength. Theoretically at least, if a user has a question that's not covered in the documentation and wants to help out, the coders will cooperate. The tendency is for build related questions to be well documented but stale, because Linux is a fast moving target with lots of parallel development and of course, actively maintained code changes. One common solution is to provide a Wiki so that users can maintain their own documentation easily. This is a good way to accumulate information, but it has its drawbacks. Chief among them is the requirement to visit the Wiki in order to use it, which can be problematic. Additionally, it's not unusual for the Wiki to not be accessible from the "Documentation" link and vice versa. Wiki's, like the rest of free software development are participation driven, which makes a good segue into the next part. If you had to look up "segue" pay close attention. There's Only 24 Hours In A Day I'll start out prefacing this by saying software is built for a purpose. If I'm looking for a new construction house, I can buy one or build one. I may be a big Bob Vila fan and choose to build one, but that doesn't mean I'm a fan of Roy Underhill and want to make my own lumber too. Or forge my own hammer and nails. Given enough stress, and wasted time, I'll more than likely to bail and find a contractor to finish, or even go buy a built house. Even if it's not custom and the roof leaks, the builder at least acknowledges the obligation to fix the leaky roof. I suppose free software is more like an old fashioned barn raising, but anybody participating in one of those sticks to what they can do and knows what a barn is supposed to be. Marble floors and a media center is nice in a building, but it doesn't keep the livestock dry. Unnecessarily High Time Requirements For Building Code To Evaluate. This is highly variable. Some projects have better build processes than others, and less bleeding edge requirements. As projects mature things tend to improve, but not always. It's not unheard of for an early on decision to leave a legacy of problems that only become more bothersome as time passes. It's not reasonable to expect this to change due to inertia, but these types of problems generate questions that fall into the "it's obvious to me" category. It's also not reasonable to expect users to either fix it or eat shit and like it. If a user spends enough time with the doco and the list archives they can usually hash it out build problems, but there comes a point when one either has to go "Gentoo" and drink the koolaid because of the time invested. (I've been there and if you're a Gentoo user who wants to flame me, tell me you didn't _want_ to love it after the time invested to install it fully bootstrapped). Or, the user gets fed up and moves to another piece of software. That's known as "getting burned" and it doesn't generate goodwill. If it happens enough times it ceases to become a [G|K|X]foo problem and becomes a LA problem because unhappy users complain loudly. Happy ones are mostly silent. What it has to do with LA is, people trying to use these programs for relaxation or to make a living with audio/music have time constraints too. One might be a tech in a going facility that got a green light to do some experimentation with LA when nothing else is going on, but if a paying client has a problem with the headphone system that the tech didn't get around to fixing because he was cocking around trying to find an answer to something that was "obvious to me" or even worse figure out why "it works for me" and not him, guess which facility isn't going to be testing any LA software? A Bob Clearmountain or Bruce Swedien certainly isn't likely to spend the time tweaking out a system. This kind of thing can fly in a weekend project studio, but if you have a tech with that much time on his hands, you probably can't afford to pay for deadwood, unless maybe you use the studio as a cover to launder money, in which case "free" _really_ has no place there. (If you just started looking at the floor and shuffling your feet, I do consulting ;) On the other end of it (the low, low end ;) are schmucks like me who just want to gig, and while I have the time and the inclination to do this, it still cuts in to rehearsal and promotion time, which means less work for me and less exposure for you. We need each other, so let's not be coy. A Somewhat Distorted Sense Of What Musicians And Pro Audio Need/Want Again, this is variable. Some applications, like Ardour and Jamin, would drop right into a professional setting, because they do what they're supposed to and the interface is what people who use these kinds of tools expect, even if they're not 1:1 knock-offs of commercial apps. Other tools like oh, say Ecasound, or Cecilia would flop, especially with the "prosumer" crowd that buys things like standalone HD recorders and synth modules. These apps may be technically excellent, but look at how many musicians can't even read standard notation! If these kinds of folks want to get experimental, it's power it up and twist some dials and see where it goes. Neither one has an interface suitable for spontaneous creative monkeying. Cecilia would fare better than ecasound in that scenario, but chances are anybody that could use either of them effectively to create traditional music is an EE or a CS by day. My intention is not to slam either of these apps. They've been around for a relatively long time for a reason; They work. They're just a tad esoteric for general use and fill a niche. I'm not aware of any commercial software that does any of these things that doesn't have it's share of problems too. The tendency in professional settings is to be conservative with revisions and put off updates until somebody else has tested them, or if they have on staff techs and a lab, stress test well before inserting it in the revenue stream. The difference, when it comes to whether or not time spent getting support is worth the cost is simple. The vendor is obligated to come up with answers and the cost is quantifiable up front. If somethings not going to happen, they tell you. "We don't support foo". You may hear "Foo will be supported in the next version" from marketing, but you don't see that on the homepage they way you see "Aims to support foo, bar and baz" on a lot of sourceforge homepages. Nobody Cares About Linux Except The Converted. They really don't. They care about quality and stability, sure, but just because it runs on Linux doesn't mean it's inherently stable or high quality. There's a joke among sound men and recording engineers that all the equipment runs on magic smoke. Once you let the smoke out, it doesn't work anymore. All that matters is that it works as advertised, and not just to the bean counters. A Windows power user that can put together his own ProTools DAW isn't going to be real interested in feeling like a noob and getting flack because he's not comfortable patching kernels. They may not even be comfortable getting DeMuDi up and running. It doesn't mean they're an idiot, it means they know their limitations. Fortunately, this particular nit is not news. Of course Macs are still solidly entrenched so that has to tell you something. No Compelling Business Case. Yes, I know, it's not about the money. Well, I hate to be the one to tell you, but as soon as you say "professional", it is. And let's face it, if you're a core developer and you were offered a royalty or even a salary to do what you're doing for free you'd take it. There's no reason you shouldn't benefit even if there's no legal requirement for a vendor to show appreciation. You wouldn't have a legal obligation to address the vendors requests without a contractual obligation now either, would you? Now that that's out of the way, let's consider the business angle from a potential user's point of view, relative to the standard arguments for free software. Joe Haxor: It runs on Linux! Mark Pigeon: What? On Lindows? I saw that in K-Mart, I wasn't impressed JH: You'll get a lifetime of free upgrades. MP: How often do these upgrades break file format compatibilty? JH: Almost never... Sometimes it happens, but somebody can write a filter. MP: Almost? What about my archived work? JH: And it will always be supported, because you can fix it yourself! MP: But I'm not a programmer. I took a course in BASIC when I was in school, but that was a while ago. JH: Basic huh? That must have been some school. That's okay though, you can always hire a programmer! MP: I'm not a software house, I do radio spots. JH: Well, it doesn't cost anything, so you can pay the programmer per diem with what you save on commercial software! MP: Mmm lemme call my accountant. (ring ring, yack yack) He says custom software isn't deductible. JH: It's not custom! MP: Hang on (yack yack) He says it still not C.O.T.S. even before we modify it. JH: Tell him you can take the money you save on software and get twice as much hardware, that's deductible! MP: But then what do I pay for bug fixes with? And besides if I bring a programmer in they still have to wrap their head around the code. JH: AHA! You can hire the original programmer :D Now who better to fix the code than the guy who wrote it! :D MP: You mean the guy that implemented the bugs in the the first place? What happens if he gets hit by a bus? JH: Uh, well, um, there's a half dozen guys on the team and I know the code, so you can always hire me. MP: Well.. I guess thats true, but how do I know you'll be available? I'll tell you what, let's talk about hardware, now what's the warrantee like? JH: That'd depend on who you buy the hardware from. MP: I was thinking I'd buy it from you, since you're trying to sell me. What do you suggest? JH: Let's see.. you want a Foomax2k5 SMP board with a Flaprack googleplexer and MP: A wha? Lemme ask you this, what's it cost per I/O channel? JH: Depends on what you want. MP: I want to go have lunch. Go work up 2 year lease price on 24 channel system with a years support and 24 hr on-site emergency response and fax it to me when you have a number. JH: Why would you lease? MP: Okay, I have a business lunch to get to, let me walk you to your car. The moral of the story: There is no such thing as free and people have things to do. So What's Your Plan Smartass? First thing is to improve the documentation factor to help make things easier for the brave. Right now it's a Gordian knot and here are what the scissors look like. I expect we all know what a MIDI implementation chart is. I'm going to whomp up a database driven reporting system that extends the concept to include protocol and library support and has some Wiki like features. One will be able to search for specific types of programs with specific criteria like: Sequencers with LADSPA, JACK, DSSI, MESS, OSC, PHAT (Yes PHAT is that cool) Hits will come back in table form with checkmarks in the appropriate columns, ranked by how much of a match and a "freshness" date. The app name will link to the project site and there will be additional links to the primary documentation and the Wiki, if one exists. There will also be a link to and reporting form for an MI chart. Forms will be radio buttons/check boxes/combo boxes. The only text input will be for URLs. This should minimize grammatical and language issues as well as make internationalization easy. Links will be validated at a regular interval and 404's will generate an email to me, or if someone has taken responsibility for a project, that person. Bounced emails to that address will be returned to me for further investigation. This is intended for both developers and end users. It will take no more than 5 minutes to file a complete report. This may sound like a burden for the developers, but no more than a Wiki is a burden on users. I'll prime the pump with some reports on what I use myself. Newly interested users looking to help out on projects should find filing a report to be a good way to begin. This by itself isn't quite enough, but it's a start. I'm also planning on subscribing the system to the LAA list or possibly spidering the list archive for announcements to get the ball rolling with automating some of the updating. As far as library support goes, I'm going to keep a CVS tree of what I consider to be the cream that will be cron'ed to update daily, then recursed and diffed for new options in configure files. New options will initially generate an email to me, and if all goes well will eventually report directly to the system. I would appreciate any ideas on what should be included, but I'm not going to get into extended debates about what should be in. I'm the ultimate arbiter, at least until it debuts. The basic manual reporting and search should be live in 7-10 days. What About The Business Angle Then, Donald Chump? That's the easy part. I'm laying the legal groundwork for becoming a vendor and support channel for turnkey systems. There is a lot of money spent on this kind of stuff and if price is a factor, it only takes a few dollars difference. Anything more than that is counter productive. If you don't believe me, have a garage sale and put out a box of "free" stuff, then after an hour or two put "$1" on it people might haggle you down but it'll move. "Linux" will be on the last page of the brochure. If all goes according to plan the biggest chunk of revenue is going into R&D, which means to guys who've been doing heavy lifting on the core apps. Anything they're not interested in gets farmed out, most likely on a bounty. Despite the apparent lack of popularity of the idea, it will have distributed processing as an option. This will allow for incremental penetration and interoperability with existing systems. Depending on the budget one has there are more ways to skin that cat than the plugin route. We have MADI support on the platform for the high end and good old coax for low end applications like live FX processing. And there you have it. Why these opinions should matter is self evident.

21 years, 2 months

[linux-audio-dev] Jackbeat : contributors needed

by Olivier Guilyardi

Hi, I feel like it's not a usual way to ask for contributions, but, well, I thought I'd give it a try : I'm the author of Jackbeat, at http://xung.org/jackbeat, and my day job's currently eating my time. I've just released the 0.3 development version which is a rewrite, forked from the (quite) stable 0.2 branch. Here comes the todo list : * Saving and loading songs is broken. This has to be rewritten : - implement a new song file format, based on an xml metadata format, with all samples stored in a subdirectory, all that packed in a tar archive, using libtar (http://www.feep.net/libtar). FLAC compression would be nice as well. - provide backward compatibility for jackbeat 0.2's .jab binary file format * Pattern nesting. This allows using another instance of Jackbeat as a sample. This is called "buses" in some other software : - this is half-implemented * Syscall-free IPC : - currently posix message queues are used to talk with the JACK thread. This has to be changed to a lock-free fifo. Jackbeat do have users, and I'd really like to keep it alive. If any of you have interest in participating in this project, especially by contributing some code, please let me know. About the song file format : it looks to me like this tar+xml+flac format could be implemented as a library. Chances are that it could be reusable in many contexts. Regards -- og

21 years, 2 months

[linux-audio-dev] Re: linux-audio-dev Digest, Vol 11, Issue 35

by John Lazzaro

On Aug 20, 2004, at 6:43 PM, Paul David wrote: > there may be people who are sight-impaired who manage to make a living > as an audio engineer, but i would guess that i could count them all on > the fingers of one hand. Sound on Sound (or maybe it was Mix ...) did a feature article on two blind engineers who built their own studio to work out of ... it was a really interesting article, but I can't seem to locate on the web at the moment ... maybe someone can find it and post the link (it was a free article, I'm not a subscriber to either). --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu ---

21 years, 2 months

[linux-audio-dev] ANN: Distributed LADSPA Processing

by Nelson Posse Lago

Hi, Have you ever wondered if it is possible to escape the limits imposed by your cpu to the number of ladspa plugins you can run simultaneously, while keeping latency low? Well, yes, there is. This email is to let you know about DLADSPA (Distributed LADSPA). While there are a few rough edges on the code, there has been some talk related to it on this list and so I'm bringing it to the table. DLADSPA allows you to group several LADSPA plugins on a chain that appears as a single "meta-plugin". This meta-plugin is loaded by your application as any other plugin, but in fact it loads the "real" plugins in the chain on a remote machine and sends the data for remote processing at each interaction. There are some limitations: - the system needs every period to be the same size (unless you are not running in real-time or the remote load is *very* low, but then what is the point?). - The system adds to the latency the equivalent of a single period. That is, if your period size is 2ms for a total input-to-output latency of 4ms, the system adds another 2ms to the latency, so total latency goes to 6ms. - You cannot define the chain of plugins to be loaded remotely from within your application; that needs to be done separately (using jack-rack), the chain must be saved and the application restarted. - right now, there is a simple GUI missing, configuration is complicated thanks to a corba layer that needs to be eliminated, the code is tricky to compile (but it *does* compile on debian stable) and error handling is non-existant (any error calls exit(), which means your app crashes). If jack udp transport doesn't work adequately (haven't tested it), I intend to adapt the code to work on top of jack too (should be reasonably easy). It is available at my homepage: http://gsd.ime.usp.br/~lago/masters Hope you enjoy it, Nelson ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

21 years, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev