<div dir="ltr">Forwarding this following thread here also for information if someone has problems with latest rt kernels and ice1712 based cards.<div><br></div><div>Lassi<br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Fernando Lopez-Lezcano</b> <span dir="ltr"><<a href="mailto:nando@ccrma.stanford.edu">nando@ccrma.stanford.edu</a>></span><br>Date: Tue, Jun 21, 2016 at 7:09 PM<br>Subject: Re: [PlanetCCRMA] Midi clock out problems with latest two rt-kernels (system hang)<br>To: Lassi Ylikojola <<a href="mailto:lassi.ylikojola@gmail.com">lassi.ylikojola@gmail.com</a>><br>Cc: <a href="mailto:nando@ccrma.stanford.edu">nando@ccrma.stanford.edu</a><br><br><br>On 06/21/2016 02:33 AM, Lassi Ylikojola wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi<br>
</blockquote>
<br>
Hi!,<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Tested last night on my system two 70 minutes runs with RT19, 48000/64/4<br>
sending AND receiving midi/midi clock via usb midi interface(CH345) the<br>
system was rock solid. No xruns no nothing. Everyhing worked. I'm not<br>
sure but i think something was wrong with my initial tests. Non session<br>
manager not shutting down all apps or something or some updates fixed<br>
something.<br>
<br>
Anyway as soon as i pushed midi clock via ice1712 the system halted. It<br>
took under a minute. So all points to ice1712 doing something wrong<br>
with RT kernels at the moment.<br>
</blockquote>
<br></span>
Thanks for taking the time to retest this thoroughly! I will summarize and post to the lists and copy you. Hopefully someone will be able to spot the problem and come up with a fix.<br>
<br>
Best,<br>
-- Fernando<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Mon, Jun 20, 2016 at 11:24 PM, Lassi Ylikojola<br></span><div><div class="h5">
<<a href="mailto:lassi.ylikojola@gmail.com" target="_blank">lassi.ylikojola@gmail.com</a> <mailto:<a href="mailto:lassi.ylikojola@gmail.com" target="_blank">lassi.ylikojola@gmail.com</a>>> wrote:<br>
<br>
Hi<br>
<br>
I answered your questions and id some further testing today. Using<br>
usb midi interface(CH345) and usb sound card(m-audio micro dac) i<br>
think there are no crashes at least for ten minutes i tested.<br>
<br>
I blacklisted:<br>
blacklist snd_hda_intel ( integrated card. This was blacklisted before)<br>
blacklist snd_ice1712<br>
blacklist snd_ice17xx_ak4xxx<br>
<br>
And my lsmod |grep snd<br>
snd_hrtimer 16384 2<br>
snd_seq_dummy 16384 2<br>
snd_seq_midi 16384 9<br>
snd_seq_midi_event 16384 1 snd_seq_midi<br>
snd_usb_audio 176128 16<br>
snd_usbmidi_lib 36864 1 snd_usb_audio<br>
snd_hwdep 16384 1 snd_usb_audio<br>
snd_rawmidi 32768 2 snd_usbmidi_lib,snd_seq_midi<br>
snd_seq 69632 79<br>
snd_seq_midi_event,snd_seq_dummy,snd_seq_midi<br>
snd_seq_device 16384 3 snd_seq,snd_rawmidi,snd_seq_midi<br>
snd_pcm 114688 2 snd_usb_audio<br>
snd_timer 32768 3 snd_hrtimer,snd_pcm,snd_seq<br>
<br>
<br>
So it seems it's related to those<br>
modules(snd_ice1712,snd_ice17xx_ak4xxx) on my system. I think your<br>
card M-Audio Delta 1010 card uses also ice1712. Some sort of<br>
regression...<br>
<br>
I remembered seeing this thread from 2006:<br>
'Midi issues with 1.0.12 and ice1712'<br>
<a href="http://www.spinics.net/linux/fedora/alsa-user/msg00346.html" rel="noreferrer" target="_blank">http://www.spinics.net/linux/fedora/alsa-user/msg00346.html</a><br>
<br>
I tried the mentioned option to no avail:<br>
"options seq seq_default_timer_device=0"<br>
<br>
<br>
I also have a laptop on which i tested with the same usb midi<br>
interface(CH345) and laptops internal pci intel sound card and no<br>
problems on ten minute test.<br>
<br>
lsmod |grep snd<br>
snd_hda_codec_idt 57344 1<br>
snd_hda_codec_generic 69632 1 snd_hda_codec_idt<br>
snd_hda_codec_hdmi 49152 1<br>
snd_hda_intel 40960 11<br>
snd_hda_codec 126976 4<br>
snd_hda_codec_hdmi,snd_hda_codec_idt,snd_hda_codec_generic,snd_hda_intel<br>
snd_hda_core 61440 5<br>
snd_hda_codec_hdmi,snd_hda_codec_idt,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel<br>
snd_hwdep 16384 1 snd_hda_codec<br>
snd_seq 69632 0<br>
snd_seq_device 16384 1 snd_seq<br>
snd_pcm 114688 4<br>
snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_hda_core<br>
snd_timer 32768 2 snd_pcm,snd_seq<br>
snd 77824 32<br>
snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_hda_codec_idt,snd_pcm,snd_seq,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,snd_seq_device<br>
soundcore 16384 1 snd<br>
<br>
I try to do longer tests as soon as possible.<br>
<br>
<br>
Lassi<br>
<br>
<br>
On Mon, Jun 13, 2016 at 2:50 AM, Fernando Lopez-Lezcano<br></div></div><div><div class="h5">
<<a href="mailto:nando@ccrma.stanford.edu" target="_blank">nando@ccrma.stanford.edu</a> <mailto:<a href="mailto:nando@ccrma.stanford.edu" target="_blank">nando@ccrma.stanford.edu</a>>> wrote:<br>
<br>
On 06/11/2016 02:07 PM, Lassi Ylikojola wrote:<br>
<br>
Hi<br>
<br>
<br>
Hi,<br>
Thanks for the report! I guess we should forward this to the rt<br>
kernel mailing list.<br>
<br>
I tried a quick test here at home with rt19 but my system is<br>
much simpler than yours. This is on an i7-3770K CPU and with one<br>
M Audio Delta 1010 card (plus the motherboard HDA Intel and an<br>
NVidia HDMI sound interface as well running nouveau).<br>
<br>
I started seq24, selected (in "Options") to send MIDI Clock to<br>
the Delta 1010, then created some random notes (also routed to<br>
the 1010) and pressed play. It plays for a while.<br>
<br>
It did hang after some time but I don't know what happened. But<br>
I just managed to hang it again (instantly this time). Brought<br>
up the pattern editor and clicked on "Select Output Bus" (which<br>
by default was showing the Midi Through Port).<br>
<br>
But this is not repeatable. I just did it again (tried several<br>
times) and it did not happen. A race condition, probably...<br>
After a while I noticed that seq24 was not playing - I moved the<br>
mouse and it moved the cursor a tiny bit and then the system was<br>
again hung.<br>
<br>
Are you getting "instant hangs" or is this something that<br>
happens randomly?<br>
<br>
<br>
Sending midi to ice1712 card the system hangs within a minute.<br>
Sending midi via usb midi interface and audio coming from ice1712<br>
card hangs the system randomly.<br>
<br>
<br>
<br>
I presume also that after the cold reboot there is nothing left<br>
in /var/log/messages that may be a clue? (an "Oops" or "BUG" - I<br>
don't see anything in my test machine).<br>
<br>
#Disable SElinux<br>
setenforce 0<br>
<br>
<br>
Why are you doing this? I have never had to disable SElinux for<br>
audio reasons. Were you getting errors from SElinux?<br>
<br>
I really don't remember why i use this in my config. I read about it<br>
somewhere.<br>
<br>
<br>
-- Fernando<br>
<br>
<br>
clock send from jack clients(seq24, sequencer64,<br>
jack_midi_clock from<br>
<a href="http://www.teuton.org/~gabriel/jack_midi_clock/" rel="noreferrer" target="_blank">http://www.teuton.org/~gabriel/jack_midi_clock/</a> or<br>
<a href="https://github.com/x42/jack_midi_clock" rel="noreferrer" target="_blank">https://github.com/x42/jack_midi_clock</a>) to external devices<br>
via midi out<br>
interface.<br>
<br>
Sending midi clock to external devices via ice1712 based<br>
cards hangs the<br>
system and i have to cold reset the computer. I was able to<br>
circumvent<br>
this on rt 17 by sending midi clock via usb midi<br>
interface(CH345).<br>
However on rt19 this works also and the system does not hang<br>
but the<br>
clock is not send correctly. It lacks behind or it is out of<br>
place(This<br>
needs more tests with other clock sources).<br>
<br>
Tested kernels:<br>
<br>
4.4.12-300.rt19.1.fc23.ccrma.x86_64+rt ice1712 based cards<br>
midi out<br>
hangs the system. Midi out via usb interface CH345 works but<br>
not on<br>
correct beat/time. I have to retest this with different<br>
clock sources.<br>
<br>
4.4.9-300.rt17.1.fc23.ccrma.x86_64+rt ice1712 based cards<br>
midi out hangs<br>
the system. Midi out via usb interface CH345 works.<br>
<br>
4.4.4-301.rt11.1.fc23.ccrma.x86_64+rt is ok. I can send midi<br>
clock from<br>
ice1712 devices and system is stable.<br>
<br>
The system is stable with stock kernel also.<br>
<br>
So any help appreciated. I use rtirq and below some system info.<br>
<br>
<br>
System info:<br>
<br>
Scipt before every session:<br>
# fedora chmod<br>
chmod 666 /dev/snd/seq<br>
<br>
#wait 2 secs<br>
sleep 2<br>
<br>
#load performance governor<br>
modprobe cpufreq_performance<br>
<br>
#wait 1 sec<br>
sleep 1<br>
<br>
#Set full speed for all processors<br>
echo performance ><br>
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor<br>
echo performance ><br>
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor<br>
echo performance ><br>
/sys/devices/system/cpu/cpu2/cpufreq/scaling_governor<br>
echo performance ><br>
/sys/devices/system/cpu/cpu3/cpufreq/scaling_governor<br>
<br>
<br>
<br>
cat .jackdrc<br>
/usr/bin/jackd -dalsa -r48000 -p64 -n4 -D -Chw:DMX6Fire<br>
-Phw:DMX6Fire<br>
<br>
Tried different -p and -n options (-p128 -n2).<br>
<br>
cat /proc/asound/cards<br>
0 [A61 ]: USB-Audio - Axiom 61<br>
M-Audio Axiom 61 at<br>
usb-0000:00:1d.7-2.3, full speed<br>
1 [CH345 ]: USB-Audio - CH345<br>
QinHeng CH345 at usb-0000:00:1a.2-2,<br>
full speed<br>
2 [nanoPAD2 ]: USB-Audio - nanoPAD2<br>
KORG INC. nanoPAD2 at<br>
usb-0000:00:1d.7-2.4.4,<br>
full speed<br>
3 [DSP24 ]: ICE1712 - Hoontech SoundTrack Audio DSP24<br>
Hoontech SoundTrack Audio DSP24 at<br>
0xec00, irq 16<br>
4 [DMX6Fire ]: ICE1712 - TerraTec DMX6Fire<br>
TerraTec DMX6Fire at 0xe400, irq 17<br>
<br>
<br>
<br>
lsmod |grep midi<br>
snd_seq_midi 16384 16<br>
snd_seq_midi_event 16384 1 snd_seq_midi<br>
snd_usbmidi_lib 36864 1 snd_usb_audio<br>
snd_rawmidi 32768 3<br>
snd_usbmidi_lib,snd_mpu401_uart,snd_seq_midi<br>
snd_seq 69632 80<br>
snd_seq_midi_event,snd_seq_dummy,snd_seq_midi<br>
snd_seq_device 16384 3 snd_seq,snd_rawmidi,snd_seq_midi<br>
snd 73728 47<br>
snd_ice1712,snd_usb_audio,snd_ac97_codec,snd_hwdep,snd_timer,snd_i2c,snd_pcm,snd_seq,snd_rawmidi,snd_usbmidi_lib,snd_ak4xxx_adda,snd_mpu401_uart,snd_seq_device,snd_cs8427<br>
<br>
<br>
<br>
lsmod |grep 1712<br>
snd_ice1712 77824 18<br>
snd_cs8427 16384 1 snd_ice1712<br>
snd_i2c 16384 2 snd_ice1712,snd_cs8427<br>
snd_ice17xx_ak4xxx 16384 1 snd_ice1712<br></div></div>
snd_ak4xxx_adda <a href="tel:20480" value="+35820480" target="_blank">20480</a> <tel:<a href="tel:20480" value="+35820480" target="_blank">20480</a>> 2<div><div class="h5"><br>
snd_ice1712,snd_ice17xx_ak4xxx<br>
snd_mpu401_uart 16384 1 snd_ice1712<br>
snd_ac97_codec 131072 1 snd_ice1712<br>
snd_pcm 114688 5<br>
snd_ice1712,snd_usb_audio,snd_ac97_codec<br>
snd 73728 47<br>
snd_ice1712,snd_usb_audio,snd_ac97_codec,snd_hwdep,snd_timer,snd_i2c,snd_pcm,snd_seq,snd_rawmidi,snd_usbmidi_lib,snd_ak4xxx_adda,snd_mpu401_uart,snd_seq_device,snd_cs8427<br>
<br>
<br>
<br>
cat /proc/cpuinfo<br>
processor: 0<br>
vendor_id: GenuineIntel<br>
cpu family: 6<br>
model: 23<br>
model name: Intel(R) Core(TM)2 Quad CPU Q9300 @ 2.50GHz<br>
stepping: 7<br>
microcode: 0x70a<br>
cpu MHz: 2499.000<br>
cache size: 3072 KB<br>
physical id: 0<br>
siblings: 4<br>
core id: 0<br>
cpu cores: 4<br>
apicid: 0<br>
initial apicid: 0<br>
fpu: yes<br>
fpu_exception: yes<br>
cpuid level: 10<br>
wp: yes<br>
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge<br>
mca cmov pat<br>
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe<br>
syscall nx lm<br>
constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf<br>
pni dtes64<br>
monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1<br>
lahf_lm<br>
dtherm tpr_shadow vnmi flexpriority<br>
bugs:<br>
bogomips: 4999.64<br>
clflush size: 64<br>
cache_alignment: 64<br>
address sizes: 36 bits physical, 48 bits virtual<br>
power management:<br>
<br>
<br>
<br>
cat /proc/interrupts<br>
CPU0 CPU1 CPU2 CPU3<br>
0: 132 0 0 0 IO-APIC<br>
2-edge<br>
timer<br>
1: 1 0 1 0 IO-APIC<br>
1-edge<br>
i8042<br>
8: 0 0 0 1 IO-APIC<br>
8-edge<br>
rtc0<br>
9: 0 0 0 0 IO-APIC<br>
9-fasteoi<br>
acpi<br>
12: 0 2 1 1 IO-APIC<br>
12-edge<br>
i8042<br>
16: 70849 70400 84763 74134 IO-APIC<br>
16-fasteoi<br>
uhci_hcd:usb3, snd_ice1712<br>
17: 7682775 7678025 7665199 7669368 IO-APIC<br>
17-fasteoi<br>
snd_ice1712, enp2s0<br>
18: 391807 398860 393361 405386 IO-APIC<br>
18-fasteoi<br>
ehci_hcd:usb1, uhci_hcd:usb5, uhci_hcd:usb8<br>
19: 213063 213252 212895 213142 IO-APIC<br>
19-fasteoi<br>
ata_piix, ata_piix, uhci_hcd:usb7, firewire_ohci<br>
21: 0 0 0 0 IO-APIC<br>
21-fasteoi<br>
uhci_hcd:usb4<br>
23: 910884 913622 912322 912878 IO-APIC<br>
23-fasteoi<br>
ehci_hcd:usb2, uhci_hcd:usb6<br>
27: 3989331 3982167 3990009 3981430 PCI-MSI<br>
524288-edge<br>
nvkm<br>
NMI: 11793 11536 11770 11499<br>
Non-maskable interrupts<br>
LOC: 25987631 29292447 20791378 19576474 Local<br>
timer interrupts<br>
SPU: 0 0 0 0 Spurious<br>
interrupts<br>
PMI: 11793 11536 11770 11499 Performance<br>
monitoring interrupts<br>
IWI: 1 2 0 0 IRQ work<br>
interrupts<br>
RTR: 0 0 0 0 APIC ICR<br>
read retries<br>
RES: 17114611 15588423 26439361 24596924<br>
Rescheduling interrupts<br>
CAL: 5808866 6203269 7499109 6750939 Function<br>
call interrupts<br>
TLB: 923613 903498 920749 891225 TLB<br>
shootdowns<br>
TRM: 0 0 0 0 Thermal<br>
event interrupts<br>
THR: 0 0 0 0 Threshold<br>
APIC interrupts<br>
DFR: 0 0 0 0 Deferred<br>
Error APIC<br>
interrupts<br>
MCE: 0 0 0 0 Machine<br>
check exceptions<br>
MCP: 282 282 282 282 Machine<br>
check polls<br>
ERR: 0<br>
MIS: 0<br>
PIN: 0 0 0 0<br>
Posted-interrupt<br>
notification event<br>
PIW: 0 0 0 0<br>
Posted-interrupt<br>
wakeup event<br>
<br>
<br>
BR Lassi<br>
<br>
<br>
_______________________________________________<br>
PlanetCCRMA mailing list<br>
<a href="mailto:PlanetCCRMA@ccrma.stanford.edu" target="_blank">PlanetCCRMA@ccrma.stanford.edu</a><br></div></div>
<mailto:<a href="mailto:PlanetCCRMA@ccrma.stanford.edu" target="_blank">PlanetCCRMA@ccrma.stanford.edu</a>><br>
<a href="https://cm-mail.stanford.edu/mailman/listinfo/planetccrma" rel="noreferrer" target="_blank">https://cm-mail.stanford.edu/mailman/listinfo/planetccrma</a><br>
<br>
<br>
<br>
<br>
</blockquote>
<br>
</div><br></div></div>