Re: rtirq

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 20 Mar 2015 09:50:19 +0100, Joakim Hernberg wrote:
>AFAIK, once hrtimers are enabled in a kernel, everything runs off that
>by default.

Thank you Joakim,

btw. I upgraded rtirq today and noticed that Rui dropped "rtc" from the
rtirq name list. I didn't remove "i8042", but I guess Len's guess is
right, even while I'm using a PS/2 keyboard, it might not need rt
priority.

>I'd also really like to do away with the 1000Hz ticker and start using
>NOHZ on my rt kernels, but I haven't changed that yet, just to
>accommodate the people talking of MIDI jitter...
>
>I'd be very happy if someone concerned about midi jitter could test an
>alternative kernel to see how the changes would affect the matter.

I do not care that much about the MIDI jitter and my Linux audio issues
anymore and I'm anyway out of practice. Assumed I have free time to make
some music, I'm using my Arch Linux the way it is possible for my needs
and avoid to do recordings that can't satisfy my needs. However, I'm
using HR timer with Qtractor and not system timer (1000 Hz). Someday I
might have the time and will to test a NOHZ kernel. IIRC once
"tickless" was suspected to cause issues on my machine, since there's a
nohz=off menu entry in my GRUB menu:

[rocketmouse@archlinux ~]$ cat /mnt/debi386/boot/grub/grub.cfg
[snip]
menuentry 'Arch Linux Rt nohz=off'
[snip]

At the moment I test portable equipment. For testing purpose I even
replaced my Ibanez Blubber and the analog stomp boxes by 31.25 KHz, 5
ms latency digital equipment [1]. If I ever should finish the "test", I
likely will export WAV and not MIDI and mix the imported WAV files on my
Arch Linux machine. So within the foreseeable future I neither will do
MIDI, nor audio recordings using my PC, I just will use it to mix the
music.

On Fri, 20 Mar 2015 10:00:50 +0100, Joakim Hernberg wrote:
>On Thu, 19 Mar 2015 19:01:33 +0100 Ralf Mardorf wrote:
>
>> Tape synced to the Computer by SMPTE (Atari) or by Click (C64).
>> Record a MIDI synth and after that record the same synth on another
>> tape track. This will double the synth sound, all you get is a
>> phasing, that doesn't move.
>> 
>> Do the same with a Linux or Windows PC. Record a track with Qtractor
>> or Cubase and after that record the same external synth on another
>> Qtractor or Cubase track. Sounds do not start at the same time,
>> there's always audible shift, comparable to slow early reflections
>> and the phasing is moving.
>
>One thing that isn't clear to me in the above test, what is sending
>MIDI to the instrument?

A MIDI sequencer running on the C64 or Atari ST has got a MIDI track.
This MIDI sequencer is synced to a tape recorder, by SMPTE (Atari) or by
click (C64).
The tape recorder is sync master, the C64's or Atari's sequencer is
sync slave.
1. Record e.g. a Kick from a drum sample player to the analog tape
recorder. When finished rewind and
2. record a Kick on another audio tape track.
Both Kicks always start at the same time.

Use a Linux PC, record a MIDI track for e.g. a Kick with Qtractor.
1. Record the audio signal of the external synth playing the Kick on a
Qtractor audio track and
2. do a second recording on another Qtractor audio track. The higher
the latency, the larger is the drift between the Kicks on both tracks.
It's not a constant delay, it's fluctuating delay, aka jitter.

>I know that there were quite a lot of problems
>on windows regarding midi timing, especially keeping it synced, as
>windows had 3 different multimedia timers used, so depending on which
>timers were in use, the midi timer might have drifted compared to the
>audio timer.

I don't use Windows, I just installed it for testing purpose, but in my
experiences there is less jitter, but still too much when using Windows.
Have you ever used loop play over a very long time with Qtractor? You
will experience another sync issue, you unlikely will find using Cubase.

>But this is just drifting clocks, and has nothing to do
>with jitter.  Further, at least on windows the midi isn't handled at
>all by the ASIO driver, so I doubt that the ASIO buffer size would
>have any impact at all on midi timing.

I don't know, I made my tests with the OS I use, Linux and compared
just the lowest usable latency with a Windows install. A Windows
install I only made for testing purpose.

> I think this is different on linux using jack midi, but i suspect
> that the alsa sequencer won't be tied at all to any buffer size that
> JACK uses.  I might be wrong about this though?

JFTR the tests I made were done a long time ago, with Jack 2 and the
-Xalsarawmidi option, to reduce the fluctuating drift. Jack 1 didn't
provide this option.

Regards,
Ralf

[1]
I'm testing "MusicStudio" an app running on my iPad2
with a Line 6 MIDI Mobilizer II and Line 6 Mobile in and a Behringer X
V-Amp LX1-X as small portable gear, resp. until now I only used the
touchscreen as input device.

My impression until now:

Only analog Wah Wahs produce good sound and 5 ms latency are strange
compared to analog stomp boxes.

A touchscreen can't be seriously used as a keyboard replacement, for
programming rhythms it is ok.

The output sound of an iPad is disgusting, remixing on a Linux, Windows
or Mac desktop/laptop computer is needed.

The value-for-money ratio without the need to pay for an iPad is ok:

14.99 € MusicStudio
37.83 € V-Amp
19.20 € Line 6
-------------------
72.02 €
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user





[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux