[linux-audio-dev] strange jack ringbuffer problem
I've been banging my head against this one all evening. Now I'm going to
go to sleep on it, but I throw it out for the wiser and more experienced
to see if you can see my error.
The code is at http://fugal.net/~fugalh/src/alex which you are welcome
to refer to and critique.
It segfaults on line 171 of jack.cc, but not if I comment out line 158
(or use 0 for the second argument). It seems to segfault once input_rb
is nearly or completely to the end (not full, since it is being drained
by the other thread; it's just as it would wrap around). The autopsy
shows that it is segfaulting because output_rb and consequentially vec
is completely hosed. What I don't understand is how
jack_ringbuffer_write_advance(input_rb, something_plenty_small) could
possibly hose output_rb. something_plenty_small is usually on the order
of 160 bytes. I'm running jackd with a 512 byte buffer at 48000Hz.
(gdb) bt
#0 0xb7f91253 in src_short_to_float_array () from /usr/lib/libsamplerate.so.0
#1 0x0804a01c in Jack::jack_process (this=0xb300, nframes=512,
arg=0xb300) at jack.cc:171
#2 0x08049d87 in Jack::jack_process_wrapper (nframes=512, arg=0xb300)
at jack.cc:114
#3 0xb7fb255d in jack_stop_freewheel () from /usr/lib/libjack-0.80.0.so.0
#4 0xb7d639b4 in start_thread () from /lib/tls/libpthread.so.0
#5 0x in ?? ()
(gdb) up
#1 0x0804a01c in Jack::jack_process (this=0xb300, nframes=512,
arg=0xb300) at jack.cc:171
171 src_short_to_float_array((short*)vec[i].buf, buf, vframes);
(gdb) p *output_rb
$1 = {buf = 0xd0b0c860 ,
write_ptr = 92858992, read_ptr = 88669736, size = 4291362712,
size_mask = 13171512, mlocked = 3735008}
(gdb) p vec
$2 = {{buf = 0xd5f9c688 , len = 4189256}, {
buf = 0x804d028 "", len = 0}}
(gdb) p *input_rb
$3 = {buf = 0x804d028 "", write_ptr = 16266, read_ptr = 16266,
size = 16384, size_mask = 16383, mlocked = 0}
I hope someone can see what I'm doing wrong.
Consider the code under the GPL.
--
.O. Hans Fugal| De gustibus non disputandum est.
..O http://hans.fugal.net | Debian, vim, mutt, ruby, text, gpg
OOO| WindowMaker, gaim, UTF-8, RISC, JS Bach
-
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460
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-
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.
[linux-audio-dev] [ANN] libDSP-5.0.1
libDSP is a C++ library of digital signal processing functions with class and template interface. It also has a wrapper for C language. It also has assembler optimizations for x86 (E3DNow! and SSE2) and x86-64 platforms. Changes: - Assembler optimized version of complex multiply-add has been added. - Some makefile cleanups and fixes. Homepage: http://libdsp.sf.net http://www.sonarnerd.net/projects/libdsp/ Download: http://sourceforge.net/project/showfiles.php? group_id=25287&package_id=17119&release_id=305295 http://www.sonarnerd.net/projects/dlbins/ -- Jussi Laako (MiskaX || SonarNerd @ IRC) <[EMAIL PROTECTED]>
[linux-audio-dev] Re: X Error: BadWindow errors with qjackctl 0.2.15a
Lee Revell wrote: > Every time I start qjackctl from a remote X session I get these errors > at startup. I am using the Cygwin X server. > > X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 2 > Minor opcode: 0 > Resource id: 0x3a > X Error: BadAtom (invalid Atom parameter) 5 > Major opcode: 18 > Minor opcode: 0 > Resource id: 0x134 > X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 2 > Minor opcode: 0 > Resource id: 0x3a > X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 2 > Minor opcode: 0 > Resource id: 0x3a > X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 2 > Minor opcode: 0 > Resource id: 0x3a > X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 7 > Minor opcode: 0 > Resource id: 0x3a > X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 7 > Minor opcode: 0 > Resource id: 0x3a > > Then if I activate the Messages window and move the mouse back and forth > between it and the qjackctl window I get tons of these. They seem to be > associated with the tooltips popping up in the main qjackctl window. > > X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a > X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a > X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a > X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a > X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a > X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a > X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a > X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a > X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a > X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a > X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a > X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a > > The latter are especially annoying as they spam the Messages window not > the xterm I launched qjackctl from. > I thought these messages were harmless :/ I also get something like this, always for all (my) Qt apps: X Error: BadDevice, invalid or uninitialized input device 155 Major opcode: 144 Minor opcode: 3 Resource id: 0x0 Failed to open device X Error: BadDevice, invalid or uninitialized input device 155 Major opcode: 144 Minor opcode: 3 Resource id: 0x0 Failed to open device AFAICR this started somewhere since some Qt 3.3.x, don't know really since... Again , I think this is simply noise, but can be hidding something under the sheets :) -- rncbc aka Rui Nuno Capela [EMAIL PROTECTED]
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
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] X Error: BadWindow errors with qjackctl 0.2.15a
Can you log in to the remote system using ssh -Y? This looks like one of the X11Forwarding problems. Jan On Thu, 17 Feb 2005 13:11 , Lee Revell <[EMAIL PROTECTED]> sent: >Every time I start qjackctl from a remote X session I get these errors >at startup. I am using the Cygwin X server. > >X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 2 > Minor opcode: 0 > Resource id: 0x3a >X Error: BadAtom (invalid Atom parameter) 5 > Major opcode: 18 > Minor opcode: 0 > Resource id: 0x134 >X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 2 > Minor opcode: 0 > Resource id: 0x3a >X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 2 > Minor opcode: 0 > Resource id: 0x3a >X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 2 > Minor opcode: 0 > Resource id: 0x3a >X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 7 > Minor opcode: 0 > Resource id: 0x3a >X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 7 > Minor opcode: 0 > Resource id: 0x3a > >Then if I activate the Messages window and move the mouse back and forth >between it and the qjackctl window I get tons of these. They seem to be >associated with the tooltips popping up in the main qjackctl window. > >X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a >X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a >X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a >X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a >X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a >X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a >X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a >X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a >X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a >X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a >X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a >X Error: BadWindow (invalid Window parameter) 3 > Major opcode: 38 > Minor opcode: 0 > Resource id: 0x3a > >The latter are especially annoying as they spam the Messages window not >the xterm I launched qjackctl from. > >Lee
[linux-audio-dev] X Error: BadWindow errors with qjackctl 0.2.15a
Every time I start qjackctl from a remote X session I get these errors at startup. I am using the Cygwin X server. X Error: BadWindow (invalid Window parameter) 3 Major opcode: 2 Minor opcode: 0 Resource id: 0x3a X Error: BadAtom (invalid Atom parameter) 5 Major opcode: 18 Minor opcode: 0 Resource id: 0x134 X Error: BadWindow (invalid Window parameter) 3 Major opcode: 2 Minor opcode: 0 Resource id: 0x3a X Error: BadWindow (invalid Window parameter) 3 Major opcode: 2 Minor opcode: 0 Resource id: 0x3a X Error: BadWindow (invalid Window parameter) 3 Major opcode: 2 Minor opcode: 0 Resource id: 0x3a X Error: BadWindow (invalid Window parameter) 3 Major opcode: 7 Minor opcode: 0 Resource id: 0x3a X Error: BadWindow (invalid Window parameter) 3 Major opcode: 7 Minor opcode: 0 Resource id: 0x3a Then if I activate the Messages window and move the mouse back and forth between it and the qjackctl window I get tons of these. They seem to be associated with the tooltips popping up in the main qjackctl window. X Error: BadWindow (invalid Window parameter) 3 Major opcode: 38 Minor opcode: 0 Resource id: 0x3a X Error: BadWindow (invalid Window parameter) 3 Major opcode: 38 Minor opcode: 0 Resource id: 0x3a X Error: BadWindow (invalid Window parameter) 3 Major opcode: 38 Minor opcode: 0 Resource id: 0x3a X Error: BadWindow (invalid Window parameter) 3 Major opcode: 38 Minor opcode: 0 Resource id: 0x3a X Error: BadWindow (invalid Window parameter) 3 Major opcode: 38 Minor opcode: 0 Resource id: 0x3a X Error: BadWindow (invalid Window parameter) 3 Major opcode: 38 Minor opcode: 0 Resource id: 0x3a X Error: BadWindow (invalid Window parameter) 3 Major opcode: 38 Minor opcode: 0 Resource id: 0x3a X Error: BadWindow (invalid Window parameter) 3 Major opcode: 38 Minor opcode: 0 Resource id: 0x3a X Error: BadWindow (invalid Window parameter) 3 Major opcode: 38 Minor opcode: 0 Resource id: 0x3a X Error: BadWindow (invalid Window parameter) 3 Major opcode: 38 Minor opcode: 0 Resource id: 0x3a X Error: BadWindow (invalid Window parameter) 3 Major opcode: 38 Minor opcode: 0 Resource id: 0x3a X Error: BadWindow (invalid Window parameter) 3 Major opcode: 38 Minor opcode: 0 Resource id: 0x3a The latter are especially annoying as they spam the Messages window not the xterm I launched qjackctl from. Lee
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 16:44 +, mimo wrote: > No, happened with rme96 at 44.1kHz -- will try to reproduce tonight and > send you details. > OK. Make sure to copy the list (and probably alsa-user), because I'm not an RME expert at all. Lee
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, 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
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, 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, 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
Le 17 févr. 05, à 16:16, Alfons Adriaensen a écrit : 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 Yes, this is currently done like that in jackdmp 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, I think it depends of what is important: a "more" robust system with one extra buffer latency or the current model. I will make both options available in jackdmp. 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. Hum I'm not sure asynchronous interface is needed. In my implementation graph state changes are "seen" by the audio thread the next cycle, but since all calls that change the graph state are serialized by the server, clients always see a coherent state. 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
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
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
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
>> 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
>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
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
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
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
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
James McDermott wrote: 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... ..want to go into more detail? 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? hmm..., maybe you right. I had something working about 2 years ago -- then called muzz :) -- and that spent most of it's time doing that tree thingy. But it was probably a bad way of doing it in general.. there is alos this thing about inputs and outputs or more general connectors and how to handle the logics behind them.. 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
>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
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
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
> 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, 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
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
it all sounds a lot like Beast to me ... http://beast.gtk.org/ --p
Re: [linux-audio-dev] mux concept paper
On Thu, Feb 17, 2005 at 11:43:44 +, mimo wrote: > >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. Such as DSSI? http://dssi.sf.net - Steve
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
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.
