FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > 64 Studio > 64 Studio Developer

 
 
LinkBack Thread Tools
 
Old 07-14-2010, 08:07 PM
Ralf Mardorf
 
Default ALSA MIDI latency test results are far away from reality

On Wed, 2010-07-14 at 21:42 +0200, Robin Gareus wrote:
> On 07/14/2010 07:58 PM, Ralf Mardorf wrote:
> > On Wed, 2010-07-14 at 17:30 +0200, Robin Gareus wrote:
> >> On 07/14/2010 04:22 PM, Ralf Mardorf wrote:
> >>> Hi Robin
> >>>
> >>> On Wed, 2010-07-14 at 15:44 +0200, Robin Gareus wrote:
> >>>> On 07/14/2010 03:23 PM, Ralf Mardorf wrote:
> >>>>> [..]
> >>>>> AND IT'S AUDIBLE THAT THERE IS MUCH MORE JITTER BUT 1.1 ms.
> >>>>>
> >>>>> Any hints how to solve this are welcome.
> >>>>
> >>>> Did you try to start jackd with -p64 instead of -p1024
> >>>
> >>> A good argument, because when I made tests in the past for the USB MIDI,
> >>> things become better at >= -p256 (when I had this Windows test install
> >>> latency for the EWX 24/96 audio was less high than for Linux). The
> >>> problem here is, that I need at least -p512 and even than I'm not safe
> >>> regarding to issues for JACK audio, that's why I used -p1024 instead of
> >>> -p512. For a test -p64 should work, but when recording music I would
> >>> need to increase it step by step until a minimum of -p512.
> >>
> >> I'm sorry; don't understand that. Are you getting [audio] x-runs or what
> >> is the problem using -p64 (or even -p32)?
> >
> > Yes there are lapse, even if there should be no messages about xruns.
> >
> >> I was hinting that the audible midi-jitter could be a result of
> >> midi-messages getting 'quantizied' to jack-periods.
> >
> > It seems to be like that. Take a look at my email with the
> > subject:
> > Correlation of alsa -p value and hw
> > MIDI jitter
> >
> >> 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".
>
> It turned out I was using an ancient version of "a2j".
>
> > I did use Qtractor, but had the same issue when using Rosegarden a long
> > time ago. But we are talking about ALSA MIDI to the hardware
> > MIDInterface?!
> Originally i was only talking about JACK-MIDI apps.
>
> >>> IIRC when I did tests for the USB MIDI with -p64 or even -p125 (I'm not
> >>> sure) it theoretically did work, but this isn't a solution, because at
> >>> some point JACK audio will fail.
> >>
> >> How does it fail? x-runs?
> >
> > All kinds of dropouts, even the left and right channel seem to get out
> > of phase. Just running FluidSynth DSSI playing a kick and a rim-shot was
> > without audible failure at -p16, but I'm sure I won't be able to do
> > multi-trach recording with -p16.
> >
> >>
> >> JACKd works quite robust here with the UA25 and FA101 at 64fpp.
> >>
> >>>> using JACK-midi, I've encountered a similar issue with fluidsynth always
> >>>> synchronizing note-start/ends to jack cycles.
> >>>>
> >>>> Simply lowering the frames-per-period got me playing again so I did not
> >>>> check if it's related to JACK-midi or FluidSynth 1.1.1 in general.
> >>>
> >>> At least FluidSynth DSSI (host is Qtractor) is able to play in unison
> >>> with any DSSI or virtual ALSA MIDI and JACK MIDI (-Xseq) synth on my
> >>> machine. Just 'in unison' for virtual synth to hw synth there sometimes
> >>> is more delay, but just an early reflection like effect.
> >>>
> >>> Note! It was hard to groove when I connected the master keyboard to ALSA
> >>> hw MIDI in --> DIRECTLY TO --> ALSA hw MIDI out and this to a 100% ok
> >>> drum module. Directly connecting the master keyboard to the drum module
> >>> there were no issues.
> >>
> >> Aha, by this we can infer that your problem is ALSA or kernel/timing
> >> related.
> >>
> >> To verify this, take everything up from there (eg. qtractor, fluidsynth)
> >> out of the picture for now.
> >>
> >> 1) Use 'amidiplay' to send a some midi-song directly to your
> >> drum-module. -> Is there still audible jitter?
> >
> > On a todo list, but there seems to be a correlation to JACK audio.
>
> The idea is to remove all correlations. Otherwise it's very hard to find
> the problem.
>
> It looks like you're chasing [at least] two different issues:
>
> 1) ALSA / hardware jitter
>
> 2) qtractor/fluidsynth timing/sync
>
>
> Don't even start JACKd. just use 'aplaymidi'.
> or 'ametro' http://perso.wanadoo.es/plcl/ametro/ametro-en.html

There might be another strange behaviour. IIRC when I recorded audio
from external MIDI devices (when I used my USB MIDI in the past), some
waveforms were recorded, before the MIDI event should be played.

I need to test this again.

Btw. I used Qtractor, that didn't had a latency compensation that might
work bad, hence all MIDI events should have (positive) delay, but
negative delay for recordings. When doing the test today I even didn't
notice if always the virtual or the external drum sounds were later or
if it does change, far less that I was able to hear if there was just
delay or negative delay, I didn't record anything and it's hard to hear
those details, it's easier to hear that something isn't in timeing.


>
> >> 2) Do you have a Hardware MIDI Sequencer? Have it play a simple
> >> metronome beat and dump incoming MIDI-messages. See if the timestamps of
> >> each midi-note-on message are identically spaced.
> >
> > C64 and Atari ST are stable, but there are some issues for e.g the
> > monitor. My VGA isn't slow enough for the Atari. I'll try to do it with
> > the broken SM124.
> >
> >> 'aseqdump' (at least version 1.0.22 which I currently use) does not
> >> print timing-info, 'kmidimon' does.
>
> You can also just use 'arecordmidi' and open it later in an editor.
>
>
> And finally:
>
> External-Keyboard or Sequencer -> PC -> External-Synth
>
> Use 'aconnect' or 'aconnectgui' to connect MIDI-in -> MIDI-out.
> There should be some latency but no recognizable jitter.
>
> If these 3 (amidiplay, amidirecord, ALSA midi-thru) do not work as
> expected, all other tests that mix external-hardware and software will
> be [more or less] useless.

ALSA MIDI thru definitive has audible latency. I played live testing
this. I can't say if it was stable latency or jitter.

Do you know the psychological effect, when you try to sing, while you
just can here your vocals with much delay?
You will lose timing.

amidiplay can play MIDI files for two MIDI channels? Note! It's not easy
to notice this jitter, when there isn't a reference, e.g. you try to
groove live or a bass by a software synth should be in sync with
external drums. Just listening to one source with jitter just works for
a short time, than you become unable for hours to notice a bad timing.
But you always will notice this issues for real work, e.g. when first
recording an external bass and than recording the external bass drum
etc..

>
>
> >>> I need to do something else now, but I take time off. From Friday
> >>> (perhaps earlier) until next Sunday noon I could spend the whole days
> >>> for this MIDI issue only.
> >>>
> >>> Resume:
> >>>
> >>> I assume that -p64 would solve this 'looooooong early reflection like
> >>> effect/async', but then hard disk recording will become impossible.
> >>>
> >>> The target is, that Linux at least replace the Atari ST as sequencer +
> >>> an analog 4-Track machine synced by SMPTE. With -p64 4-track recoding
> >>> would become impossible.
> >>
> >> I'm pretty sure that you can get a stable 64fpp setup, but one thing at
> >> a time. let's keep this thread to MIDI just now.
> >
> > Thank you for your effort .
> >
> >>
> >>> 'Read you later' today or at the latest on Friday.
> >>
> >> enjoy a good long week-end.
> >
> > Have a nice weekend too.
>
> I wish I could.
> It's only just Wednesday here, even though it's Bastille day.

Here it's Wednesday too ... when I said I've got time from Friday to
Sunday for Linux only, I was talking about the da after tomorrow .

Btw. I assume that the max. time difference on earth won't be days .

A thunder-storm put a spoke in my wheel .. I shouldn't be online now .

Cheers!

Ralf

>
> > I'll spend the weekend for Linux audio.
> >
> >>
> >>> Cheers!
> >>>
> >>> Ralf
> >>
> >> ciao,
> >> robin
> >
> > Cheers!
> >
> > Ralf
> >


_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel
 
Old 07-14-2010, 08:16 PM
Ralf Mardorf
 
Default ALSA MIDI latency test results are far away from reality

On Wed, 2010-07-14 at 21:45 +0200, Robin Gareus wrote:
> On 07/14/2010 03:23 PM, Ralf Mardorf wrote:
>
> [..]
> > $ su -c "chgrp audio /dev/hpet"
> Its also writable for the group, right?
>
> > $ su -c "sysctl -w dev.hpet.max-user-freq=64"
>
> Documentation on this value is hard to come by, but I think it's unit is
> Hz. So you'll want

Yep . I've got no idea what would be better a high or a low value, but
at least 64 when using HR timer was better than using the regular timer.
Unfortunately not many apps are able to run, when HR timer is used.
Usage of HR timer can freeze the system, e.g. Rosegarden does this on my
machine. I also need to start 'qtractor filename'. If I first start
Qtractor and than try to load a session, here are issues because HR
timer already is captured.

I guess one would be more flexible, if not using HR timer. I didn't
tested if there will be a difference when using the PCI MIDI. I'll do
this also ASAP. As I mentioned before, for USB MIDI there is a big
difference.

No thunder, no storm anymore, but there was a rainbow some minutes
ago

- Ralf

> su -c "sysctl -w dev.hpet.max-user-freq=1024"
> or even more
>
> try:
> echo 2048 | sudo tee /sys/class/rtc/rtc0/max_user_freq
> echo 2048 | sudo tee /proc/sys/dev/hpet/max-user-freq
>
> [..]
> ciao,
> robin
>
>


_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel
 
Old 07-14-2010, 08:24 PM
Ralf Mardorf
 
Default ALSA MIDI latency test results are far away from reality

On Wed, 2010-07-14 at 22:16 +0200, Ralf Mardorf wrote:
> On Wed, 2010-07-14 at 21:45 +0200, Robin Gareus wrote:
> > On 07/14/2010 03:23 PM, Ralf Mardorf wrote:
> >
> > [..]
> > > $ su -c "chgrp audio /dev/hpet"
> > Its also writable for the group, right?
> >
> > > $ su -c "sysctl -w dev.hpet.max-user-freq=64"
> >
> > Documentation on this value is hard to come by, but I think it's unit is
> > Hz. So you'll want
>
> Yep . I've got no idea what would be better a high or a low value, but
> at least 64 when using HR timer was better than using the regular timer.
> Unfortunately not many apps are able to run, when HR timer is used.
> Usage of HR timer can freeze the system, e.g. Rosegarden does this on my
> machine. I also need to start 'qtractor filename'. If I first start
> Qtractor and than try to load a session, here are issues because HR
> timer already is captured.
>
> I guess one would be more flexible, if not using HR timer. I didn't
> tested if there will be a difference when using the PCI MIDI. I'll do
> this also ASAP. As I mentioned before, for USB MIDI there is a big
> difference.
>
> No thunder, no storm anymore, but there was a rainbow some minutes
> ago
>
> - Ralf
>
> > su -c "sysctl -w dev.hpet.max-user-freq=1024"
> > or even more
> >
> > try:
> > echo 2048 | sudo tee /sys/class/rtc/rtc0/max_user_freq
> > echo 2048 | sudo tee /proc/sys/dev/hpet/max-user-freq
> >
> > [..]
> > ciao,
> > robin
> >
> >
>

Could it be that a low value is better because it's some kind of 'be
ready for an IRQ every 64 times (of what unit ever)'?

IIRC a long time ago I tested 64 and 1024 and couldn't hear or see (for
the waveforms) a difference.


_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel
 
Old 07-14-2010, 08:32 PM
Ralf Mardorf
 
Default ALSA MIDI latency test results are far away from reality

On Wed, 2010-07-14 at 21:45 +0200, Robin Gareus wrote:
> On 07/14/2010 03:23 PM, Ralf Mardorf wrote:
>
> [..]
> > $ su -c "chgrp audio /dev/hpet"
> Its also writable for the group, right?

Sorry another PS, I missed to reply to this question.

At least for Suse it is:

spinymouse11.2@suse11-2:~> su -c "chgrp audio /dev/hpet"
Password:
spinymouse11.2@suse11-2:~> ls -l /dev/hpet
crw-rw---- 1 root audio 10, 228 2010-07-14 21:39 /dev/hpet

I'm sure it was for 64 Studio 3.0-beta3 too, but I never checked it for
64 Studio 3.3 alpha.

_______________________________________________
64studio-devel mailing list
64studio-devel@lists.64studio.com
http://lists.64studio.com/mailman/listinfo/64studio-devel
 

Thread Tools




All times are GMT. The time now is 10:04 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org