Hi Jeremy and Ben, 2015-02-28 20:17 GMT+01:00 Jeremy Jongepier <jeremy(a)autostatic.com>om>: I've been using a Delta 44 for many many years though since moving more and more to laptop it's no longer possible so I've moved to Firewire. Not this card though, got a Roland FA-66 which works good but gives a bit much latency, and a Presonus firestudio project which I use mostly live. Another thing is that I find the cabling for firewire (and probably USB) a real nuisance, especially since the firewire stack used by jack does NOT like it when the device is disconnected. Sorry to go off on a tangent but is USB comparable in performance to firewire under linux now? Latency? Number of channels? Mostly I'm asking about latency. Regards, Robert

On Sun, 1 Mar 2015, Jeremy Jongepier wrote: My USB IF is a USB1.1 which may be why I can only get 64/2. I should try 32/3 on it. I use -r48000 by default on everything BTW. -- Len Ovens www.ovenwerks.net

If tweaks do work, seems to depend to the hardware, BIOS update, Linux driver etc.. For the ICE cards I can use 256/2/48000 without xruns, the HDSP card can't be used lower than 256/2/48000 and even then or with higher latencies, it still cause xruns. Keyboard mini din, mouse USB, since the mini din mouse didn't work with some Linux installs anymore. AMD Athlon dual-core 2.1 GHz, 4 GiB RAM. I didn't use the the uname -r kernel below for serious audio work, but other x86_64 and x86 RTs. For MIDI I use HR timer, but I can't use it for audio. Nowadays I use the HDSP for audio and the ICE cards for MIDI. If I don't need MIDI, I disable the ICE cards. For audio nothing changes when changing PCI/PCIe slots or using a NVIDI card instead of the integrated ATI graphics, it just has got impact to the intervals, when MIDI jitter happens, but even for MIDI it doesn't make a big difference. [rocketmouse@archlinux ~]$ uname -rm 3.10.61-rt65-1-rt-lts x86_64 [rocketmouse@archlinux ~]$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor performance performance [rocketmouse@archlinux ~]$ cat /usr/local/sbin/tuning #!/bin/bash # /usr/local/sbin/tuning - Arch Linux # 2013/Apr/05 ### http://www.mythtv.org/wiki/PCI_Latency ### http://wiki.linuxmusicians.com/doku.php?id=system_configuration#pci_bus_lat… ### Bluetooth #service bluetooth stop ### Network #service network-manager stop #service networking stop # does cause serious issues #modprobe -r r8169 # Ethernet NIC driver ### TerraTec EWX 24/96 #modprobe -r snd_ice1712 ### Others modprobe -r firewire-ohci modprobe -r firewire_core #service cups stop modprobe -r ppdev # parallel port modprobe -r lp # printer ### Unbinding devices echo -n "0000:00:13.2" > /sys/bus/pci/drivers/ohci_hcd/unbind echo -n "0000:00:13.4" > /sys/bus/pci/drivers/ohci_hcd/unbind ### Log file l="/var/log/tuning.log" #echo "$ lspci -v " > $l #lspci -v >> $l #echo >> $l echo "# service rtirq status " > $l service rtirq status >> $l echo "# grep 18: /proc/interrupts" >> $l grep 18: /proc/interrupts >> $l echo >> $l echo -n $(date)" - "$(uname -r)" - " >> $l cat /etc/issue >> $l echo -e "\n########################################################################\n" ; cat $l exit 0 [rocketmouse@archlinux ~]$ diff /usr/local/sbin/tuning /usr/local/sbin/tuning-rice 3c3 < # /usr/local/sbin/tuning - Arch Linux --- 18c18 < #modprobe -r snd_ice1712 --- [rocketmouse@archlinux ~]$ grep music /etc/fstab /dev/sda11 /mnt/music ext3 noatime,defaults 0 2 /dev/sdb12 /home/music ext4 noatime,defaults 0 2 [rocketmouse@archlinux ~]$ service rtirq status PID CLS RTPRIO NI PRI %CPU STAT COMMAND 44 FF 90 - 130 0.0 S irq/8-rtc0 199 FF 85 - 125 0.0 S irq/18-snd_hdsp 206 FF 80 - 120 0.0 S irq/20-snd_ice1 213 FF 79 - 119 0.0 S irq/21-snd_ice1 78 FF 75 - 115 0.0 S irq/19-ehci_hcd 81 FF 75 - 115 0.0 S irq/16-ohci_hcd 94 FF 74 - 114 0.0 S irq/17-ohci_hcd 100 FF 73 - 113 0.0 S irq/17-ohci_hcd 42 FF 70 - 110 0.0 S irq/1-i8042 30 FF 50 - 90 0.0 S irq/9-acpi 61 FF 50 - 90 0.0 S irq/42-radeon 82 FF 50 - 90 0.0 S irq/14-pata_ati 83 FF 50 - 90 0.0 S irq/15-pata_ati 88 FF 50 - 90 0.0 S irq/22-ahci 185 FF 50 - 90 0.0 S irq/7-parport0 371 FF 50 - 90 0.0 S irq/43-enp3s0 3 FF 1 - 41 0.4 S ksoftirqd/0 19 FF 1 - 41 0.5 S ksoftirqd/1 [rocketmouse@archlinux ~]$ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: HDSPMx579bcc [RME AIO_579bcc], device 0: RME AIO [RME AIO] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: EWX2496 [TerraTec EWX24/96], device 0: ICE1712 multi [ICE1712 multi] Subdevices: 1/1 Subdevice #0: subdevice #0 card 2: EWX2496_1 [TerraTec EWX24/96], device 0: ICE1712 multi [ICE1712 multi] Subdevices: 1/1 Subdevice #0: subdevice #0 RTIRQ_NAME_LIST Regarding MIDI jitter caused by USB MIDI, there's no difference between "usb" or making the USB port for the MIDI interface head of the USB ports, perhaps for USB audio it has got noticeable impact. [rocketmouse@archlinux ~]$ grep RTIRQ_NAME_LIST /etc/conf.d/rtirq RTIRQ_NAME_LIST="rtc snd_hdsp snd_ice1 usb i8042" JFTR the newer kernels assign individual IRQs to the graphics and HDSP, but with older kernels they share the IRQ and not sharing the IRQ anymore didn't improve anything. Regards, Ralf

On Sun, 1 Mar 2015, Len Ovens wrote: I am just noticing on my new mother board: 17: 1162370 601852 172158 46400 IO-APIC-fasteoi snd_ice1712 19: 0 1 2 186154 IO-APIC-fasteoi snd_ens1370 But there is no problem. So the irq order was specific to my old P4. -- Len Ovens www.ovenwerks.net

On Sun, Mar 01, 2015 at 08:18:47PM +0100, Robert Jonsson wrote: Well I read the first few responses and took the plunge. I've got things to get recorded and no plan B so I'm going to cross my fingers and go for it. Thanks to everyone who's replied with information, I'll let you all know how it goes! bjb

On Sun, 29 Mar 2015, Ben Bell wrote: There is a lot to be said for something that shares internal bus and power supply. Pulse uses the dbus IF to control it's mixer and the levels seem to track with fader movement very well I can notice no delay. This is not a dbus issue I think. My first thought is: why would you stop jack? I know here, it starts on session login and only stops at logout (which around here means starts at boot and stop at shutdown) Are you using jackd or jackdbus? If you are using jackdbus, you may wish to try chmod -x jackd to keep it from being auto started by some jack client. Jack_control will allow you to change any of jack's parameters while jackdbus is running... though the only one that makes sense is latency which can be changed on the fly anyway. Anyway, if you are using qjackctl to turn jack off and on then I would suggest using it's run script on start/stop to shut these other things down before jack and start them again after. Again, I have set qjackctl not to start or stop jackdbus so I can use the connection window for connections. I can use it to stop jack, but no matter the AI, stopping jack means restarting pretty much all the SW and reconnecting all the ports. There are some APPs that will allow a reconnect to jack when it comes back and will reconnect at least it's own ports to whatever they were connected to before but that to me is not a good way to run things. I am sure if you powered the d1010 down while the system was running you would have similar problems or worse. Don't do that. I think if you want your focusrite to be as stable as an internal card you need to treat it the same... powered before the system starts and off after system. Using an AoIP or USB IF should be the same. Just my 2c -- Len Ovens www.ovenwerks.net

On Sun, Mar 29, 2015 at 05:07:10PM +0100, Ben Bell wrote: Touch wood, final follow up mail, just to report that this is now seeming to be pretty solid if I accept that I need to start ffado-dbus and Jack and then not touch the settings. The problems I was having turned out to be a dodgy optical cable brand which lead to some sync problems. So, thumbs up on the switch to Focusrite Saffire Pro 40 from me. Thanks for all who responded. bjb

Hi Ben, 2015-02-28 21:17 GMT+01:00 Len Ovens &lt;len(a)ovenwerks.net&gt;et>: I can only answer some of these questions. The 1010s will have slightly I sometimes wonder about numbers like these and if I'm doing something wrong or if it's incredibly hardware dependent. I've never ever come close to running at 16/2 in a stable manner. 128/2 I could run reasonbly stable with the Delta 44. Now with firewire it's harder still. Do you really get this without xruns? Any magic tricks? How much have you tweaked your settings to get there? Regards, Robert

On Sun, 1 Mar 2015 07:17:19 -0800 (PST), Len Ovens wrote: PA isn't installed on my machine. No WiFi here either, I'm using an ADSL modem by PPPoE. Disconnecting the Internet doesn't make a difference. WMs/DEs usually openbox or JWM, but also Xfwm/Xfce4 and others, don't make a difference.

On 03/03/2015 10:00 PM, alexus / dotcommon wrote: Yes but I get the idea that it's becoming more and more irrelevant these days as there are timers available with higher resolutions, like snd-hrtimer. But correct me if I'm wrong, this part of Linux Audio is not the best documented one ;) Jeremy

On 03/03/2015 10:26 PM, alexus / dotcommon wrote: Sequencers that use ALSA MIDI like Qtractor or Seq24 can also use the snd-hrtimer timer. But it's still unclear to me if those sequencers perform better when using the hardware timer or the snd-hrtimer kernel module. I have a gut feeling snd-hrtimer yields better results as it has a higher resolution (which could on the other hand result in more jitter). Jeremy

On Wed, 4 Mar 2015 20:58:55 +0100, Ralf Mardorf wrote: You were talking about audio, not MIDI? Well, about audio my opinion isn't wanted on that list :p.

On Tue, 3 Mar 2015, alexus / dotcommon wrote: 48k, synced to my 48K s/pdif preamp as happens. Because I want my audio card ICE1712 to be higher priority than my MIDI card which also has an audio portion (snd_ens1370) Really I could (and should remove USB from the list as there is nothing on USB that needs to be prioritized. The stock rtirq tries to be rightish no matter what audio IF the user plugs in, but boosting ones mouse priority above the hard drive and ethernet does not really make sense :) I do the same thing on my netbook by setting "usb3 snd usb" to push the usb3 port (where my audio IF sits with a clear irq) to a higher priority than the SD reader, internal camera and whatever else Acer decided to hook up to USB internally. The snd in there is for internal audio when I use that. (generally output only) Cron runs at maximum niceness, but checking for new SW does a lot of disk read/write and network traffic. Turning cron off seems to get rid of some of those odd spaced spurious xruns. Some people turn off auto updates instead, and do those manually. Cups is not as bad as the win print servers used to be (everything stopped while the windows system printed a page) but I don't run that either. When I was running the P4 with low memory I tried to think of anything that might give trouble and went for the quietest system I could. The app I use is a script for the most part (actually a collection of scripts) and can change everything on the fly. But it is jackdbus centric which some people just don't like. I could probably make it jackd(1/2) if I really felt like it, but I don't :) No solid reason, just my bent. -- Len Ovens www.ovenwerks.net

On Sun, Mar 1, 2015 at 9:42 AM, Len Ovens &lt;len(a)ovenwerks.net&gt; wrote: all audio interfaces have a hardware limit on the smallest sized buffer (period) they can use. it is partly based on the internal design of the interface itself, but also affected by the bus minimum transfer size. multichannel cards can theoretically use a smaller buffer because they don't bump into the bus transfer limit, but in an era when even the builtin HDA has 6 or 8 channels, this isn't much of a difference any more. there's almost no reason to use the RTC on any modern system. high frequency timers are on every motherboard and in combination with a tickless kernel (the default these days), the cpu overhead is massively reduced even as resolution is increased. this should NEVER be true. if it is true then the synth is misdesigned or the video driver is incorrectly written. JACK (1) goes to some considerable lengths to make sure that the relevant code of its clients can never be swapped out. JACK 2 makes a similar though slightly less sophisticated effort.

On Sun, Mar 1, 2015 at 7:28 PM, Len Ovens &lt;len(a)ovenwerks.net&gt; wrote: no kernel code runs in the SCHED_FIFO scheduling class. kernel code interrupting or delaying a SCHED_FIFO task/thread is a bug in the kernel.