Re: [linux-audio-dev] mux concept paper
but IMHO, you should be looking at Beast or gAlan or ALSA Modular Synth, or SSM or ... not starting from scratch. And Pd, which is the oldest and probably most capable and stable of all the available graphical softsynths running on Linux. i think people get confused about the difference between a synthesizer which can host plugins and a sequencer which can host plugins. galan, ams, ssm and pd are fine programs but they aren't designed for the same job that mimo wants to do. beast is quite close but (as he already said) it's too cpu-heavy for him, and it doesn't focus on a super-usable sequencer the way (eg) buzz does. it's no good telling mimo to contribute code to beast (for example) unless you think the authors will allow him to strip out the gui to make it run the way he (mimo) wants. (btw i hope i'm not putting words in his mouth, apologies if so.)
Re: [linux-audio-dev] mux concept paper
Hallo, Paul Davis hat gesagt: // Paul Davis wrote: but IMHO, you should be looking at Beast or gAlan or ALSA Modular Synth, or SSM or ... not starting from scratch. And Pd, which is the oldest and probably most capable and stable of all the available graphical softsynths running on Linux. It also has a dsp graph inside, which is quite clever, but indeed it can lead to dropouts if you create a lot of objects at the same time, as the dsp graph needs to reorder itself. However live patching is possible in Pd and it is done by a lot of users. Regarding the live capabilities of Pd, let me tell you a recent story: Last weekend we did an improvisation gig in my town, where ten laptop artists, most of them running Pd on Linux (seven, and one running Max/MSP on OS-X, two running Supercollider on OS-X) were playing together for a really long time (about an hour, but some participiants just couldn't stop... ;) All machines were synchronized through OSC messages coming from my machine sent to broadcast addresses, one main machine with Pd on Linux was receiving all the other machines' audio data through its RME card and then doing spatialization with them in Pd which fed 16 speakers with sounds running over 8 independent paths (which were in turn controllable by everyone involved through OSC again). This was quite an impressive setup, and Pd did not fail on a single box through the whole performance. Oh, and some people were also doing video art with their Pd/Linux boxes. Can Buzz do all this? Ciao -- Frank Barknecht _ __footils.org__ _ __latest track: fqdn _ http://footils.org/cms/show/38
Re: [linux-audio-dev] mux concept paper
hi mimo, are you thinking of something like buzz (or maybe max/msp) where audio can be routed in a free-form network from sources (generators) to sink (master output)? i'm a big fan of this idea. the Preprocessor Level that lazily generates a set optimised list of instructions for the audio io level can you go into more detail on this point? are you planning to use ladspa/dssi plugins as the machines? i think it's a good idea to make something that can be relied on in a live gig.
Re: [linux-audio-dev] mux concept paper
Hi James, James McDermott wrote: hi mimo, are you thinking of something like buzz (or maybe max/msp) where audio can be routed in a free-form network from sources (generators) to sink (master output)? i'm a big fan of this idea. You got me! I am a long term buzz user, used it for live gigs, and wrote a keyboard based mixer for it. I have seen other people using max/msp -- impressive. But there are also some downsides which I want to overcome. The principal idea and the simplicity of buzz I think are unique. the Preprocessor Level that lazily generates a set optimised list of instructions for the audio io level can you go into more detail on this point? The idea goes like this. Usually what you do in this type of programme is build some sort of tree representation of the generators and effects. So you need some sort of algorithm to find the processing order of the different machines. Most of the actual running time the processing order doesnt change. Only if the user adds or removes connections between machines the processing order has to be recalculated. Changes like the volume level between two machines or a control input into a machine (like sending a different note) do not have any impact on the processing order. A lot of time is spent on finding the processing order. But this only needs to be done once in a while. The rest of the time it needs to run just a list of simple instructions, like mix buffer a and b to buffer c, run a machine on buffer c, etc. 'Lazily' means that the recalculation should be done 'in the background', while the output still comes from the 'old' processing order. Only when the new processing order is finished will it activated. are you planning to use ladspa/dssi plugins as the machines? Ladspa is limited. I'd rather use a super class of Ladspa that allows using Ladspa, etc. i think it's a good idea to make something that can be relied on in a live gig. Thanks. mimo -- Please note that this account is being filtered using anti UCE systems. If you send email to this account make sure that it could not be mistaken as UCE.
Re: [linux-audio-dev] mux concept paper
it all sounds a lot like Beast to me ... http://beast.gtk.org/ --p
Re: [linux-audio-dev] mux concept paper
Hi Mimo, I have put online the beginngs of a concept paper for an audio program I have been wanting to write for quite a while now. I wondered whether you could give me some feedback on it and share some of your experiences with me. A while ago I decided to call this *mux* where the name stands for nothing in particular. I have tested a couple of similiar audio apps for linux recently, and then toyed around with libraries I found on the net. I might be reinventing the wheel once more, but that's up for discussion.. The paper is work in progress, I'm hoping to add to it tomorrow night. Looking forward to hear back from you and thanks for any input.. PS.: the paper is here http://mimo.gn.apc.org/mux/ First of all: nice initiative. But... ...why create a new modular audio framework, if you could improve, harden and extend an existing one? Think of all that hairy GUI code that you don't have to write and debug... Another thing: I don't agree with the assessment in your paper that jack is heavy-weight - and I think jack is much more natural fit to your application as jackd has xrun detection, already provides means to set a lower samplerate and increase period size if your system can't put up with the load. IMHO jack is the way to go if your target platform is only Linux (or OSX BSD), otherwise the cross-platform PortAudio may be more appropriate. Just my two euro cents ;-) Cheers, Walco
Re: [linux-audio-dev] mux concept paper
Walco wrote: Hi Mimo, PS.: the paper is here http://mimo.gn.apc.org/mux/ First of all: nice initiative. But... ...why create a new modular audio framework, if you could improve, harden and extend an existing one? Think of all that hairy GUI code that you don't have to write and debug... Well and yes. I agree and principle and looked at existing ones but seriously didnt like them. beast was mentioned, it's gtk and I cant get my head around gtk. Also, it's very heavy on the machines I have tried. The other thing is, you look at existing code, often undocumented one. So you end up spending more time trying to find out what someone else was thinking while he did this... and from my experience, often when you finish a program, it's best to sit down and rewrite it from scratch. But I'm open for suggestions, so if anyone knows of an active project that I might contribute to let me know Another thing: I don't agree with the assessment in your paper that jack is heavy-weight - and I think jack is much more natural fit to your application as jackd has xrun detection, already provides means to set a lower samplerate and increase period size if your system can't put up with the load. IMHO jack is the way to go if your target platform is only Linux (or OSX BSD), otherwise the cross-platform PortAudio may be more appropriate. I know it was a bit provocative to write that. Also, jack is under development and I should probably wait for an official release before complaining. But my experiences with jack are negative. First time I started looking at it I had huge expectations after all that I had read. First problems, after a couple of second of running without any actual processing going on, strange noise artefacts kind of getting worse. I had a look at source code and realise that it bases its time calculation on cpu MHz in /proc/cpuinfo. I dont know about your machine, but on my machine(s) a) this is a float and b) it's slightly different every time I boot the machine. The other thing I dont understand about jack is the whole graph business. E.g. I look at the artsd in kde and plugin an effect and this is seamless, no stopping of audio. In jack, it says recalculating graph and get a cup of coffee :) Ok, enough ranting... sorry didnt want to discuss jack really. Cheers, Walco mimo -- Please note that this account is being filtered using anti UCE systems. If you send email to this account make sure that it could not be mistaken as UCE.
Re: [linux-audio-dev] mux concept paper
You got me! I am a long term buzz user, used it for live gigs, and wrote a keyboard based mixer for it. oh - you wrote miXo - of course. (i wrote a peer machine or two.) go buzz devs! i think everyone who's ever used buzz for more than a couple of hours wants a new, stable, cross-platform version. (and there are *loads* of re-implementation projects, including at least one linux one.) i even have some semi-formed plans myself... A lot of time is spent on finding the processing order. But this only needs to be done once in a while. i'd be very surprised by that (i haven't looked at any code though). surely it's a very light task, computationally? i'm thinking that if the machine network is represented by a tree, just a depth-first search through the tree gets you the right processing order?
Re: [linux-audio-dev] mux concept paper
Walco wrote: Hi Mimo, I have put online the beginngs of a concept paper for an audio program I have been wanting to write for quite a while now. I wondered whether you could give me some feedback on it and share some of your experiences with me. A while ago I decided to call this *mux* where the name stands for nothing in particular. I have tested a couple of similiar audio apps for linux recently, and then toyed around with libraries I found on the net. I might be reinventing the wheel once more, but that's up for discussion.. The paper is work in progress, I'm hoping to add to it tomorrow night. Looking forward to hear back from you and thanks for any input.. PS.: the paper is here http://mimo.gn.apc.org/mux/ [snip] Another thing: I don't agree with the assessment in your paper that jack is heavy-weight - and I think jack is much more natural fit to your application as jackd has xrun detection, already provides means to set a lower samplerate and increase period size if your system can't put up with the load. IMHO jack is the way to go if your target platform is only Linux (or OSX BSD), otherwise the cross-platform PortAudio may be more appropriate. I'll chime in here. I've been testing Csound5 quite a lot lately, it supports PortAudio (as well as ALSA and JACK) and PortMIDI. Frankly, I'm not impressed with default realtime performance under PortAudio. I can improve performance with some judicious buffer tweaks, but the native ALSA driver is much better. I also agree with Walco re: JACK weight. Nevertheless, it's Linux, innit ? So you can do what you like... :) Btw, mimo: Have you tried using Buzz under Linux ? I've had it working quite nicely, it's a very impressive program, lots of fun. A native Buzz would be most welcome. Best, dp
Re: [linux-audio-dev] mux concept paper
on the subject of beast (and maybe some other programs), i'd agree that it's cpu-intensive. the great thing about buzz (sorry for going on about it) is that it's fast: songs using 50+ plugins are possible on old machines, like my 566 MHz celeron laptop.
Re: [linux-audio-dev] mux concept paper
I know it was a bit provocative to write that. Also, jack is under development and I should probably wait for an official release before this is not really true. there have been no API changes to the core of JACK for at least a year. complaining. But my experiences with jack are negative. First time I started looking at it I had huge expectations after all that I had read. First problems, after a couple of second of running without any actual processing going on, strange noise artefacts kind of getting worse. I had a look at source code and realise that it bases its time calculation on cpu MHz in /proc/cpuinfo. I dont know about your machine, but on my machine(s) a) this is a float and b) it's slightly different every time I boot the machine. this has nothing to do with your noise. JACK uses CPU Hz to provide a UST value. i am puzzled by the fact you are the 2nd person to think that JACK's timing is somehow based on system timers and so forth. JACK (in regular mode, using one of the normal backends) is driven 100% by the interrupt from your audio interface. whether or not the CPU Hz value is correct has (effectively) zero impact on audio generation and timing. The other thing I dont understand about jack is the whole graph business. E.g. I look at the artsd in kde and plugin an effect and this is seamless, no stopping of audio. In jack, it says recalculating graph and get a cup of coffee :) good grief. that's a ludicrous comment. it takes fractions of a millisecond to recompute the graph. and yes, artsd doesn't break the audio chain because it isn't built around low latency - stefan has acknowledged that. there is a new implementation of jack for osx that also doesn't break audio processing during graph reorders - it uses lock free techniques. but guess what - it has one process-cycle worth of extra latency as a result. so, as they say in the UK: you pays your money and you makes your choice. you can have absolute minimal latency, but that requires locking the graph against use when it is reordered. Ok, enough ranting... sorry didnt want to discuss jack really. well, you can't go around making ill-informed comments about someone else's software and not expect a discussion. that being said, JACK is *not* appropriate as a replacement for the engine in something like Buzz. JACK does not scale well much beyond, well, it depends on your machine, but in general terms, on the order of 5-10 clients. This isn't a defect - its a reflection of what it designed to do. but IMHO, you should be looking at Beast or gAlan or ALSA Modular Synth, or SSM or ... not starting from scratch. --p
Re: [linux-audio-dev] mux concept paper
Dave Phillips wrote: Btw, mimo: Have you tried using Buzz under Linux ? I've had it working quite nicely, it's a very impressive program, lots of fun. A native Buzz would be most welcome. I guess you mean under wine. I have but wasnt impressed with performance (maybe I really should get a better machine after all.. hmm.. but buzz used to run fine on a 230Mhz machine.. no it must be feasible ;) ) Yes, native buzz this should be with some minor improvements. Best, dp mimo -- Please note that this account is being filtered using anti UCE systems. If you send email to this account make sure that it could not be mistaken as UCE.
Re: [linux-audio-dev] mux concept paper
Paul Davis wrote: complaining. But my experiences with jack are negative. First time I started looking at it I had huge expectations after all that I had read. First problems, after a couple of second of running without any actual processing going on, strange noise artefacts kind of getting worse. I had a look at source code and realise that it bases its time calculation on cpu MHz in /proc/cpuinfo. I dont know about your machine, but on my machine(s) a) this is a float and b) it's slightly different every time I boot the machine. this has nothing to do with your noise. JACK uses CPU Hz to provide a UST value. i am puzzled by the fact you are the 2nd person to think that JACK's timing is somehow based on system timers and so forth. JACK (in regular mode, using one of the normal backends) is driven 100% by the interrupt from your audio interface. whether or not the CPU Hz value is correct has (effectively) zero impact on audio generation and timing. Just out of interest, if it is dependent on the audio hardware, why do I get the same problems with different sounds cards on the same machine, and a colleague gets them with completely different hardware all the same. Any ideas what might be the reason? Anyone else with the same experiences? The other thing I dont understand about jack is the whole graph business. E.g. I look at the artsd in kde and plugin an effect and this is seamless, no stopping of audio. In jack, it says recalculating graph and get a cup of coffee :) good grief. that's a ludicrous comment. it takes fractions of a millisecond to recompute the graph. and yes, artsd doesn't break the audio chain because it isn't built around low latency - stefan has acknowledged that. there is a new implementation of jack for osx that also doesn't break audio processing during graph reorders - it uses lock free techniques. but guess what - it has one process-cycle worth of extra latency as a result. so, as they say in the UK: you pays your money and you makes your choice. you can have absolute minimal latency, but that requires locking the graph against use when it is reordered. Ok, enough ranting... sorry didnt want to discuss jack really. well, you can't go around making ill-informed comments about someone else's software and not expect a discussion. Sure, point taken. that being said, JACK is *not* appropriate as a replacement for the engine in something like Buzz. JACK does not scale well much beyond, well, it depends on your machine, but in general terms, on the order of 5-10 clients. This isn't a defect - its a reflection of what it designed to do. Good to know, so I misread the jack spec in the first place because I was expecting it to do what I wanted to do -- the many machines processor. but IMHO, you should be looking at Beast or gAlan or ALSA Modular Synth, or SSM or ... not starting from scratch. One thing, I dont want to start completely from scratch. At least I'm going to nick some lines of code from someone elses project :) mimo -- Please note that this account is being filtered using anti UCE systems. If you send email to this account make sure that it could not be mistaken as UCE.
Re: [linux-audio-dev] mux concept paper
On Thu, Feb 17, 2005 at 08:40:01AM -0500, Paul Davis wrote: you can have absolute minimal latency, but that requires locking the graph against use when it is reordered. AFAICS, that is not the real reason. If it were, the simple solution would be to let the engine continue using a copy of the current graph while the new one is being computed and the required resources created. Probably if look you into it deep enough you'll find that the necessity to stop processing while new clients are created or when the port connection change can be traced back to the combined effect of: 1. only having one JACK-controlled thread in each client, 2. the synchronous nature of the API calls that modify the graph. -- FA
Re: [linux-audio-dev] mux concept paper
On Thu, Feb 17, 2005 at 02:00:24 +, mimo wrote: Paul Davis wrote: complaining. But my experiences with jack are negative. First time I started looking at it I had huge expectations after all that I had read. First problems, after a couple of second of running without any actual processing going on, strange noise artefacts kind of getting worse. I had a look at source code and realise that it bases its time calculation on cpu MHz in /proc/cpuinfo. I dont know about your machine, but on my machine(s) a) this is a float and b) it's slightly different every time I boot the machine. this has nothing to do with your noise. JACK uses CPU Hz to provide a UST value. i am puzzled by the fact you are the 2nd person to think that JACK's timing is somehow based on system timers and so forth. JACK (in regular mode, using one of the normal backends) is driven 100% by the interrupt from your audio interface. whether or not the CPU Hz value is correct has (effectively) zero impact on audio generation and timing. Just out of interest, if it is dependent on the audio hardware, why do I get the same problems with different sounds cards on the same machine, and a colleague gets them with completely different hardware all the same. Any ideas what might be the reason? Anyone else with the same experiences? Are you running it in realtime mode? If not, and jackd misses realtime deadlines you will often get noises in the output. - Steve
Re: [linux-audio-dev] mux concept paper
Just out of interest, if it is dependent on the audio hardware, why do I get the same problems with different sounds cards on the same machine, and a colleague gets them with completely different hardware all the same. Any ideas what might be the reason? Anyone else with the same experiences? I don't know. I don't recall anyone ever having reported this kind of noise, certainly not within the last year or two of JACK's history. You are talking about a system that is just running jackd, no clients, correct? What audio h/w are we talking about? Good to know, so I misread the jack spec in the first place because I was expecting it to do what I wanted to do -- the many machines processor. it *is* intended to connect multiple audio applications together, but the design goals weren't based on each of those applications being on the scale of a buzz machine, or a LADSPA/DSSI plugin. the idea was that applications would host the .dll level plugins, and JACK would host the applications. and it does so rather well, from what we hear. --p
Re: [linux-audio-dev] mux concept paper
you can have absolute minimal latency, but that requires locking the graph against use when it is reordered. AFAICS, that is not the real reason. If it were, the simple solution would be to let the engine continue using a copy of the current graph while the new one is being computed and the required resources created. Probably if look you into it deep enough you'll find that the necessity to stop processing while new clients are created or when the port connection change can be traced back to the combined effect of: 1. only having one JACK-controlled thread in each client, 2. the synchronous nature of the API calls that modify the graph. stephane's new OSX implementation (jackdmp) avoids both of these, and ends up with an extra process-cycle worth of latency. he does exactly what you suggest above. is it avoidable? i don't know. stephane didn't seem to think so when we talked about it briefly on IRC. maybe it can be. --p
Re: [linux-audio-dev] mux concept paper
Steve Harris wrote: On Thu, Feb 17, 2005 at 02:00:24 +, mimo wrote: Paul Davis wrote: complaining. But my experiences with jack are negative. First time I started looking at it I had huge expectations after all that I had read. First problems, after a couple of second of running without any actual processing going on, strange noise artefacts kind of getting worse. I had a look at source code and realise that it bases its time calculation on cpu MHz in /proc/cpuinfo. I dont know about your machine, but on my machine(s) a) this is a float and b) it's slightly different every time I boot the machine. this has nothing to do with your noise. JACK uses CPU Hz to provide a UST value. i am puzzled by the fact you are the 2nd person to think that JACK's timing is somehow based on system timers and so forth. JACK (in regular mode, using one of the normal backends) is driven 100% by the interrupt from your audio interface. whether or not the CPU Hz value is correct has (effectively) zero impact on audio generation and timing. Just out of interest, if it is dependent on the audio hardware, why do I get the same problems with different sounds cards on the same machine, and a colleague gets them with completely different hardware all the same. Any ideas what might be the reason? Anyone else with the same experiences? Are you running it in realtime mode? If not, and jackd misses realtime deadlines you will often get noises in the output. Yes, and root, tried evryting I could think of. And again, this happens without any load. mimo - Steve -- Please note that this account is being filtered using anti UCE systems. If you send email to this account make sure that it could not be mistaken as UCE.
Re: [linux-audio-dev] mux concept paper
Le 17 févr. 05, à 15:26, Alfons Adriaensen a écrit : On Thu, Feb 17, 2005 at 08:40:01AM -0500, Paul Davis wrote: you can have absolute minimal latency, but that requires locking the graph against use when it is reordered. AFAICS, that is not the real reason. If it were, the simple solution would be to let the engine continue using a copy of the current graph while the new one is being computed and the required resources created. Probably if look you into it deep enough you'll find that the necessity to stop processing while new clients are created or when the port connection change can be traced back to the combined effect of: 1. only having one JACK-controlled thread in each client, 2. the synchronous nature of the API calls that modify the graph. -- FA These kind of problems are addressed in jackdmp, (jackd for multi-processors) where new clients, ports and connections can be done/changed without stopping the audio stream. Look at http://www.grame.fr/~letz/jackdmp.zip for the OSX version which contains a technical paper explaining the new implementation. Stephane Letz
Re: [linux-audio-dev] mux concept paper
Le 17 févr. 05, à 15:43, Paul Davis a écrit : you can have absolute minimal latency, but that requires locking the graph against use when it is reordered. AFAICS, that is not the real reason. If it were, the simple solution would be to let the engine continue using a copy of the current graph while the new one is being computed and the required resources created. Probably if look you into it deep enough you'll find that the necessity to stop processing while new clients are created or when the port connection change can be traced back to the combined effect of: 1. only having one JACK-controlled thread in each client, 2. the synchronous nature of the API calls that modify the graph. stephane's new OSX implementation (jackdmp) avoids both of these, and ends up with an extra process-cycle worth of latency. he does exactly what you suggest above. is it avoidable? i don't know. stephane didn't seem to think so when we talked about it briefly on IRC. maybe it can be. --p Just one word about the one extra process-cycle worth of latency: this is not exactly related to the fact that the graph is updated without stopping the audio thread : one could perfectly keep the current model (where the server waits for the client graph execution end to write the output buffer ) *and* have the don't stop audio thread property most of the time. The one extra process-cycle worth of latency is a consequence of another idea to implement a more robust system, where robust mean a system where *some* audio clients may fail during one cycle without stopping the entire graph. Stephane
Re: [linux-audio-dev] mux concept paper
On Thu, Feb 17, 2005 at 09:43:16AM -0500, Paul Davis wrote: stephane's new OSX implementation (jackdmp) avoids both of these, and ends up with an extra process-cycle worth of latency. he does exactly what you suggest above. is it avoidable? i don't know. stephane didn't seem to think so when we talked about it briefly on IRC. maybe it can be. Strange. The only way you could have an extra cycle of latency is by explicitly programming for it, either inserting a buffer somewhere, or by changing the sequence backend wakeup - read inputs - call graph - write outputs to backend wakeup - write outputs - read inputs - call graph which amounts to the same thing. How would this help in allowing processing to continue during graph changes ? I'm convinced it should be possible. The price to pay should not not be increased audio latency, but an asynchronous interface to the client creation / port creation and connection functions. In other words, you will have to request something and the result will be known not when your call returns, but by some asynchronous event. This makes sense anyway for things that can be modified from any number of places at the same time. -- FA
Re: [linux-audio-dev] mux concept paper
On Thu, 2005-02-17 at 09:39 -0500, Paul Davis wrote: Just out of interest, if it is dependent on the audio hardware, why do I get the same problems with different sounds cards on the same machine, and a colleague gets them with completely different hardware all the same. Any ideas what might be the reason? Anyone else with the same experiences? I don't know. I don't recall anyone ever having reported this kind of noise, certainly not within the last year or two of JACK's history. You are talking about a system that is just running jackd, no clients, correct? What audio h/w are we talking about? The only time I have heard of this happening is when people do something stupid like trying to run JACK with an emu10k1 at 44100KHz. Lee
Re: [linux-audio-dev] mux concept paper
On Thu, 2005-02-17 at 08:40 -0500, Paul Davis wrote: complaining. But my experiences with jack are negative. First time I started looking at it I had huge expectations after all that I had read. First problems, after a couple of second of running without any actual processing going on, strange noise artefacts kind of getting worse. I had a look at source code and realise that it bases its time calculation on cpu MHz in /proc/cpuinfo. I dont know about your machine, but on my machine(s) a) this is a float and b) it's slightly different every time I boot the machine. this has nothing to do with your noise. JACK uses CPU Hz to provide a UST value. i am puzzled by the fact you are the 2nd person to think that JACK's timing is somehow based on system timers and so forth. JACK (in regular mode, using one of the normal backends) is driven 100% by the interrupt from your audio interface. whether or not the CPU Hz value is correct has (effectively) zero impact on audio generation and timing. Besides, I wrote a patch to eliminate the /proc/cpuinfo hack, it's low prio but should be in JACK eventually. But like Paul says this has absolutely nothing to do with the sound. Lee
Re: [linux-audio-dev] mux concept paper
On Thu, Feb 17, 2005 at 02:45:22 +, mimo wrote: Are you running it in realtime mode? If not, and jackd misses realtime deadlines you will often get noises in the output. Yes, and root, tried evryting I could think of. And again, this happens without any load. Is the card a soundblaster live derivative? I beive there was a problem with these at some point. - Steve
Re: [linux-audio-dev] mux concept paper
On Thu, Feb 17, 2005 at 11:20:06 -0500, Lee Revell wrote: this has nothing to do with your noise. JACK uses CPU Hz to provide a UST value. i am puzzled by the fact you are the 2nd person to think that JACK's timing is somehow based on system timers and so forth. JACK (in regular mode, using one of the normal backends) is driven 100% by the interrupt from your audio interface. whether or not the CPU Hz value is correct has (effectively) zero impact on audio generation and timing. Besides, I wrote a patch to eliminate the /proc/cpuinfo hack, it's low prio but should be in JACK eventually. But like Paul says this has absolutely nothing to do with the sound. Actually it can be on laptops with CPU scaling. JACK gets sufficiently confused on mine that it tells ALSA to restart the card constantly, causing all kinds of noise. I have to lock the CPU to the maximum frequency to stop it happening. - Steve
Re: [linux-audio-dev] mux concept paper
Lee Revell wrote: On Thu, 2005-02-17 at 09:39 -0500, Paul Davis wrote: Just out of interest, if it is dependent on the audio hardware, why do I get the same problems with different sounds cards on the same machine, and a colleague gets them with completely different hardware all the same. Any ideas what might be the reason? Anyone else with the same experiences? I don't know. I don't recall anyone ever having reported this kind of noise, certainly not within the last year or two of JACK's history. You are talking about a system that is just running jackd, no clients, correct? What audio h/w are we talking about? The only time I have heard of this happening is when people do something stupid like trying to run JACK with an emu10k1 at 44100KHz. No, happened with rme96 at 44.1kHz -- will try to reproduce tonight and send you details. mimo Lee -- Please note that this account is being filtered using anti UCE systems. If you send email to this account make sure that it could not be mistaken as UCE.
Re: [linux-audio-dev] mux concept paper
On Thu, 2005-02-17 at 16:33 +, Steve Harris wrote: Besides, I wrote a patch to eliminate the /proc/cpuinfo hack, it's low prio but should be in JACK eventually. But like Paul says this has absolutely nothing to do with the sound. Actually it can be on laptops with CPU scaling. JACK gets sufficiently confused on mine that it tells ALSA to restart the card constantly, causing all kinds of noise. I have to lock the CPU to the maximum frequency to stop it happening. That thread kind of petered out on jackit-devel without a resolution. I have some more information on the problem. As many of you know the issue is that some CPU's frequency scaling implementations causes the TSC (which JACK and many other apps use because it's by far the cheapest high res timer on x86) to change speed, confusing JACK severely. According to the experts on LKML (specifically George Anzinger from MontaVista) these systems are BROKEN - IOW this behavior violates some spec. Newer machines (P4 and later) are guaranteed not to have the problem. The normal means for dealing with broken hardware, when you don't want to make everyone take a performance hit due to a few buggy systems, is to use a blacklist. Anyway this is an issue for jackit-devel. The short answer is to disable frequency scaling when you're doing audio work. Which is common sense anyway. Lee
Re: [linux-audio-dev] mux concept paper
On Thu, 2005-02-17 at 05:40, Dave Phillips wrote: Walco wrote: Hi Mimo, I have put online the beginngs of a concept paper for an audio program I have been wanting to write for quite a while now. I wondered whether you could give me some feedback on it and share some of your experiences with me. A while ago I decided to call this *mux* where the name stands for nothing in particular. I have tested a couple of similiar audio apps for linux recently, and then toyed around with libraries I found on the net. I might be reinventing the wheel once more, but that's up for discussion.. The paper is work in progress, I'm hoping to add to it tomorrow night. Looking forward to hear back from you and thanks for any input.. PS.: the paper is here http://mimo.gn.apc.org/mux/ [snip] Another thing: I don't agree with the assessment in your paper that jack is heavy-weight - and I think jack is much more natural fit to your application as jackd has xrun detection, already provides means to set a lower samplerate and increase period size if your system can't put up with the load. IMHO jack is the way to go if your target platform is only Linux (or OSX BSD), otherwise the cross-platform PortAudio may be more appropriate. I'll chime in here. I've been testing Csound5 quite a lot lately, it supports PortAudio (as well as ALSA and JACK) and PortMIDI. Frankly, I'm not impressed with default realtime performance under PortAudio. I can improve performance with some judicious buffer tweaks, but the native ALSA driver is much better. Just curious, what backend were you using with PortAudio? Alsa? -- Fernando
Re: [linux-audio-dev] mux concept paper
Hi Fernando: I built PortAudio (v19 I believe) with ALSA and JACK support but I haven't used it with JACK at all. When building Cs5 Scons will assume your PortAudio has been built with JACK, you need to specify if it isn't. Best, dp On Thu, 2005-02-17 at 05:40, Dave Phillips wrote: Walco wrote: Hi Mimo, I have put online the beginngs of a concept paper for an audio program I have been wanting to write for quite a while now. I wondered whether you could give me some feedback on it and share some of your experiences with me. A while ago I decided to call this *mux* where the name stands for nothing in particular. I have tested a couple of similiar audio apps for linux recently, and then toyed around with libraries I found on the net. I might be reinventing the wheel once more, but that's up for discussion.. The paper is work in progress, I'm hoping to add to it tomorrow night. Looking forward to hear back from you and thanks for any input.. PS.: the paper is here http://mimo.gn.apc.org/mux/ [snip] Another thing: I don't agree with the assessment in your paper that jack is heavy-weight - and I think jack is much more natural fit to your application as jackd has xrun detection, already provides means to set a lower samplerate and increase period size if your system can't put up with the load. IMHO jack is the way to go if your target platform is only Linux (or OSX BSD), otherwise the cross-platform PortAudio may be more appropriate. I'll chime in here. I've been testing Csound5 quite a lot lately, it supports PortAudio (as well as ALSA and JACK) and PortMIDI. Frankly, I'm not impressed with default realtime performance under PortAudio. I can improve performance with some judicious buffer tweaks, but the native ALSA driver is much better. Just curious, what backend were you using with PortAudio? Alsa? -- Fernando
Re: [linux-audio-dev] mux concept paper
I've touched on the concept. I started out with the same paper and desires, and ended up with pkaudio. PKAudio - simple, practical API, powerful, takes care of asynchronous communication. http://pkaudio.sf.net/ On Thursday 17 February 2005 03:22 am, James McDermott wrote: hi mimo, are you thinking of something like buzz (or maybe max/msp) where audio can be routed in a free-form network from sources (generators) to sink (master output)? i'm a big fan of this idea. the Preprocessor Level that lazily generates a set optimised list of instructions for the audio io level can you go into more detail on this point? are you planning to use ladspa/dssi plugins as the machines? i think it's a good idea to make something that can be relied on in a live gig.
Re: [linux-audio-dev] mux concept paper
On Thu, 2005-17-02 at 13:07 +, mimo wrote: Walco wrote: Hi Mimo, PS.: the paper is here http://mimo.gn.apc.org/mux/ First of all: nice initiative. But... ...why create a new modular audio framework, if you could improve, harden and extend an existing one? Think of all that hairy GUI code that you don't have to write and debug... Well and yes. I agree and principle and looked at existing ones but seriously didnt like them. beast was mentioned, it's gtk and I cant get my head around gtk. Also, it's very heavy on the machines I have tried. The other thing is, you look at existing code, often undocumented one. So you end up spending more time trying to find out what someone else was thinking while he did this... and from my experience, often when you finish a program, it's best to sit down and rewrite it from scratch. But I'm open for suggestions, so if anyone knows of an active project that I might contribute to let me know I'm working on a (currently) LADSPA-using modular synth called Om that's a seperate engine controlled by OSC (like supercollider). It already does all the process-order-in-the-background stuff you mentioned (ie there is a distinction between realtime and non-realtime events and they don't interfere with each other) and allows you to do everything in realtime. Two clients can even use it at once over the network and see the changes to the patch mirror on each other's screens. It's polyphonic, has subpatching, multiple toplevel patches (ie completely dynamic jack port creation), MIDI binding, blah blah etc. etc. I don't know if what you're planning on doing is a modular synth or something different/more, but if it's a modular synth you want to make.. help me, I'm many months ahead of you. :) The UI is gtk, but there's nothing stopping you from writing your own, the OSC commands are quite simple. I'm more than open to ideas that take things beyond just a modular synth (already experimenting with OSC-driven algorithmic stuff) and the engine is quite simple to extend in any resonable way. Feel free to drop me a line. -DR-
