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