Am Donnerstag, den 30.03.2017, 14:17 +0200 schrieb Ralf Mardorf: First, you're calling it "grotesque", then you point out two tasks where low latency DOES matter (IMHO in EVERY live situation, not only in some)... Sometimes, one should think twice before posting. I wouldn't call it exactly "offending", but, you know, it just sounds like you're blaming people writing shit.  Be kind. And respect others that took the time to document things. Just my 2 Cents... Greets! Mitsch

Am 30.03.2017 um 16:39 schrieb Ralf Mardorf: Why ? Latency introduced by digital or analogue gear, will always come on top of it. So the goal is to keep it as small as possible. Archive a latency of ~5ms isn't as hard with a proper set up machine. You'll never change anything on "travel time of the sound wave in the air", so why make it complicated?

On Thu, 30 Mar 2017 11:07:35 -0400, Robert Edge wrote: Not in my experiences, but ok, then we simply don't remove it from the Wiki. Should we stay with the Wiki as is, or are there at least a few other points we should edit? On Thu, 30 Mar 2017 16:47:20 +0200, Hermann Meyer wrote: If live music, theatre etc. should be your domain, you hopefully try to compensate issues caused by travel time. Or am I mistaken aren't there possible issues caused by travel times? Regards, Ralf

On Thu, Mar 30, 2017 at 11:57 AM, Len Ovens <len(a)ovenwerks.net> wrote: Depends on what you need it for, but in general I think that is a fair assessment. If I find that the studio I am paying to use cannot support monitoring through the machine because it's prosumer USB interface isn't stable at usable latencies, I'm finding another studio.

Am 30.03.2017 um 17:25 schrieb Ralf Mardorf: If there are, then it is related to the room / speaker positions. Nothing you can change with pc-setup-tools. Maybe with a specialized software for that, but again, no general solution could be provided. More likely you'll look for a better speaker position. But most likely is the opposite, you'll use the travel time as "effect" . To say, hey, this room has a nice acoustic, really great live atmosphere.

Am 31.03.2017 um 09:43 schrieb Will Godfrey: I think, for listeners, latency, if it is in a "normal range" wouldn't be a issue, often it is the opposite (eg. Live Atmosphere) , but for the artist, even a small amount of latency could be disturbing, when you hear your instrument delayed without using a delay.

On Fri, 31 Mar 2017, Hermann Meyer wrote: That is exactly it. When playing bass, I find that once I am 30 feet away from the rest of the band (all analog signal path) my playing suffers. I find playing guitar through the computer to use effects in the computer with jack set 256/2 is starting to get anoying. In a hall, so long as the house speakers are reasonably aligned, I can be over 100feet away with no degredation in listening enjoyment (assuming a hall with reasonable acoustics). -- Len Ovens www.ovenwerks.net

30 feet would be closer to 30ms, and is enough to make the feeling of playing the note and the sensation of hearing it start to feel disconnected. Try this stuff for yourself: take your synth or guitar or bass or what have you, plug it in to your computer, put a simple delay in the path with something like jack_rack, and play. At some point it's going to start feeling weird. Exactly where that point is depends on the person and the nature of the sounds you are making. Here's another thing you can do: fire up hydrogen and make a pattern which is just a clave or cross stick playing quarter notes at a slow tempo. send the output to both directly to your sound card as well as to an instance of jack rack with a short delay. start increasing the delay time, by 30ms you will hear a clear flam. On Fri, Mar 31, 2017 at 10:32 AM, Peter <list(a)schmitteckert.com> wrote:

On Fri, 31 Mar 2017 16:32:18 +0200, Peter wrote: [rocketmouse@archlinux ~]$ bpm2ms 90 | grep 1/32 (60000ms/90BPM)*4*(1/32)= ~83.33333333333333333333ms So this would be 1/32 note at 90 BPM. This is something a musician should notice, let alone that artists are not seldom "freaks", e.g. savants, autists etc., some even without being aware to "suffer" from autism or something similar. We are at least aware of what was played already before, what already is "processed" by the brain. So I wouldn't it call it "cheating", but what we are doing is based on "extrapolation". You were to late, the brain takes a while to notice this and then you compensate it. A good musician isn't to late, a beginner often is out of time.

On 03/31/2017 04:32 PM, Peter wrote: There's the Larry Mullen Jr case: http://www.newyorker.com/magazine/2011/04/25/the-possibilian He could hear a track was off by about 2ms and also in which direction. But if anybody knows about more in-depth research then I'd be interested too. Jeremy

Am 31.03.2017 um 16:32 schrieb Peter: For me, disturbing starts at a frame rate of 256/2 which means round about 10ms. That is the point were it seems that my brain starts to lock ahead. With a setting of 128/2 (5ms) I've no problems at all. I'm not sure, if I'm able to notice lower latency at all.

On Fri, 31 Mar 2017 17:34:07 +0200, Ralf Mardorf wrote: Resp. I suspect we made a mistake. If we play a virtual synth we might start noticing that something is fishy at 256/2 not at 10 ms, but already at 5 ms. Not round-trip, just output latency. -- "Michael" described Floyd as "an idiot savant", and added, "Give him any two numbers, and he can multiply them in his head, just like that." Homer, testing Floyd, said, "Five times nine", and Floyd instantly responded "Forty-five", which impressed Homer.

Le Fri, 31 Mar 2017 15:06:57 +0000, Fons Adriaensen <fons(a)linuxaudio.org> a écrit : I fully agree, to practice rhythms in a regular basis is very important to get a fluid and varied play. And more you practice different rhythms, easier it become to play new ones, or to assure the show even when you are in a bad day. For me, it is 4 dimensions in music, the rhythm give us the genre, the harmony give the context, the melody give the meaning and the expression give the style. Harmony and melody are closely related, as well than rhythm and expression. More you are good at playing rhythms, more expressions you can give at your music. For me, learning to play rhythms was a very difficult and long way. I came from classical music and was not good at playing modern music, that until I begun to sing at the same time I am playing. I never regretted that step, this forced me to play simple things, to return to the basis, to use my feeling to add the complications, and to work the rhythms again and again until I became some kind of rhythm machine. With time, it begun to make sense and I surprised me to play stuffs I was never expecting to be able to play. And folks begun to said me not only they liked the song, but also that they like the way I am playing music. Cheers, Dominique

Dear All, Am 31.03.2017 um 20:00 schrieb Will Godfrey: and I would like to thank everyone who answered. I have a much better understanding of the time scales now. Best regards, Peter

On Fri, 31 Mar 2017 09:25:34 +0200, Hermann Meyer wrote: You are clueless, aren't you? Have you ever heard of travel time correction? I didn't find a good, absolutely correct, detailed explanation in English, likely it requires more than just such a short text. However, to prove you wrong, just talking about something you don't understand at all, this should be enough: http://www.recordinginstitute.com/da154/images/spkrdel.gif "Delay In Sound Reinforcement Sometimes at live performances, extra speakers are placed down the walls of the auditorium. If these speakers are not delayed, it will appear that the sound is coming from the walls rather that from the state. The delay of the sound coming from the state, mixing with the un-delayed signal coming from the speaker, can also muffle the attack and clarity of the sound. To prevent this from happening, side speakers used for sound reinforcement are delayed by the number of milliseconds equal to the number of feet that the speaker is away from the stage. Figure one below shows two sets of speaks on the side wall. The closest set is 20 feet away from the stage so the signal sent to these speakers is delayed 20 ms. Since the second set is 40 feet away from the stage, their signal is delayed by 40 ms." - www.recordinginstitute.com/da154/ARP/chap3Sig/0304delcor.htmlA Regards, Ralf -- "Michael" described Floyd as "an idiot savant", and added, "Give him any two numbers, and he can multiply them in his head, just like that." Homer, testing Floyd, said, "Five times nine", and Floyd instantly responded "Forty-five", which impressed Homer.

On Fri, 31 Mar 2017 13:27:36 +0200, Christopher Arndt wrote: No problem, I didn't start the hostilities and I'm not interested to do any additional editing to the Wiki. For me this "discussion" is finished. Regards, Ralf

On Fri, 31 Mar 2017 14:11:58 +0200, Joakim Hernberg wrote: Hi, I asked for help, since I don't know everything! I can't simply edit the Wiki without knowing if there are some computers that e.g. require 1000 Hz because hrtimer for some reason can't be used. Are there some apps not using hpet? What is the jack1 equivalent of -Xalsarawmidi? Did somebody compare alsa-midi-latency-test with and without echo 2048 > /proc/sys/dev/hpet/max-user-freq ? Is there anything related to professional audio that requires flash? Instead I got... "Sometimes, one should think twice before posting. I wouldn't call it exactly "offending", but, you know, it just sounds like you're blaming people writing shit.  Be kind. And respect others that took the time to document things." ..and a bunch of bikeshedding about latency. Btw. nobody contributed to the talk [ https://wiki.archlinux.org/index.php/Talk:Professional_audio ] and apparently just a few read the Wiki page. The Wiki is outdated! I already edited a little bit, but I will not continue to "offend" anybody or blame "people writing shit". I'll keep the Wiki as is, to "respect others that took the time to document things". Regards, Ralf -- "Michael" described Floyd as "an idiot savant", and added, "Give him any two numbers, and he can multiply them in his head, just like that." Homer, testing Floyd, said, "Five times nine", and Floyd instantly responded "Forty-five", which impressed Homer.

On Fri, 31 Mar 2017 16:49:55 +0200 (CEST), karl(a)aspodata.se wrote: Where should somebody do her homework? The Wiki is intended for professional audio homework. Sure, the professional user needs to find a few things out by her own, but the original information for the homework shouldn't give bad advices. Even fixing small issues does help. At the moment the Ardour package from official Arch repositories isn't well maintained. A professional not involved in the community can't know this, that's why I e.g. pointed to the AUR, to build Ardour. Do you expect somebody needs to find out this by her own? Why? The Wiki is made to provide such information. Then there's a pointer to use 1000Hz for those compiling their own kernel and at the same time there are links to PKGBUILD that do use configs with CONFIG_HZ_300=y for RT patched kernels. The Wiki is there to help users, to understand why 1000Hz might or might not be required.

On Fri, 31 Mar 2017 18:55:45 +0200 (CEST), karl(a)aspodata.se wrote: There's no need for measurements. If you want to compare system timer 300 Hz with system timer 1000 Hz you e.g. could check if one or the other increases MIDI jitter by using https://github.com/koppi/alsa-midi-latency-test , but since by default usually hpet (hrtimer) is used, it doesn't matter. The question is, if for some reason hpet (hrtimer) shouldn't be used on some machines or by some software. There are also the tickless options. [rocketmouse@archlinux ~]$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet acpi_pm [rocketmouse@archlinux ~]$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc [rocketmouse@archlinux ~]$ zgrep NO_HZ /proc/config.gz CONFIG_NO_HZ_COMMON=y CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set # CONFIG_NO_HZ is not set Btw. in the past, with my old mobo, Qtractor displayed using hrtimer and it was selectable by the list of sources. Now it displays "default" and doesn't offer hrtimer in the list. Any explanation for this is welcome. Regards, Ralf -- "Michael" described Floyd as "an idiot savant", and added, "Give him any two numbers, and he can multiply them in his head, just like that." Homer, testing Floyd, said, "Five times nine", and Floyd instantly responded "Forty-five", which impressed Homer.

On Fri, 31 Mar 2017 21:26:43 +0200 (CEST), karl(a)aspodata.se wrote: Because the Wiki should provide useful information to set up a professional audio computer and not test cases for all kinds of situations, available methods of measurements etc.. "Professional" is for being able to set up a system with working settings and not to waste time by trail and error and measurements. Btw. I added the latency test to the MIDI chapter, so users could test their MIDI interfaces, _just in case they should notice something fishy_ without measurements. As long as nothing is noticeable, there's no need to measure and optimise. Another and last example, likely most, if not all major distros by default mount with "relatime" [1]. SATA3 is wide spread, even SSDs are wide spread. I'm used to mount music partitions with "noatime", but I doubt that this is really required. Since you never know, I would mention "noatime" by the Wiki, as it's already done, but OTOH I wouldn't mention to touch all possible settings, that theoretically could have impact, they all might come with side effects, as "noatime" does, too. [rocketmouse@archlinux ~]$ man mount | grep "Update inode" -B1 -A3 relatime Update inode access times relative to modify or change time. Access time is only updated if the previous access time was earlier than the current modify or change time. (Similar to noatime, but it doesn't break mutt or other applications that need to know if a file has been read since the last time it was modified.) Btw. if your HDDs should be the bottleneck, at least Ardour informs you about this. The only time I experienced this, was with a HDD that reached end of life. However, since I do not continue updating the Wiki, consider to provide your opinions to https://wiki.archlinux.org/index.php/Talk:Professional_audio . Maybe somebody else will update the Wiki. And don't worry, if the maintainer has time to continue maintaining the official Ardour Arch package, I revert the link from "AUR" to "Extra". With "not updating the Wiki", I'm only saying that I don't remove all the clutter, but I still have an eye on it. Regards, Ralf

Am 31.03.2017 um 12:47 schrieb Ralf Mardorf: Please learn to read what others wrote, what you claim above, is, exactly what I wrote. just shorter then your doctor thesis. :-P

On Thu, Mar 30, 2017 at 09:28:39AM -0400, Joe Hartley wrote: Not if you listen to a mix of the reproduced trakcs and the direct sound (line in) of your instrument. Almost all soundcards allow this, otherwise use a simple analog mixer for monitoring. The recorderd track is offset to compensate for latency, Ardour will do this automagically. High latency will be a problem if the new track is a software instrument. But then it's a problem even when just playing along with other musicians, and not specific to overdubbing. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

On Thu, 30 Mar 2017 10:01:12 -0400, Joe Hartley wrote: That's why I asked to help, to improve the Wiki ;). Regards, Ralf

Let's focus on the important parts. It's a Wiki about professional usage. I don't claim that low latency is unimportant. It's also important when playing virtual synth, but users shouldn't try to archive latencies between 1 ms and 5 ms, because this is hard to archive. If this works it's very good, if just latencies around 10 ms are possible it's ok, too. More important is to optimise everything to get a reliable system. Again, I don't claim that it's absolutely irrelevant to e.g. compile with "Timer Frequency is set to 1000Hz (CONFIG_HZ_1000=y" but usually hrtimer is used by default, e.g. by Qtractor. To optimise more for e.g. MIDI usage users should consider to run jack2 with -Xalsarawmidi. There also is an option for jack1, but I'm not a jack1 user, so hopefully somebody could help to edit the Wiki. It's the Arch Wiki, the recommended kernel from AUR (btw. there's also a LTS RT patched kernel available) for good reasons dropped 1000 Hz. IOW the AUR kernel is opposing to the hints provided by the Wiki. If 1000 Hz are still required, then we should clarify this. I just asked you to help to get the Wiki up to date and to _discuss_ controversial opinions, as well to explain some things that aren't explained. I can't understand the resistance and hostilities. What's wrong with trying to make the Wiki better? It was good, but seemingly isn't up to date. For example, I already removed "If you want to use any MIDI hardware you need to ensure the ALSA MIDI driver is loaded. You can set the MIDI driver to load at boot by creating the file /etc/modules-load.d/alsamidi.conf containing:" For what reason? This happens automatically. "Warning: Enabling threadirqs seems to be causing system lockups in conjunction with usb devices in at least some kernel versions starting with 3.13 and including at least 3.14-rc2. See for example https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1279081 and http://www.spinics.net/lists/linux-usb/msg102504.html also linked from there. EDIT: The changelog seems to indicate that this has been fixed in the 3.13.6 vanilla kernel. (Search for threadirqs in https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.13.6)" No such kernel is still provided by Arch Linux, even the LTS kernel is 4.9.18. Does somebody need flash for pro-audio? In short, if somebody wants to set up an Arch Linux PC for pro-audio it's better to avoid clutter and to focus in short, of the important things. This are my opinions and _questions_: https://wiki.archlinux.org/index.php/Talk:Professional_audio On Thu, 30 Mar 2017 15:16:51 +0200, Michael Jarosch wrote: Did you read my talk section? I didn't add "This article or section needs expansion". Somebody else did ;). The Wiki is confusing and needs to be reworked. expansion. Regards, Ralf -- "Michael" described Floyd as "an idiot savant", and added, "Give him any two numbers, and he can multiply them in his head, just like that." Homer, testing Floyd, said, "Five times nine", and Floyd instantly responded "Forty-five", which impressed Homer.

On Thu, 30 Mar 2017, Joe Hartley wrote: no -- Len Ovens www.ovenwerks.net

I just noticed this on that wiki page: " ...a worst case latency of up to 10ms (time between the moment an interrupt occurs in hardware, and the moment the corresponding interrupt-thread gets running)" The useful number I need when I talk about the latency of a digital audio device (as a user of that device in a setting where such things matter) is the time between when the sound goes in to the device and when it comes back out. That's not the same thing as the author of this wiki page is talking about. If the thread doesn't even wake up for 10ms it would have to do the processing and then deliver the output to the sound card for the next interrupt (or the one after that, or worse). So I'm not ever sure what is being claimed in the introductory sentence.

On Thu, 30 Mar 2017 21:31:02 +0000, Fons Adriaensen wrote: Full ACK, but I only made a few minor changes, e.g. replaced the link to the Ardour 4.7 package with a link to Ardour 5.8 from AUR. Regards, Ralf

On 3/30/17 2:25 PM, Bernardo Barros wrote: According to their explanation, Bela.io achieves 100us latency it using Xenomai Linux kernel extensions and Programming Realtime Unit (PRU) to "write straight to the hardware". I wonder if that's an option for us.

I think the bela.io comes with a puredata compiler. It's not regular linux. On 3/30/17, Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> wrote:

Do you mean you could run a regular jack app on bela? About the low latency audio on regular linux, I know it's possible. I've been able to run my onboard soundcard at 16/2 48000 with no xruns on my old laptop (core2duo 2GHz). It starts to drop frames as soon as you do anything non-trivial, though. When I need live monitoring, I set up the card at 128 frames. That is low enough I can play guitar or keys normally. About the RT kernel, yes, it makes a world of a difference on my old computers at the lowest latencies. I also have a stock kernel configured for low power consumption on my netbook, and at 1024 frames I could build a quite big patch on automatonism yesterday, and play for hours without xruns. BTW check out automatonism, it's a great modular synth for puredata: https://www.automatonism.com/the-software/ On 3/31/17, Felipe Ferreri Tonello <eu(a)felipetonello.com> wrote: