Hey all,
Just wondering, how can I hear the output of two seperate channels in
Rosegarden? For example, in the case of an upper and lower manual of the
aeolus organ?
I can only seem to hear one channel, and both keyboards are listening to
that one channel, even changing channels on my controllers doesn't work.
I'm running rosegarden 1.7.3 and the latest version of aeolus.
Thanks,
Andrew Coughlan
I'm on Debian testing nicely tweaked (a.k.a. AVLinux), which means all
sound is pure direct ALSA, except when I turn on Jack and run something
explicitly through it. The question is: Is there any reason why I
should not be running all audio through Jack? I heard that through
.asoundrc one can achieve this quite easily, and it strikes me as a way
to speed up the process of setup for a gig, unless there are downsides I
don't understand?
J.E.B.
Hi All + Jakob,
I am moving this conversation onto this list as other people may be
interested in this topic. I have just run Jakob alsa-midi-latency-test
on my pc Ubuntu 8.10 (intrepid) with the standard kernel
2.6.27-14-generic and get these results pasted below. I feel that this
program is important because it measures the real-time performance of
the OS and the midi hardware and hopefully it will encourage main
stream distributions to improve the out of the box real-time
performance. Unfortunately this program says that this test failed on
my setup (I am using the Edirol UM-2EX USB MIDI interface but Jakob
benchmark results for the UM-2EX has a worst latency of 2.15 ms which
is great) The results are MUCH better than on my old Xandros eeepc
701(also results below) which I am using until my faulty eeepc 901A
returns from repair.
I have a particular interested in this as I am the author of
PianoBooster which is aimed at novices as well as advanced pianists
and I hope that real-time performance will be improved on future on
mainstream standard Linux distributions without requiring lots of
tweaks. Maybe we could use this program to test beta distributions to
ensure that out of the box real-time performance was up to scratch. I
am also planning to use this program to improve the performance of
PianoBooster which I know suffers from a number of timing issues. In
the meantime what results do you get on your hardware and on your
setup?
./alsa-midi-latency-test -o 24:0 -i 24:0 -R -w 1 -r
sched_setscheduler: Operation not permitted
> set_realtime_priority(SCHED_FIFO, 99).. done.
> clock resolution: 0.000000001 s
> interval between measurements: 1.000 .. 2.000 ms
> sampling 10000 midi latency values - please wait ...
> press Ctrl+C to abort test
sample; latency_ms; latency_ms_worst
0; 3.69; 3.69
1; 3.80; 3.80
5; 4.82; 4.82
107; 6.17; 6.17
238; 6.30; 6.30
496; 6.52; 6.52
4712; 6.79; 6.79
8429; 6.82; 6.82
9999; 3.74; 6.82
> done.
> latency distribution:
...
3.0 - 3.1 ms: 12 #
3.1 - 3.2 ms: 921 #############################################
3.2 - 3.3 ms: 961 ###############################################
3.3 - 3.4 ms: 969 ###############################################
3.4 - 3.5 ms: 994 #################################################
3.5 - 3.6 ms: 948 ##############################################
3.6 - 3.7 ms: 944 ##############################################
3.7 - 3.8 ms: 944 ##############################################
3.8 - 3.9 ms: 1022 ##################################################
3.9 - 4.0 ms: 981 ################################################
4.0 - 4.1 ms: 966 ###############################################
4.1 - 4.2 ms: 137 #######
4.2 - 4.3 ms: 22 #
4.3 - 4.4 ms: 18 #
4.4 - 4.5 ms: 22 #
4.5 - 4.6 ms: 14 #
4.6 - 4.7 ms: 10 #
4.7 - 4.8 ms: 11 #
4.8 - 4.9 ms: 16 #
4.9 - 5.0 ms: 7 #
5.0 - 5.1 ms: 9 #
5.1 - 5.2 ms: 14 #
5.2 - 5.3 ms: 9 #
5.3 - 5.4 ms: 3 #
5.4 - 5.5 ms: 7 #
5.5 - 5.6 ms: 5 #
5.6 - 5.7 ms: 4 #
5.7 - 5.8 ms: 4 #
5.8 - 5.9 ms: 6 #
5.9 - 6.0 ms: 3 #
...
6.1 - 6.2 ms: 2 #
6.2 - 6.3 ms: 7 #
6.3 - 6.4 ms: 2 #
...
6.5 - 6.6 ms: 1 #
...
6.7 - 6.8 ms: 3 #
6.8 - 6.9 ms: 2 #
> FAIL
best latency was 3.04 ms
worst latency was 6.82 ms, which is too much. Please check:
- if your hardware uses shared IRQs - `watch -n 1 cat /proc/interrupts`
while running this test to see, which IRQs the OS is using for
your midi hardware,
- if you're running this test on a realtime OS - `uname -a` should
contain '-rt',
- your OS' scheduling priorities - `chrt -p [pidof process name|IRQ-?]`.
Have a look at
http://www.linuxaudio.org/mailarchive/lat/
to find out, howto fix issues with high midi latencies.
---------- Forwarded message ----------
From: Jakob Flierl <jakob.flierl(a)gmail.com>
Date: Thu, Oct 15, 2009 at 11:53 PM
Subject: Re: [LAA] Second version of alsa-midi-latency-test released (v0.0.2)
To: "Louis B." <louisjbarman(a)googlemail.com>
Hi Louis,
thanks for testing!
The latency values are too big. Which kernel `uname -a` are you running?
Can you re-run alsa-midi-latency-test with the options "-R -w 1 -r"
and re-send me the results? This will turn on realtime scheduling for
the application and make a more "realistic" benchmark.
Kind regards,
Jakob
On Fri, Oct 16, 2009 at 12:44 AM, Louis B. <louisjbarman(a)googlemail.com> wrote:
> Wow Thanks that is really useful see my results below. I always new
> the EEEPC 701 was bad but now I can measure how bad it really is. My
> replacement EEEPC 901A has gone back for repair.
>
> I now want to sent it through PianoBooster It should work using the
> midi through to link the two programs together and the midi cable to
> comlete the loop (pb in Midi through:0 out UM:2 cable UM:2 out to UM:1
> in ./alsa-midi-latency-test -o 14:0 -i 20:0)
>
> src> ./alsa-midi-latency-test -l
> Port Client name Port name
> 14:0 Midi Through Midi Through Port-0
> 20:0 UM-2 UM-2 MIDI 1
> 20:1 UM-2 UM-2 MIDI 2
>
>
> I have tried but PB translates the MIDI input messages (ie the
> pianist piano input onto midi channel one.
>
> I need to try this on good hardware.
>
>
> Thanks
>
> Louis
>
>
>> alsa-midi-latency-test 0.0.3
>> clock resolution: 0.010000000 s
> WARNING: You do not have a high-resolution clock!
>
>> sampling 10000 midi latency values - please wait ...
>> press Ctrl+C to abort test
>
> sample; latency_ms; latency_ms_worst
> 0; 3.16; 3.16
> 8; 7.38; 7.38
> 182; 30.50; 30.50
> 2666; 99.98; 99.98
> 9999; 1.95; 99.98
>> done.
>
>> latency distribution:
> ...
> 1.2 - 1.3 ms: 58 #
> 1.3 - 1.4 ms: 127 #
> 1.4 - 1.5 ms: 134 #
> 1.5 - 1.6 ms: 128 #
> 1.6 - 1.7 ms: 120 #
> 1.7 - 1.8 ms: 143 #
> 1.8 - 1.9 ms: 135 #
> 1.9 - 2.0 ms: 623 ####
> 2.0 - 2.1 ms: 7086 ##################################################
> 2.1 - 2.2 ms: 135 #
> 2.2 - 2.3 ms: 133 #
> 2.3 - 2.4 ms: 99 #
> 2.4 - 2.5 ms: 92 #
> 2.5 - 2.6 ms: 74 #
> 2.6 - 2.7 ms: 94 #
> 2.7 - 2.8 ms: 64 #
> 2.8 - 2.9 ms: 52 #
> 2.9 - 3.0 ms: 56 #
> 3.0 - 3.1 ms: 242 ##
> 3.1 - 3.2 ms: 20 #
> 3.2 - 3.3 ms: 28 #
> 3.3 - 3.4 ms: 32 #
> 3.4 - 3.5 ms: 33 #
> 3.5 - 3.6 ms: 37 #
> 3.6 - 3.7 ms: 37 #
> 3.7 - 3.8 ms: 34 #
> 3.8 - 3.9 ms: 27 #
> 3.9 - 4.0 ms: 26 #
> 4.0 - 4.1 ms: 20 #
> 4.1 - 4.2 ms: 16 #
> 4.2 - 4.3 ms: 11 #
> 4.3 - 4.4 ms: 8 #
> 4.4 - 4.5 ms: 4 #
> 4.5 - 4.6 ms: 12 #
> 4.6 - 4.7 ms: 9 #
> 4.7 - 4.8 ms: 3 #
> 4.8 - 4.9 ms: 3 #
> 4.9 - 5.0 ms: 2 #
> 5.0 - 5.1 ms: 2 #
> 5.1 - 5.2 ms: 3 #
> 5.2 - 5.3 ms: 1 #
> 5.3 - 5.4 ms: 2 #
> 5.4 - 5.5 ms: 1 #
> 5.5 - 5.6 ms: 1 #
> 5.6 - 5.7 ms: 1 #
> ...
> 5.8 - 5.9 ms: 1 #
> ...
> 7.4 - 7.5 ms: 1 #
> ...
> 11.5 - 11.6 ms: 1 #
> ...
> 12.7 - 12.8 ms: 1 #
> ...
> 13.0 - 13.1 ms: 1 #
> ...
> 13.6 - 13.7 ms: 1 #
> ...
> 14.3 - 14.4 ms: 1 #
> ...
> 14.7 - 14.8 ms: 1 #
> ...
> 26.3 - 26.4 ms: 1 #
> ...
> 26.5 - 26.6 ms: 2 #
> 26.6 - 26.7 ms: 1 #
> ...
> 27.4 - 27.5 ms: 1 #
> ...
> 27.8 - 27.9 ms: 2 #
> ...
> 28.2 - 28.3 ms: 2 #
> 28.3 - 28.4 ms: 1 #
> ...
> 28.5 - 28.6 ms: 1 #
> ...
> 28.9 - 29.0 ms: 2 #
> ...
> 29.2 - 29.3 ms: 1 #
> ...
> 29.5 - 29.6 ms: 1 #
> ...
> 29.8 - 29.9 ms: 3 #
> ...
> 30.1 - 30.2 ms: 1 #
> 30.2 - 30.3 ms: 1 #
> ...
> 30.5 - 30.6 ms: 1 #
> ...
> 59.7 - 59.8 ms: 1 #
> ...
> 60.0 - 60.1 ms: 1 #
> ...
> 99.9 -100.0 ms: 1 #
>
>> FAIL
>
> best latency was 1.16 ms
> worst latency was 99.98 ms, which is too much. Please check:
>
> - if your hardware uses shared IRQs - `watch -n 1 cat /proc/interrupts`
> while running this test to see, which IRQs the OS is using for
> your midi hardware,
>
> - if you're running this test on a realtime OS - `uname -a` should
> contain '-rt',
>
> - your OS' scheduling priorities - `chrt -p [pidof process name|IRQ-?]`.
>
> Have a look at
> http://www.linuxaudio.org/mailarchive/lat/
> to find out, howto fix issues with high midi latencies.
>
> src>
>
0.016 Alsa audio bug fixes, plus fixed an issue with potential to corrupt
~/.zynaddsubfxXML.cfg on saving settings. On start up, it now tries to
load settings from ~/.yoshimiXML.cfg. If it can't find that it tries
~/.zynaddsubfxXML.cfg. On exit it now writes settings to ~/.yoshimiXML.cfg
<http://www.graggrag.com/?q=node/19> As always, be careful out there.
cheers, Cal
>that website doesn't work too well for me (and no way i'm going to
>register). good an old-school download link somewhere?
sorry, wasn't aware of that, will try to find a different place for storing the files asap, any hint is welcome
best
s
--
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
Hi all,
There are six new BASES for the Gigsaw.
Indeed all the previous Gigsaw's patterns are definitively
rewritten to suit of the new version.
You'll find Country, Dance-Disco-Techno, Hip-hop and more..., Reggae,
Jazz and Rock BASES at:
(Look at the left panel and download what you like.)
http://philippe.hezaine.free.fr/spip.php?article46
I'm going to begin updates and new bases.
Have fun.
--
Phil.
Superbonus-Project (Site principal) <http://superbonus.project.free.fr>
Superbonus-Project (Plate-forme d'échange):
<http://philippe.hezaine.free.fr>
I am stumped myself. Copying Robin and conference organizers on this one.
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Assistant Co-Director, CCTAD
CHCI, CS, and Art (by courtesy)
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-6139
(540) 231-5034 (fax)
ico(a)vt.edu
http://www.music.vt.edu/faculty/bukvic/
_____
From: linux-audio-dev-bounces(a)lists.linuxaudio.org
[mailto:linux-audio-dev-bounces@lists.linuxaudio.org] On Behalf Of victor
Sent: Tuesday, October 13, 2009 1:54 PM
To: The Linux Audio Developers' Mailing List
Subject: [LAD] Next year's LAC
... seems to have been announced. I got an email from ICMA about it.
Why was it not announced here or in the Consortium list? I would
have thought these are the main places where you find good interest.
Any further news?
Victor
Here's a story that may give you all a good chuckle:
Last weekend Robin Gareus, our LAO guru has contacted me inquiring why there
was a ~1hr linuxaudio.org server downtime that took place that Sat. morning.
Luckily we now have an UPS that gives us almost 2 hours of offline power.
Hence, the server went through this unscathed. Yet, the network
infrastructure was also down so even though the server remained up, there
was no way of reaching it.
So, I went investigating what happened, and this is the reply I got from our
on-campus support:
Squirrel fried in transformer. Campus and part of downtown was out of power
on Saturday morning before the game. [this was a football game we had in
town that day with 10K+ visitors]
:-)
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Assistant Co-Director, CCTAD
CHCI, CS, and Art (by courtesy)
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-6139
(540) 231-5034 (fax)
ico(a)vt.edu
http://www.music.vt.edu/faculty/bukvic/