No firewire here. I once had a MOTU, but I guess that there isn't a
driver for Linux and the guy who lend me the MOTU + Mac was Dirk Brauner
who isn't a friend anymore. I guess the MOTO was audio only. The people
who are still my friends don't have much different equipment, but I've
got. Always Envy24 based PCI, one friend has just more IOs for his
Envy24 based PCI card.
> Make sure that the MIDI device is being triggered before the soft
> synth before you post to LAD. If it ends up being the case, then go
> ahead and post it on LAD.
You're right I was stupid to spread to much speculations.
And yes, regarding to your knowledge you should join LAD.
- Ralf
On Wed, 2010-07-14 at 14:12 -0700, Devin Anderson wrote:
> On Wed, Jul 14, 2010 at 12:43 PM, Ralf Mardorf
> <ralf.mardorf(a)alice-dsl.net> wrote:
> > On Wed, 2010-07-14 at 12:30 -0700, Devin Anderson wrote:
> >> On Wed, Jul 14, 2010 at 10:29 AM, Ralf Mardorf
> >> <ralf.mardorf(a)alice-dsl.net> wrote:
> >>
> >> > Hi :)
> >> >
> >> > delayed by a thunder-storm I could do another test.
> >> > --snip--
> >>
> >> So, what you're saying is that your MIDI device and software synth
> >> sync up less and less as you raise the period size.
> >
> > Yes :).
> >
> >> I had presupposed
> >> before that your MIDI device was triggering *after* your software
> >> synth, but it occurs to me that it might be the other way around. Do
> >> you hear the audio from your software synth first, or from your MIDI
> >> device?
> >
> > I can't say it today, now I do some office work. I had the impression
> > that it might vary. Sometimes the virtual drum sampler and sometimes the
> > standalone drum sampler was played earlier, I need to check this ASAP.
> > For older tests with my USB MIDI device it was exactly that way, that
> > jitter had positive and negative delay. At least the recorded waveforms
> > of external MIDI equipment (when I used USB MIDI, now I'm using PCI
> > MIDI), were recorded by Qtractor, before theoretically the MIDI event
> > was send ;). Note! Qtractor had no latency compensation, all recorded
> > audio of external MIDI instruments should have (positive) delay, but
> > negative delay.
>
> If it ends up being the case that your MIDI device is being triggered
> before your software synth, then I'm guessing that the issue here is
> not MIDI jitter. I'm guessing the issue is that the latency that's
> imposed by JACK on incoming and outgoing audio is not imposed on
> incoming and outgoing ALSA MIDI. So, while the audio coming out of
> the software synth is delayed by a certain amount of frames imposed by
> JACK, the audio coming out of your MIDI device is only delayed by the
> latency of the ALSA drivers, the latency of the MIDI ports, the
> latency of your MIDI device.
>
> This would certainly explain why the problem gets worse as you raise
> the period size, and could explain why you had positive and negative
> delay in your older USB MIDI tests, as the reported MIDI jitter in
> your tests was *far* worse in your older tests than it is now.
>
> At the moment, I happen to be doing some work in JACK 2 that could
> potentially solve this issue by enabling MIDI to sync more closely
> with audio, so I'm very curious to know if my suspicions are correct.
> Please keep me updated. :)
Should I build JACK dummy packages for 64 Studio and daily get JACK2
from svn co http://subversion.jackaudio.org/jack/jack2/trunk/jackmp ?
I wonder if this should be cross-posted to LAD?
On LAD and the 64 Studio list are people with much knowledge and your
reply might hit the nail on the head.
- Ralf
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
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
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/
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
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.
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
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.
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