Linux-audio-dev July 2010

linux-audio-dev@lists.linuxaudio.org

69 participants
72 discussions

Re: [LAD] ALSA MIDI latency test results are far away from reality

by Robin Gareus

On 07/14/2010 06:31 PM, Nedko Arnaudov wrote: > Robin Gareus <robin-+VlDMftONaMdnm+yROfE0A(a)public.gmane.org> writes: > >> I was hinting that the audible midi-jitter could be a result of >> midi-messages getting 'quantizied' to jack-periods. >> >> A JACK-MIDI app which does not honor 'jack_midi_event_t->time' but >> simply processes all queued midi-events on each jack_process_callback() >> will result in the symptoms you describe (snare & kick on the same >> beat). One example of such an app is "a2j". > > What version? release-4 - the latest on svn://svn.gna.org/svn/a2jmidid > I can clearly see code that handles this in the current > version. It is in jack.c, a2j_alsa_output_thread(), lines 385-411 I've just seen that there's git://repo.or.cz/a2jmidid.git and jumped from release-4 to release-6. ciao, robin -- Robin Gareus mail: robin(a)gareus.org site: http://gareus.org/ chat: xmpp:rgareus@ik.nu blog: http://rg42.org/ lab : http://citu.fr/ Public Key at http://pgp.mit.edu/ Fingerprint : 7107 840B 4DC9 C948 076D 6359 7955 24F1 4F95 2B42

13 years, 9 months

Correlation of alsa -p value and hw MIDI jitter

by Ralf Mardorf

Hi :) delayed by a thunder-storm I could do another test. 64 Studio 3.3 alpha (= Ubuntu Karmic) amd64 LXDE, poff dsl-provider, cpufreq-selector -g performance, chgrp audio /dev/hpet, sysctl -w dev.hpet.max-user-freq=64, modprobe snd-hrtimer Qtractor + HR timer playing FluidSynth DSSI drums and a standalone MIDI drum module in unison. $ jackd -Rch -dalsa -dhw:0 -r96000 -p16 -n2 FluidSynth DSSI and the hardware MIDI drum module are playing in unison. $ jackd -Rch -dalsa -dhw:0 -r96000 -p512 -n2 Borderline, not out of timing, but not fine and already critical. $ jackd -Rch -dalsa -dhw:0 -r96000 -p256 -n2 Borderline, not out of timing, but not fine. $ jackd -Rch -dalsa -dhw:0 -r96000 -p128 -n2 Borderline, not out of timing, but not fine. $ jackd -Rch -dalsa -dhw:0 -r96000 -p64 -n2 Borderline, not out of timing, but not fine. $ jackd -Rch -dalsa -dhw:0 -r96000 -p32 -n2 It here might become usable. $ jackd -Rch -dalsa -dhw:0 -r96000 -p16 -n2 Yes, for this test the problem at -p32 and -p16 is, that because of phasing the kick become randomly very loud. It seems not to depend on the sounds, but jitter, anyway I can't say this for sure, some sounds can't be played in unison, even if there won't be jitter. Values >= -p64 result in ... I need to hear it again ... $ jackd -Rch -dalsa -dhw:0 -r96000 -p64 -n2 ... 'in unison' becomes a little bit of an early reflection like effect, but a very, very short delayed early reflection, still more a fluctuating phasing. $ jackd -Rch -dalsa -dhw:0 -r96000 -p1024 -n2 Completely out of sync, bad timing. Unusable. I guess even with -p16 one should record all drums and the bass at the same time, but recording every instrument one after another. This could be possible even for -p512, but MIDI is completely out of timing at -p1024, note, at 96KHz. Short attacked percussive sounds shouldn't be played in unison. For some usage PCI MIDI seems to be okay on my machine, but it's not comparable to an Atari ST and SMPTE sync to a 4-track cassette recorder or even to a C64 and click sync to a 4-track cassette recorder. PCI MIDI still has to much jitter for a straight timing, that enables to record one instrument after the other in perfect sync. I guess as long as I could keep -p256 and I won't be able to do a lot without increasing this value, hw MIDI could be usable for very simple music, when the whole MIDI backing is recorded at the same time, but one after the other instrument. - Ralf

13 years, 9 months

[ANN] Drumstick 0.4.1 released

by Pedro Lopez-Cabanillas

Drumstick is a C++ wrapper around the ALSA library sequencer interface using Qt4 objects, idioms and style. ALSA sequencer provides software support for MIDI technology on Linux. Complementary classes for SMF and WRK file processing are also included. This library is used in KMetronome, KMidimon and KMid2, and was formerly known as "aseqmm". Changes: * Removed the precompiled headers build option * Fixed a bug that affected users running dumstick-based applications with realtime priority enabled. There is a related problem in glib-2.22 that has not yet been fixed (https://bugzilla.gnome.org/show_bug.cgi?id=599079). This issue prevented to execute FluidSynth from inside KMid at startup in those affected systems. Copyright (C) 2009-2010, Pedro Lopez-Cabanillas License: GPL v2 or later Project web site http://sourceforge.net/projects/drumstick Online documentation http://drumstick.sourceforge.net/docs/ Downloads http://sourceforge.net/projects/drumstick/files/0.4.1/

13 years, 9 months

meta issue tracker idea

by Philipp

Hi, this is all about making Linux Audio more useful. The idea came about because on the one hand there are parts of Linux audio that really need some coders attention and on the other hand there are coders who don't know where to start. I realize that there never are more than enough coders, so this is mainly about bringing attention to the parts that need it the most. To a degree it's what bug/feature trackers are there for, but those are usually per application, and while there are category and priority systems in place those are rarely used. So what this is also about is bridging a gap between users, developers and between applications. It would be quite simple really. An easy to find, central place, possibly a wiki or a tracker. Anyone, a user most likely, describes his workflow and what the showstopper is. This could be applications not syncing properly, or an essential but missing feature. The idea is to tackle mainly infrastructure and cross application problems, with the goal to make a workflow actually work. The user should have to specify all relevant information available, such as version information, links, probably some kind of priority or urgency indication and how hard he believes it would be. He could also put up a reward of sorts, not necessarily monetary. Any developer could pick up the task and work on it, possibly leaving a notice. The possible benefits I see are: a) A kind of overview of what's needed the most, one place where you can see what's actually important to users. b) A way to identify and fix problems between applications - something I believe is very important for a system that encourages the use of multiple applications at once. I believe there are numerous synchronisation/transport issues for example which are never really tackled, despite this being a very important part of the infrastructure. c) Emphasis on actual workflow and usability. d) It would work for any program, even those without tracker and those that aren't high profile and aren't usually in the center of attention. Could this work? What do you think? -- Regards, Philipp -- "Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan

13 years, 9 months

Is anyone using monobristol 0.60.1?

by Mike Cookson

I am using KX Studio. Latest Mono version is 2.4.4 from SVN, though the latest version is 2.6.4. Latest monobristol version from repository, 0.40.5, works, but bristol version there is 0.60.1. I compiled latest monobristol (0.60.1) with defaults and installed to /usr/local. It worked when launched from terminal, but failed to start from fbrun and gmrun and cairo-dock. KDE menu and kwin run dialog started old 0.40.5 version, though its command string is simply "monobristol". When I reinstalled it to /usr, it failed to start even from terminal. When it fails, it gives this error: Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object at MainWindow..ctor () [0x00000] at monoBristol.MainClass.Main (System.String[] args) [0x00000] I searched in web and found it like a mono bug, but I am unsure. I need to be checked by developers before reporting.

13 years, 10 months

PCI MIDI jitter - comparison Ubuntu (bad) and Suse (might be ok)

by Ralf Mardorf

Hi :) today I compared a default Ubuntu Studio with and without the proprietary NVIDIA driver. Note that for Ubuntu Studio 2 tests failed because of time out errors, but even the tests that were passed with success are significantly less good, than the tests with openSUSE, were I set up audio myself. Ubuntu based Linux until now were my music Linux, e.g 64 Studio 3.0 and 3.3, but I wonder if bad MIDI latency is depending to Ubuntu. For Ubuntu Studio even PCI MIDI has got more jitter, but USB MIDI for Suse, see older test in the archives. What might be the difference between Ubuntu and Suse? Could anybody compare different distros too? ------------------------------------------------------------------------ Ubuntu Studio 10.04 amd64 2 x Terratec EWX 24/96 (2 single cards, but 1 virtual card) Frequency scaling ? ------------------------------------------------------------------------ spinymouse@ubuntu:~$ hwinfo --gfxcard Driver: "nouveau" Driver Modules: "drm" IRQ: 18 spinymouse@ubuntu:~$ alsa-midi-latency-test -l Port Client name Port name 14:0 Midi Through Midi Through Port-0 16:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI 20:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI 128:0 TiMidity TiMidity port 0 128:1 TiMidity TiMidity port 1 128:2 TiMidity TiMidity port 2 128:3 TiMidity TiMidity port 3 spinymouse@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o20:0 -i20:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 1.00 ms worst latency was 1.97 ms, which is great. spinymouse@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o20:0 -i20:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 1.00 ms worst latency was 3.36 ms, which is great. spinymouse@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o16:0 -i16:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 0.99 ms worst latency was 1.93 ms, which is great. spinymouse@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o16:0 -i16:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 0.99 ms worst latency was 1.74 ms, which is great. spinymouse@ubuntu:~$ uname -a Linux ubuntu 2.6.32-23-preempt #37-Ubuntu SMP PREEMPT Fri Jun 11 10:19:07 UTC 2010 x86_64 GNU/Linux spinymouse@ubuntu:~$ envy24control 0xcf00, irq 20, Master Clock int 44100 No envy24control for 0xcb00, irq 21, Master Clock ? 20:0 opto S/PDIF out --> 16:00 opto S/PDIF in ------------------------------------------------------------------------ Ubuntu Studio 10.04 amd64 2 x Terratec EWX 24/96 (2 single cards, but 1 virtual card) Frequency scaling ? ------------------------------------------------------------------------ spinymouse@ubuntu:~$ hwinfo --gfxcard Driver: "nvidia" Driver Modules: "nvidia" IRQ: 18 spinymouse@ubuntu:~$ alsa-midi-latency-test -l Port Client name Port name 14:0 Midi Through Midi Through Port-0 16:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI 20:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI 128:0 TiMidity TiMidity port 0 128:1 TiMidity TiMidity port 1 128:2 TiMidity TiMidity port 2 128:3 TiMidity TiMidity port 3 pinymouse@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o20:0 -i20:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 1.00 ms worst latency was 1.84 ms, which is great. spinymouse@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o20:0 -i20:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 1.00 ms worst latency was 1.27 ms, which is great. spinymouse@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o16:0 -i16:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 0.99 ms worst latency was 1.92 ms, which is great. spinymouse@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o16:0 -i16:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 0.99 ms worst latency was 1.72 ms, which is great. spinymouse@ubuntu:~$ uname -a Linux ubuntu 2.6.32-23-preempt #37-Ubuntu SMP PREEMPT Fri Jun 11 10:19:07 UTC 2010 x86_64 GNU/Linux spinymouse@ubuntu:~$ envy24control 0xcf00, irq 20, Master Clock int 44100 No envy24control for 0xcb00, irq 21, Master Clock ? 20:0 opto S/PDIF out --> 16:00 opto S/PDIF in ------------------------------------------------------------------------ openSUSE 11.2 amd64 2 x Terratec EWX 24/96 (2 single cards, but 1 virtual card) Frequency scaling performance ------------------------------------------------------------------------ spinymouse11.2@suse11-2:~> su -c "hwinfo --gfxcard" Driver: "nvidia" Driver Modules: "nvidia" IRQ: 18 spinymouse11.2@suse11-2:~> alsa-midi-latency-test -l Port Client name Port name 14:0 Midi Through Midi Through Port-0 16:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI 24:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI spinymouse11.2@suse11-2:~> alsa-midi-latency-test -l Port Client name Port name 14:0 Midi Through Midi Through Port-0 16:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI 24:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI spinymouse11.2@suse11-2:~> alsa-midi-latency-test -Rrw=2 -o24:0 -i24:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 0.99 ms worst latency was 1.07 ms, which is great. spinymouse11.2@suse11-2:~> alsa-midi-latency-test -Rrw=2 -o24:0 -i24:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 0.99 ms worst latency was 1.08 ms, which is great. spinymouse11.2@suse11-2:~> alsa-midi-latency-test -Rrw=2 -o16:0 -i16:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 0.99 ms worst latency was 1.06 ms, which is great. spinymouse11.2@suse11-2:~> alsa-midi-latency-test -Rrw=2 -o16:0 -i16:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s > SUCCESS best latency was 0.99 ms worst latency was 1.05 ms, which is great. spinymouse11.2@suse11-2:~> uname -a Linux suse11-2 2.6.31.6-rt19 #1 SMP PREEMPT RT Wed Nov 18 16:59:26 CET 2009 x86_64 x86_64 x86_64 GNU/Linux spinymouse11.2@suse11-2:~> envy24control spinymouse@ubuntu:~$ envy24control 0xcf00, irq 20, Master Clock int 44100 No envy24control for 0xcb00, irq 21, Master Clock ? 24:0 opto S/PDIF out --> 16:00 opto S/PDIF in I still have got some tests to do, e.g. a real test by listening to MIDI music and I'll test what happens if two sound cards become one virtual sound card, http://www.jrigg.co.uk/linuxaudio/ice1712multi.html and before doing this I need to test if the second, new second hand card from Ebay isn't broken for audio, resp. I'll compare the sound quality for my old and the new Terratec EWX 24/96 sound card, before they become one virtual sound card. Cheers! Ralf

13 years, 10 months

transport/timebase calculations

by James Morris

Hi, I can't see what's wrong with the calculations I'm performing for timebase/transport in my JACK app. I'm not sure where the error lies. I keep looking and looking at it, changing bits, experimenting, and still not getting the desired result. Everything is playing too slow. For example, @ 120bpm 4/4 time, the second (or third) bar starts almost an entire beat too late. Please could someone take a look at the calculations and see if there's something obviously wrong with them? The source can be viewed online at: http://github.com/jwm-art-net/BoxySeq/blob/master/jack_transport.c The poll function starts at line 169 the jack timebase call back starts at 226. The code was originally based on non-sequencer or dino or some combination of both. It is also a bit grumpy with other JACK apps which use transport, but I trying to fix the time keeping first. TIA, James.

13 years, 10 months

[LAA] [ANN] guitarix-0.10.0 released

by hermann

guitarix is a simple Linux Rock Guitar amplifier and is designed to achieve nice thrash/metal/rock/blues guitar sounds. guitarix uses the Jack Audio Connection Kit as its audio backend and brings to the jack audio graph a mono amplifier input/output port, and a FX mono input with two (stereo) output ports. guitarix provide a jack midi input port to connect a midi controller (midi learn) and a (3 channel) jack midi output port, feed by a (scalable) mix of the tuner and a beat-detector. Release 0.10.0 comes with following changes : * add tonestack models * add 2. amp model * add cabinet impulse response module * add Patch Info widget * add Preset File Load/Export option * add simple looper * add Oscilloscope and tuner state to main settings * selectable distortion model (multi/single line) * selectable EQ model (fixed/scalable freq) * free mem when not used (delay lines) * reworked Gui * fix various bugs have fun _________________________________________________________________________ Note:// for experienced Users there is a Experimental widget witch comes with the tremolo effect contributed by transmogrifox (Rakarrack dev-team) please look ./waf --help for how to build with this widget activated. Many thanks to transmogrifox for his contribution. _________________________________________________________________________ guitarix is licensed under the GPL. Project page with screenshots: http://guitarix.sourceforge.net/ download: http://sourceforge.net/projects/guitarix/ please report bugs and suggestions in our forum here: http://sourceforge.net/apps/phpbb/guitarix/ ________________________________________________________________________ For capture, guitarix uses the great 'jack_capture' (version >= 0.9.30) written by Kjetil S. Matheussen. If you don't have it installed, you can look here: http://old.notam02.no/arkiv/src/?M=D For extra Impulse Responses, guitarix uses the zita-convolver library, and, for up/down sampling we use zita-resampler, both written by Fons Adriaensen. If you don't have it installed, get it here: http://www.kokkinizita.net/linuxaudio/index.html We use the marvellous faust compiler to build the amp and effects and will say thanks to : Julius Smith http://ccrma.stanford.edu/realsimple/faust/ : Albert Graef http://q-lang.sourceforge.net/examples.html#Faust : Yann Orlary http://faust.grame.fr/ ________________________________________________________________________ For faust users : All used Faust dsp files are included in /guitarix/src/faust, the resulting cc files are in /guitarix/src/faust-cc The tools we use to convert (post-processing and plot) the resulting faust cpp files to the needed include format, stay in the /guitarix/tools directory. ________________________________________________________________________ regards Hermann Meyer, James Warden, Andreas Degert

13 years, 10 months

jack2 with session support?

by Jonathan E. Brickman

Is there a jack2 version with session support? J.E.B.

13 years, 10 months

Re: [LAD] [64studio-users] MIDI jitter

by Ralf Mardorf

Ichthyostega wrote: > Ralf Mardorf schrieb: >> Another stupid question induced by an argument regarding to MIDI jitter by >> Daniel James. >> >>> [snip] I'm sceptical that the realtime kernel is the cause of your MIDI >>> problems. If they got this right in the 80's, on computers which could not >>> do anything near realtime audio processing, then I think it's more likely >>> to be a question of MIDI application design. > > At that point we should call back, how that whole story with "realtime" > started. At the begining was a design mismatch. Many things related to > the Linux kernel started out with a kind of "I feel fine" pragmatism. > Which, btw isn't to criticise as it is, because this also accounts > for the freshness and sometime unconventional new approach to some > problems. But with regards to timings, for all of the first decade > of Linux development, there seemed to be a completely different > mental model, which we could summarise as: permormance == throughput, > and timings are only relevant, when you get a network timeout, or > a sluggish response in your application's GUI. > > Thus, if we now consider to use a Linux kernel for making music, we must > assess that the whole design isochronously assumed about 1000 times more > headroom as there really is. > > Thus, as writing a new Kernel doesn't seem to be an option, this whole > tedious undertaking of the "realtime patches" can be described as an > attempt to fix this "problem" (which was never assumed to be a problem > in the initial design) by hunting down one by one each individual instance > where the existing kernel could possibly be reacting too slow. > > Thus, we should rather be surprised, how good these realtime kernels work. > OTOH, is isn't a surprise the machines from the 80s meet these criteria; > their OS software was written with an awareness for a much more limited > processing capability right from start. > > >> Why do people (not only me) report jitter for external MIDI equipment, but I >> couldn't find any report for real-time audio jitter? Resp. what's about async >> and disconnecting clients by JACK? > > Audio and MIDI are two quite different beasts. > Sound is processed in Blocks, where the individual unity (1 Sample) is > much more fine grained and way below anything which can be discerned by > a human ear. Moreover, Sound as such already exists and 'just' has to > be piped through. To the contrary, MIDI consists of events, which > immediately trigger a reaction, which could be that a piece of software > and at the same time a piece of external hardware starts a processing > cycle. You see, thats a completely different situation and thus it's > obvious, why for these two media the same problem causes so different > symptoms. > >> OTOH on Windows audio clients don't disconnect, >> just MIDI jitter is an issue too. > > IIRC, this was a design decision for JACK. It never tries to conceal > any timeout problem, rather it requires its clients to keep up with > a very tight schedule and comply to very strict rules. > > I don't know the MIDI part of Jack well enough to judge, if it was > designed with the same "you're required to comply" policy. And besides, > when the MIDI interface is hooked up via USB, we again face a completely > different situation. USB is a complicated protocol, which multiple > versions and levels and is certainly not designed to get an individual > event transfered reliably with less than 2ms jitter. > There is even the possibility that the USB peers negotiate to use a > lower transfer rate or protocol version transparently, when they > determine the connection can't keep up with the higher speed. > > Cheers > Hermann V. It's said that USB MIDI interfaces should be the better choice. But this explains a lot. Dunno how to read Fons JACK MIDI jitter test, but ... Subject: Re: [LAD] Again MIDI jitter - tested with Fons test applications Date: Sat, 27 Mar 2010 18:26:33 +0100 From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> To: fons(a)kokkinizita.net CC: linux-audio-dev(a)lists.linuxaudio.org References: <4BADBD42.4030505(a)alice-dsl.net> <20100327164326.GD1545@zita2> > Hi Fons :) > > fons(a)kokkinizita.net wrote: > > On Sat, Mar 27, 2010 at 09:09:38AM +0100, Ralf Mardorf wrote: > > > > > >> Regular it shifted between 2395 and 2404, but with a few exceptions, > >> one time 2302, three times 2304, two times 2305 and two time 2494. > >> See attachment. > >> What might cause this exceptions? Could it be access to the RAM by > >> the graphics? Is there something bad because of the IRQs? > >> > >> Regular shift 2404 - 2395 = 9 frames of jitter, exceptional maximal > >> shift 2494 - 2302 = 192 frames of jitter. > >> > >> I guess this does mean ... > >> 5.3 ms / 512 frames = 0.010351562 ms/frame > >> Maximal difference for regular jitter 0.093164062 ms. > >> Maximal difference for exceptional jitter 1.9875 ms. > >> ... am I wrong? > >> > > > > Wrong once or twice, if twice in such a way that the two > > errors cancel out. > > > > First note that the test prints the difference between > > events. That means that e.g. if *one* note is 100 samples > > late you could see 2400 2500 2300 2400. > > > > The '2300' is just because the previous one was late, > > not because this one arrives too early. So you should > > divide the jitter as you measure it by two. > > > > Aha, okay this is plausible. > > > Second, 5.33 ms = 256 frames at 48 kHz. But maybe you > > are using 96 kHz ?? > > > > So you didn't read the attachment ;), yes I did use 96 KHz. > [snip] Subject: Again MIDI jitter - tested with Fons test applications Date: Sat, 27 Mar 2010 09:09:38 +0100 From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> To: Linux Audio Developers <linux-audio-dev(a)lists.linuxaudio.org> > When I once tested it by recording I got this result for ALSA MIDI on > Linux, Cubase runs on Windows on the same machine: > > ||Cubase|HR tmr|System|PCM pl|PCM ca > ------++------+------+------+------+------ > 500.0 || 493.0| 504.9| 505.6| 503.4| 503.2 > 1000.0|| 993.4|1005.4|1005.8|1005.3|1006.4 > 1500.0||1494.5|1503.6|1506.4|1507.4|1507.3 > 2000.0||1994.8|2003.8|2007.2|2007.9|2009.5 > 2500.0||2492.4|2504.1|2504.3|2503.6|2503.2 > 3000.0||2992.9|3006.0|3006.2|3005.9|3007.6 > 3500.0||3493.7|3502.7|3505.4|3506.5|3509.5 > 4000.0||3994.6|4003.1|4003.2|4008.8|4009.9 > msec +/- 0.1 msec > maxDif|| 4.8| 6.0| 7.2| 8.8| 9.9 > minDif|| -2.4| -2.7| -3.2| -3.4| -3.2 > --------------+------+------+------+------ > Jitter|| 2.4| 3.3| 4.0| 5.4| 6.7 > msec +/- 0.2 msec ... as you can see, for Cubase I got this 2ms of jitter. So regarding to your explanation Herman, Windows + ASIO + Cubase does a good job, just the USB interface will limit it, while for Linux there seems to be another issue too, but the USB interface. Btw. Linux HR tmr is a PITA, just System, PCM pl and PCM ca are usable without issues for all Linux apps. What could be the cause that Windows just is limited to the USB interface by 2.4 ms, but Linux comes with 4.0 ms on my machine? Joshua Boyd on LAD wrote: > On Thu, Jun 17, 2010 at 10:37:25AM -0400, Gene Heskett wrote: > >>> At my school we transfered the CAD files per floppy to a DOS box that >>> controlled the CNC machine, guess that's for the same reason, bad rt >>> capabilities of newer OSes and machines. >> The RTAI works pretty well, I can start a job, switch away from that window, >> and talk to the guys on IRC, or browse the web without hurting the job. >> That to me is true multitasking. > > So, that leaves me wondering why no one seems to be trying RTAI for > audio work? Or is someone doing that and I'm just not aware? Today I tried to do so. I tried to run JACK2 with -R switch by user and by sudo, the result was the same as here, when I launched JACK2 without -R switch on 64 Studio 3.0 beta based on Ubuntu Hardy: $ uname -r 2.6.24-16-rtai $ jackd -dalsa -dhw:0 -r96000 -p512 -n2 jackdmp 1.9.3 Copyright 2001-2005 Paul Davis and others. Copyright 2004-2009 Grame. jackdmp comes with ABSOLUTELY NO WARRANTY This is free software, and you are welcome to redistribute it under certain conditions; see the file COPYING for details JACK server starting in non-realtime mode creating alsa driver ... hw:0|hw:0|512|2|96000|0|0|nomon|swmeter|-|32bit control open "hw:0" (No such file or directory) Cannot initialize driver no message buffer overruns JackServer::Open() failed with -1 Failed to start server ALSA seq couldn't start too. I run the EMC2 / HAL latency-test: Servo thread (1.0 ms): max interval 999180 ns, max jitter 10949 ns, last interval 992259 ns Base thread (25.0 us): max interval 34551 ns, max jitter 9640 ns, last interval 24887 ns The same test couldn't be used for my kernel-rt: $ uname -r 2.6.31.12-rt20 $ latency-test insmod: can't read '/usr/realtime-2.6.31.12-rt20/modules/rtai_hal.ko': No such file or directory RTAPI: ERROR: could not open shared memory (errno=2) HAL: ERROR: rtapi init failed halcmd: hal_init() failed: -9 NOTE: 'rtapi' kernel module must be loaded RTAPI: ERROR: could not open shared memory (errno=2) HAL: ERROR: rtapi init failed halcmd: hal_init() failed: -9 NOTE: 'rtapi' kernel module must be loaded RTAPI: ERROR: could not open shared memory (errno=2) HAL: ERROR: rtapi init failed halcmd: hal_init() failed: -9 NOTE: 'rtapi' kernel module must be loaded ERROR: Module hal_lib does not exist in /proc/modules ERROR: Module rtapi does not exist in /proc/modules ERROR: Module rtai_math does not exist in /proc/modules ERROR: Module rtai_sem does not exist in /proc/modules ERROR: Module rtai_fifos does not exist in /proc/modules /usr/bin/emc_module_helper: Invalid usage with args: remove rtai_ksched [snip] ERROR: Module rtai_hal does not exist in /proc/modules Btw. should I commend out the EMC2 memlock when doing audio work again or doesn't have it an impact? $ cat /etc/security/limits.conf | grep memlock # - memlock - max locked-in-memory address space (KB) @audio - memlock unlimited # @audio - memlock 2000000 * hard memlock 20480 #EMC2 Cheers! Ralf PS: What now? It's my second hardware set up. I just bought a new computer a long time ago, because the old computer wasn't ok for Linux too, but I don't have the money to pay for one machine after the other, until I might have good luck. Both machines are 100% stable for Windows, for Linux I also get asyncs + distortion when using JACK2. I didn't test if current JACK1 is ok, or if it would disconnect clients. Don't get me wrong, I never was a private Windows user, it just were installs for testings. I'm using Linux only at home.

13 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev July 2010