[LAD] PCI MIDI jitter - comparison Ubuntu (bad) and Suse (might be ok)
Hi :) today I compared a default Ubuntu Studio with and without the proprietary NVIDIA driver. Note that for Ubuntu Studio 2 tests failed because of time out errors, but even the tests that were passed with success are significantly less good, than the tests with openSUSE, were I set up audio myself. Ubuntu based Linux until now were my music Linux, e.g 64 Studio 3.0 and 3.3, but I wonder if bad MIDI latency is depending to Ubuntu. For Ubuntu Studio even PCI MIDI has got more jitter, but USB MIDI for Suse, see older test in the archives. What might be the difference between Ubuntu and Suse? Could anybody compare different distros too? Ubuntu Studio 10.04 amd64 2 x Terratec EWX 24/96 (2 single cards, but 1 virtual card) Frequency scaling ? spinymo...@ubuntu:~$ hwinfo --gfxcard Driver: nouveau Driver Modules: drm IRQ: 18 spinymo...@ubuntu:~$ alsa-midi-latency-test -l PortClient name Port name 14:0Midi Through Midi Through Port-0 16:0TerraTec EWX24/96TerraTec EWX24/96 MIDI 20:0TerraTec EWX24/96TerraTec EWX24/96 MIDI 128:0TiMidity TiMidity port 0 128:1TiMidity TiMidity port 1 128:2TiMidity TiMidity port 2 128:3TiMidity TiMidity port 3 spinymo...@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o20:0 -i20:0 alsa-midi-latency-test 0.0.3 set_realtime_priority(SCHED_FIFO, 99).. done. clock resolution: 0.1 s SUCCESS best latency was 1.00 ms worst latency was 1.97 ms, which is great. spinymo...@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o20:0 -i20:0 alsa-midi-latency-test 0.0.3 set_realtime_priority(SCHED_FIFO, 99).. done. clock resolution: 0.1 s SUCCESS best latency was 1.00 ms worst latency was 3.36 ms, which is great. spinymo...@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o16:0 -i16:0 alsa-midi-latency-test 0.0.3 set_realtime_priority(SCHED_FIFO, 99).. done. clock resolution: 0.1 s SUCCESS best latency was 0.99 ms worst latency was 1.93 ms, which is great. spinymo...@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o16:0 -i16:0 alsa-midi-latency-test 0.0.3 set_realtime_priority(SCHED_FIFO, 99).. done. clock resolution: 0.1 s SUCCESS best latency was 0.99 ms worst latency was 1.74 ms, which is great. spinymo...@ubuntu:~$ uname -a Linux ubuntu 2.6.32-23-preempt #37-Ubuntu SMP PREEMPT Fri Jun 11 10:19:07 UTC 2010 x86_64 GNU/Linux spinymo...@ubuntu:~$ envy24control 0xcf00, irq 20, Master Clock int 44100 No envy24control for 0xcb00, irq 21, Master Clock ? 20:0 opto S/PDIF out -- 16:00 opto S/PDIF in Ubuntu Studio 10.04 amd64 2 x Terratec EWX 24/96 (2 single cards, but 1 virtual card) Frequency scaling ? spinymo...@ubuntu:~$ hwinfo --gfxcard Driver: nvidia Driver Modules: nvidia IRQ: 18 spinymo...@ubuntu:~$ alsa-midi-latency-test -l PortClient name Port name 14:0Midi Through Midi Through Port-0 16:0TerraTec EWX24/96TerraTec EWX24/96 MIDI 20:0TerraTec EWX24/96TerraTec EWX24/96 MIDI 128:0TiMidity TiMidity port 0 128:1TiMidity TiMidity port 1 128:2TiMidity TiMidity port 2 128:3TiMidity TiMidity port 3 pinymo...@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o20:0 -i20:0 alsa-midi-latency-test 0.0.3 set_realtime_priority(SCHED_FIFO, 99).. done. clock resolution: 0.1 s SUCCESS best latency was 1.00 ms worst latency was 1.84 ms, which is great. spinymo...@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o20:0 -i20:0 alsa-midi-latency-test 0.0.3 set_realtime_priority(SCHED_FIFO, 99).. done. clock resolution: 0.1 s SUCCESS best latency was 1.00 ms worst latency was 1.27 ms, which is great. spinymo...@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o16:0 -i16:0 alsa-midi-latency-test 0.0.3 set_realtime_priority(SCHED_FIFO, 99).. done. clock resolution: 0.1 s SUCCESS best latency was 0.99 ms worst latency was 1.92 ms, which is great. spinymo...@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o16:0 -i16:0 alsa-midi-latency-test 0.0.3 set_realtime_priority(SCHED_FIFO, 99).. done. clock resolution: 0.1 s SUCCESS best latency was 0.99 ms worst latency was 1.72 ms, which is great. spinymo...@ubuntu:~$ uname -a Linux ubuntu 2.6.32-23-preempt #37-Ubuntu SMP PREEMPT Fri Jun 11 10:19:07 UTC 2010 x86_64 GNU/Linux spinymo...@ubuntu:~$ envy24control 0xcf00, irq 20, Master Clock int 44100 No envy24control for 0xcb00, irq 21, Master Clock ? 20:0 opto
Re: [LAD] PCI MIDI jitter - comparison Ubuntu (bad) and Suse (might be ok)
Hi Ralf, You are comparing a banana and an orange to find out which one is sweeter. Given the nature of the problem it would help a lot to have as little differences between the systems under test, otherwise it's impossible to track it down. I hazard a guess that it's Ubuntu's 2.6.32 realtime-preemt-kernel. There are no official 2.6.32 rt-patches and it's likely that some of the back/forward ports have screwed things up. Is 'cat /proc/interrupts' identical on both systems? what about 'ps ax | wc -l' and 'ps -eo pid,class,rtprio,ni,pri,pcpu,stat,comm --sort -rtprio' Are there high-priority jobs present on Ubuntu which are not on SuSE? What happens if you use the same kernel (SuSE's kernel on Ubuntu, or vice versa) but different disto user-lands? Is there still a difference in your measurements? ciao, robin On 07/11/2010 04:53 PM, Ralf Mardorf wrote: Hi :) today I compared a default Ubuntu Studio with and without the proprietary NVIDIA driver. Note that for Ubuntu Studio 2 tests failed because of time out errors, but even the tests that were passed with success are significantly less good, than the tests with openSUSE, were I set up audio myself. Ubuntu based Linux until now were my music Linux, e.g 64 Studio 3.0 and 3.3, but I wonder if bad MIDI latency is depending to Ubuntu. For Ubuntu Studio even PCI MIDI has got more jitter, but USB MIDI for Suse, see older test in the archives. What might be the difference between Ubuntu and Suse? Could anybody compare different distros too? Ubuntu Studio 10.04 amd64 2 x Terratec EWX 24/96 (2 single cards, but 1 virtual card) Frequency scaling ? spinymo...@ubuntu:~$ hwinfo --gfxcard Driver: nouveau Driver Modules: drm IRQ: 18 spinymo...@ubuntu:~$ alsa-midi-latency-test -l PortClient name Port name 14:0Midi Through Midi Through Port-0 16:0TerraTec EWX24/96TerraTec EWX24/96 MIDI 20:0TerraTec EWX24/96TerraTec EWX24/96 MIDI 128:0TiMidity TiMidity port 0 128:1TiMidity TiMidity port 1 128:2TiMidity TiMidity port 2 128:3TiMidity TiMidity port 3 spinymo...@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o20:0 -i20:0 alsa-midi-latency-test 0.0.3 set_realtime_priority(SCHED_FIFO, 99).. done. clock resolution: 0.1 s SUCCESS best latency was 1.00 ms worst latency was 1.97 ms, which is great. spinymo...@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o20:0 -i20:0 alsa-midi-latency-test 0.0.3 set_realtime_priority(SCHED_FIFO, 99).. done. clock resolution: 0.1 s SUCCESS best latency was 1.00 ms worst latency was 3.36 ms, which is great. spinymo...@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o16:0 -i16:0 alsa-midi-latency-test 0.0.3 set_realtime_priority(SCHED_FIFO, 99).. done. clock resolution: 0.1 s SUCCESS best latency was 0.99 ms worst latency was 1.93 ms, which is great. spinymo...@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o16:0 -i16:0 alsa-midi-latency-test 0.0.3 set_realtime_priority(SCHED_FIFO, 99).. done. clock resolution: 0.1 s SUCCESS best latency was 0.99 ms worst latency was 1.74 ms, which is great. spinymo...@ubuntu:~$ uname -a Linux ubuntu 2.6.32-23-preempt #37-Ubuntu SMP PREEMPT Fri Jun 11 10:19:07 UTC 2010 x86_64 GNU/Linux spinymo...@ubuntu:~$ envy24control 0xcf00, irq 20, Master Clock int 44100 No envy24control for 0xcb00, irq 21, Master Clock ? 20:0 opto S/PDIF out -- 16:00 opto S/PDIF in Ubuntu Studio 10.04 amd64 2 x Terratec EWX 24/96 (2 single cards, but 1 virtual card) Frequency scaling ? spinymo...@ubuntu:~$ hwinfo --gfxcard Driver: nvidia Driver Modules: nvidia IRQ: 18 spinymo...@ubuntu:~$ alsa-midi-latency-test -l PortClient name Port name 14:0Midi Through Midi Through Port-0 16:0TerraTec EWX24/96TerraTec EWX24/96 MIDI 20:0TerraTec EWX24/96TerraTec EWX24/96 MIDI 128:0TiMidity TiMidity port 0 128:1TiMidity TiMidity port 1 128:2TiMidity TiMidity port 2 128:3TiMidity TiMidity port 3 pinymo...@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o20:0 -i20:0 alsa-midi-latency-test 0.0.3 set_realtime_priority(SCHED_FIFO, 99).. done. clock resolution: 0.1 s SUCCESS best latency was 1.00 ms worst latency was 1.84 ms, which is great. spinymo...@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o20:0 -i20:0
Re: [LAD] PCI MIDI jitter - comparison Ubuntu (bad) and Suse (might be ok)
Hi Robin :) On Sun, 2010-07-11 at 17:11 +0200, Robin Gareus wrote: Hi Ralf, You are comparing a banana and an orange to find out which one is sweeter. Given the nature of the problem it would help a lot to have as little differences between the systems under test, otherwise it's impossible to track it down. I hazard a guess that it's Ubuntu's 2.6.32 realtime-preemt-kernel. There are no official 2.6.32 rt-patches and it's likely that some of the back/forward ports have screwed things up. Good argument! OTOH an audio distro shouldn't use a kernel that will increase latency. I'll build 2.6.31.6-rt19 for Ubuntu Studio, btw. I had this kernel for 64 Studio too, but only in combination with USB MIDI. Is 'cat /proc/interrupts' identical on both systems? what about 'ps ax | wc -l' and 'ps -eo pid,class,rtprio,ni,pri,pcpu,stat,comm --sort -rtprio' Are there high-priority jobs present on Ubuntu which are not on SuSE? I dunno, I'll run those commands and post them later, building a kernel will take some time. To be continued. Ralf What happens if you use the same kernel (SuSE's kernel on Ubuntu, or vice versa) but different disto user-lands? Is there still a difference in your measurements? ciao, robin On 07/11/2010 04:53 PM, Ralf Mardorf wrote: Hi :) today I compared a default Ubuntu Studio with and without the proprietary NVIDIA driver. Note that for Ubuntu Studio 2 tests failed because of time out errors, but even the tests that were passed with success are significantly less good, than the tests with openSUSE, were I set up audio myself. Ubuntu based Linux until now were my music Linux, e.g 64 Studio 3.0 and 3.3, but I wonder if bad MIDI latency is depending to Ubuntu. For Ubuntu Studio even PCI MIDI has got more jitter, but USB MIDI for Suse, see older test in the archives. What might be the difference between Ubuntu and Suse? Could anybody compare different distros too? Ubuntu Studio 10.04 amd64 2 x Terratec EWX 24/96 (2 single cards, but 1 virtual card) Frequency scaling ? spinymo...@ubuntu:~$ hwinfo --gfxcard Driver: nouveau Driver Modules: drm IRQ: 18 spinymo...@ubuntu:~$ alsa-midi-latency-test -l PortClient name Port name 14:0Midi Through Midi Through Port-0 16:0TerraTec EWX24/96TerraTec EWX24/96 MIDI 20:0TerraTec EWX24/96TerraTec EWX24/96 MIDI 128:0TiMidity TiMidity port 0 128:1TiMidity TiMidity port 1 128:2TiMidity TiMidity port 2 128:3TiMidity TiMidity port 3 spinymo...@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o20:0 -i20:0 alsa-midi-latency-test 0.0.3 set_realtime_priority(SCHED_FIFO, 99).. done. clock resolution: 0.1 s SUCCESS best latency was 1.00 ms worst latency was 1.97 ms, which is great. spinymo...@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o20:0 -i20:0 alsa-midi-latency-test 0.0.3 set_realtime_priority(SCHED_FIFO, 99).. done. clock resolution: 0.1 s SUCCESS best latency was 1.00 ms worst latency was 3.36 ms, which is great. spinymo...@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o16:0 -i16:0 alsa-midi-latency-test 0.0.3 set_realtime_priority(SCHED_FIFO, 99).. done. clock resolution: 0.1 s SUCCESS best latency was 0.99 ms worst latency was 1.93 ms, which is great. spinymo...@ubuntu:~$ alsa-midi-latency-test -Rrw=2 -o16:0 -i16:0 alsa-midi-latency-test 0.0.3 set_realtime_priority(SCHED_FIFO, 99).. done. clock resolution: 0.1 s SUCCESS best latency was 0.99 ms worst latency was 1.74 ms, which is great. spinymo...@ubuntu:~$ uname -a Linux ubuntu 2.6.32-23-preempt #37-Ubuntu SMP PREEMPT Fri Jun 11 10:19:07 UTC 2010 x86_64 GNU/Linux spinymo...@ubuntu:~$ envy24control 0xcf00, irq 20, Master Clock int 44100 No envy24control for 0xcb00, irq 21, Master Clock ? 20:0 opto S/PDIF out -- 16:00 opto S/PDIF in Ubuntu Studio 10.04 amd64 2 x Terratec EWX 24/96 (2 single cards, but 1 virtual card) Frequency scaling ? spinymo...@ubuntu:~$ hwinfo --gfxcard Driver: nvidia Driver Modules: nvidia IRQ: 18 spinymo...@ubuntu:~$ alsa-midi-latency-test -l PortClient name Port name 14:0Midi Through Midi Through Port-0 16:0TerraTec EWX24/96TerraTec EWX24/96 MIDI 20:0TerraTec EWX24/96TerraTec EWX24/96 MIDI 128:0TiMidity TiMidity port
Re: [LAD] PCI MIDI jitter - comparison Ubuntu (bad) and Suse (might be ok)
On Sun, Jul 11, 2010 at 04:53:14PM +0200, Ralf Mardorf wrote: today I compared a default Ubuntu Studio with and without the proprietary NVIDIA driver. OK, so the proprietary driver seems to yield better 'worst latency' values compared to nouveau. That's kind of odd, anything X-related would have a much lower priority than the MIDI threads. Note that for Ubuntu Studio 2 tests failed because of time out errors What exactly timed out? even the tests that were passed with success are significantly less good, than the tests with openSUSE, were I set up audio myself. What might be the difference between Ubuntu and Suse? Ubuntu Studio 10.04 amd64 2 x Terratec EWX 24/96 (2 single cards, but 1 virtual card) Frequency scaling ? spinymo...@ubuntu:~$ uname -a Linux ubuntu 2.6.32-23-preempt #37-Ubuntu SMP PREEMPT Fri Jun 11 10:19:07 UTC 2010 x86_64 GNU/Linux spinymo...@ubuntu:~$ envy24control 0xcf00, irq 20, Master Clock int 44100 openSUSE 11.2 amd64 2 x Terratec EWX 24/96 (2 single cards, but 1 virtual card) Frequency scaling performance spinymouse1...@suse11-2:~ uname -a Linux suse11-2 2.6.31.6-rt19 #1 SMP PREEMPT RT Wed Nov 18 16:59:26 CET 2009 x86_64 x86_64 x86_64 GNU/Linux 2 differences jump out: - the frequency scaling is set to 'performance' on your suse install and to '?' on your ubuntu install. - The kernel options for your suse install has the options 'SMP PREEMPT RT', while your ubuntu install has the options 'SMP PREEMPT'. In other words, it looks like your ubuntu kernel has 'normal' preemption, but not the -rt patch. The latter looks like a good candidate for explaining the difference. Could you test with the kernel from the linux-image-2.6.31-10-rt package instead of the kernel from the linux-image-2.6.32-21-preempt package which you seem to be using now? Kind regards, Arnout ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] PCI MIDI jitter - comparison Ubuntu (bad) and Suse (might be ok)
On Sun, 2010-07-11 at 17:21 +0200, Arnout Engelen wrote: On Sun, Jul 11, 2010 at 04:53:14PM +0200, Ralf Mardorf wrote: today I compared a default Ubuntu Studio with and without the proprietary NVIDIA driver. OK, so the proprietary driver seems to yield better 'worst latency' values compared to nouveau. That's kind of odd, anything X-related would have a much lower priority than the MIDI threads. Note that for Ubuntu Studio 2 tests failed because of time out errors What exactly timed out? There was a time out message by the alsa-midi-latency-test. It started and than it asked, if there still is a connection, while there still was a connection. even the tests that were passed with success are significantly less good, than the tests with openSUSE, were I set up audio myself. What might be the difference between Ubuntu and Suse? Ubuntu Studio 10.04 amd64 2 x Terratec EWX 24/96 (2 single cards, but 1 virtual card) Frequency scaling ? spinymo...@ubuntu:~$ uname -a Linux ubuntu 2.6.32-23-preempt #37-Ubuntu SMP PREEMPT Fri Jun 11 10:19:07 UTC 2010 x86_64 GNU/Linux spinymo...@ubuntu:~$ envy24control 0xcf00, irq 20, Master Clock int 44100 openSUSE 11.2 amd64 2 x Terratec EWX 24/96 (2 single cards, but 1 virtual card) Frequency scaling performance spinymouse1...@suse11-2:~ uname -a Linux suse11-2 2.6.31.6-rt19 #1 SMP PREEMPT RT Wed Nov 18 16:59:26 CET 2009 x86_64 x86_64 x86_64 GNU/Linux 2 differences jump out: - the frequency scaling is set to 'performance' on your suse install and to '?' on your ubuntu install. Yes, I assume that an audio distro won't start with ondemand by default, I'll run hwinfo to see the scaling next time. For Ubuntu Studio there are a lot of issues that are nwe to me, no xorg.conf, no menu.lst etc.. - The kernel options for your suse install has the options 'SMP PREEMPT RT', while your ubuntu install has the options 'SMP PREEMPT'. In other words, it looks like your ubuntu kernel has 'normal' preemption, but not the -rt patch. I didn't noticed that, you're right. The Suse kernel is self build, the Ubuntu Studio kernel is from the repositories. The latter looks like a good candidate for explaining the difference. Could you test with the kernel from the linux-image-2.6.31-10-rt package instead of the kernel from the linux-image-2.6.32-21-preempt package which you seem to be using now? Thank you, a good idea, before I'll build a kernel by myself, it would take around 50 minutes, I'll install this kernel from the repository. To be continued. Ralf Kind regards, Arnout ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] PCI MIDI jitter - comparison Ubuntu (bad) and Suse (might be ok)
On 07/11/2010 05:18 PM, Ralf Mardorf wrote: Hi Robin :) On Sun, 2010-07-11 at 17:11 +0200, Robin Gareus wrote: Hi Ralf, You are comparing a banana and an orange to find out which one is sweeter. Given the nature of the problem it would help a lot to have as little differences between the systems under test, otherwise it's impossible to track it down. I hazard a guess that it's Ubuntu's 2.6.32 realtime-preemt-kernel. There are no official 2.6.32 rt-patches and it's likely that some of the back/forward ports have screwed things up. Good argument! OTOH an audio distro shouldn't use a kernel that will increase latency. I'll build 2.6.31.6-rt19 for Ubuntu Studio, btw. I had this kernel for 64 Studio too, but only in combination with USB MIDI. Is 'cat /proc/interrupts' identical on both systems? what about 'ps ax | wc -l' and 'ps -eo pid,class,rtprio,ni,pri,pcpu,stat,comm --sort -rtprio' Are there high-priority jobs present on Ubuntu which are not on SuSE? I dunno, I'll run those commands and post them later, building a kernel will take some time. The whole output of 'ps -eo...' will be tooo long. Just have a look and check for high priority processes that are different on both systems. If you have rtirq installed: '/etc/init.d/rtirq status' will show the same list but only display processes with RTPRIO set. Oh and I missed that the Ubuntu's 2.6.32.XX is actually not a rt-preemt kernel. many thanks to Arnout to spot that. If there's still a difference between SuSe Ubuntu using the identical kernel, with no significant high-priority processes: please post the version of the alsa-libs for both systems. Not sure if it has been mentioned before, but you should set your soundcard's IRQ handler priority to sth high (eg 90) and use '-P 89' with alsa-midi-latency-test. With the default of -P 99 the kernel will always end up inverting priorities to run it (the overhead for doing so is low but it may still be relevant). Thanks for being persistent on the Midi Jitter issue. Some of that info is bound to come in handy.. ciao, robin ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] PCI MIDI jitter - comparison Ubuntu (bad) and Suse (might be ok)
On Sun, 2010-07-11 at 18:07 +0200, Robin Gareus wrote:
The whole output of 'ps -eo...' will be tooo long. Just have a look
and check for high priority processes that are different on both systems.
If you have rtirq installed: '/etc/init.d/rtirq status' will show the
same list but only display processes with RTPRIO set.
Oh and I missed that the Ubuntu's 2.6.32.XX is actually not a rt-preemt
kernel. many thanks to Arnout to spot that.
If there's still a difference between SuSe Ubuntu using the identical
kernel, with no significant high-priority processes: please post the
version of the alsa-libs for both systems.
Not sure if it has been mentioned before, but you should set your
soundcard's IRQ handler priority to sth high (eg 90) and use '-P 89'
with alsa-midi-latency-test.
With the default of -P 99 the kernel will always end up inverting
priorities to run it (the overhead for doing so is low but it may still
be relevant).
Thanks for being persistent on the Midi Jitter issue. Some of that info
is bound to come in handy..
ciao,
robin
When I booted Ubuntustudio I didn't get this mail, so here is what I did
before I read your mail.
The blame is on Ubuntustudio.
Ubuntustudio by default isn't able to do rt! Changing the defaults seems
to be not that easy!
What an odd distro!
I did check the md5sum for the Ubuntustudio ISO and K3b did verify the
burned DVD, everything was ok.
openSUSE 11.2
suse11-2:/media/ubuntu_s_home/spinymouse/Desktop # cat /proc/interrupts
suse_proc_irqs.txt
suse11-2:/media/ubuntu_s_home/spinymouse/Desktop # ps ax | wc -l
186
suse11-2:/media/ubuntu_s_home/spinymouse/Desktop # ps -eo
pid,class,rtprio,ni,pri,pcpu,stat,comm --sort -rtprio
suse_job_prio.txt
Ubuntu Studio 10.04
1.
For Ubuntu Studio by default frequency scaling isn't performance.
Fortunately 'cpufreq-selector -g performance' does the job, but it must
be finished by Ctrl + C.
2.
If I try to boot kernel 2.6.31-11-rt or kernel 2.6.31-10-rt from the
repositories I get
'mount: mounting none on /dev failed: No such device.' Regading to the
web this might be, because of CONFIG_DEVTMPFS.
3.
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
3 FF 99 - 139 0.0 S migration/0
13 FF 99 - 139 0.0 S posixcputmr/0
14 FF 99 - 139 0.0 S watchdog/0
16 FF 99 - 139 0.0 S migration/1
17 FF 99 - 139 0.0 S posixcputmr/1
27 FF 99 - 139 0.0 S watchdog/1
83 FF 90 - 130 0.0 S irq/8-rtc0
655 FF 85 - 125 0.0 S irq/21-ICE1712
653 FF 84 - 124 0.0 S irq/20-ICE1712
for Suse vs
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
3 FF 99 - 139 0.0 Smigration/0
5 FF 99 - 139 0.0 Swatchdog/0
6 FF 99 - 139 0.0 Smigration/1
8 FF 99 - 139 0.0 Swatchdog/1
1 TS - [...]
for Ubuntu.
r...@ubuntu:~# hwinfo --cpu
Model: 15.107.2 AMD Athlon(tm) X2 Dual Core Processor BE-2350
Clock: 1000 MHz
r...@ubuntu:~# cpufreq-selector -g performance
^C
r...@ubuntu:~# hwinfo --cpu
Model: 15.107.2 AMD Athlon(tm) X2 Dual Core Processor BE-2350
Clock: 2100 MHz
r...@ubuntu:~# ps ax | wc -l
152
r...@ubuntu:~# cd /home/spinymouse/Desktop
r...@ubuntu:/home/spinymouse/Desktop# cat /proc/interrupts
ubuntustudio_proc_irqs.txt
r...@ubuntu:/home/spinymouse/Desktop# ps ax | wc -l
151
r...@ubuntu:/home/spinymouse/Desktop# ps ax | wc -l
151
r...@ubuntu:/home/spinymouse/Desktop# ps -eo
pid,class,rtprio,ni,pri,pcpu,stat,comm --sort -rtprio
ubuntustudio_job_prio.txt
r...@ubuntu:/home/spinymouse/Desktop# cat /boot/grub/grub.cfg
menuentry 'Ubuntu, with Linux 2.6.32-23-preempt' --class ubuntu --class
gnu-linux --class gnu --class os {
recordfail
insmod ext2
set root='(hd1,11)'
search --no-floppy --fs-uuid --set 54b5bb8c-356a-4268-8592-e76aac7941a8
linux /boot/vmlinuz-2.6.32-23-preempt
root=UUID=54b5bb8c-356a-4268-8592-e76aac7941a8 ro quiet splash
initrd /boot/initrd.img-2.6.32-23-preempt
}
menuentry 'Ubuntu, with Linux 2.6.32-21-preempt' --class ubuntu --class
gnu-linux --class gnu --class os {
recordfail
insmod ext2
set root='(hd1,11)'
search --no-floppy --fs-uuid --set 54b5bb8c-356a-4268-8592-e76aac7941a8
linux /boot/vmlinuz-2.6.32-21-preempt
root=UUID=54b5bb8c-356a-4268-8592-e76aac7941a8 ro quiet splash
initrd /boot/initrd.img-2.6.32-21-preempt
}
menuentry 'Ubuntu, with Linux 2.6.31-11-rt' --class ubuntu --class
gnu-linux --class gnu --class os {
recordfail
insmod ext2
set root='(hd1,11)'
search --no-floppy --fs-uuid --set
Re: [LAD] PCI MIDI jitter - comparison Ubuntu (bad) and Suse (might be ok)
On Sun, Jul 11, 2010 at 7:53 AM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: I'll test what happens if two sound cards become one virtual sound card, http://www.jrigg.co.uk/linuxaudio/ice1712multi.html and before doing this I need to test if the second, new second hand card from Ebay isn't broken for audio, resp. I'll compare the sound quality for my old and the new Terratec EWX 24/96 sound card, before they become one virtual sound card. If you're planning on bridging the audio portions of two 1712-based cards (pref of same manufacturer, like you're doing) then also be sure to interconnect the SPDIF inputs in order to make sure the audio portions of the cards stay in sync. And make one card slave it's clock off the spdif out of the other... Which means you still only have one spdif input and output remaining despite the two cards. FYI -- the technique makes a lot more sense if you have to delta 1010's w/ the high-quality ADC's and the external breakout box (he says in theory, not owning a 1010, but accepting all donations! (RME's too!) :-) )... great if you need to build a cheap 16ins/outs digital mixer with a computerlinux thrown in for free. With the EWX 24/96 -- you're probably better following the suggestion from http://lalists.stanford.edu/lau/2010/06/0875.html and http://lalists.stanford.edu/lau/2010/06/0827.html :-) Otherwise, my understanding is that the bridging allows for IRQ sharing between the cards. Hopefully the ALSA drivers properly support this feature, although I'd imagine it's just an entailment of whichever 1712 is the bus-master at the time, hanging on to the bus for it's preallocated slot of time before relinquishing it and allowing the next IRQ to be handled. The BIOS could be getting in the way as well: http://alsa.opensrc.org/index.php/Ice1712#User_comments Note that bus-mastering flies in the face of hard realtime... but it's really just a matter of having your realtime requirements being in a slower time dimension than your PCI bus and CPU and having all your potential bus masters, including your disobedient graphics card -- following the rules of the bus. However, as bus speeds increase, and CPU's perform the computations necessitated by the data w/o inducing any waits or contention for other processing, then realtime will be easy no matter whether it be realtime for audio needs, or realtime for video needs basically, as processing and bus speeds tend towards infinity, realtime will just be a matter of not programing in a totally stupid fashion. http://en.wikipedia.org/wiki/Bus_mastering .. Some types of bus allow only one device (typically the CPU, or its proxy) to initiate transactions. Most modern bus architectures, including PCI, allow multiple devices to bus master because it significantly improves performance for general purpose operating systems. Some real-time operating systems prohibit peripherals from becoming bus masters, because the scheduler can no longer arbitrate for the bus and hence cannot provide deterministic latency. .. This is also most likely what is causing failures in your setup. Your Nvidia card is hogging the PCI bus and hanging on for longer than it should, and your audio devices, be they 1712-based, or USB can't do anything about it but wait for your graphics card to stop hogging. You might find a new cheap video card could solve all your issues if you're not planning on playing games, or decoding/watching HD video, one that simply has good X windows acceleration, which is probably perfectly well supported on graphics cards people are otherwise throwing away because they won't play some FPS at a high framerate... And if you want http://en.wikipedia.org/wiki/VDPAU for video, perhaps something like a 9500gt or GT220 may be sufficient. random googles: http://thegreenbutton.com/forums/p/84249/420889.aspx http://www.rme-audio.de/english/techinfo/nforce4_tests.htm Are you running desktop effects? Turn that ^%^(*) off!! -- Niels. http://nielsmayer.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] PCI MIDI jitter - comparison Ubuntu (bad) and Suse (might be ok)
I don't run desktop effects, obscure deamons, screen savers, firewalls and there are no USB devices connected etc.. The NVIDIA 7200 GS already is a replacement for the ATI Radeon X1250, I'm not able to buy a new card all the times and the issues don't seem to be caused by the graphics, but e.g. for Ubuntu Studio, because of a bad kernel, without rt patch. Perhaps I should set up the prio for the sound cards for my other Linuxes, to maybe get less then 1ms jitter. Note, for PCI I do have around 1ms jitter and for the USB device around 2ms jitter if the Linux is set up correctly, but at least 2ms jitter (USB) are too much, perhaps 1ms (PCI) is ok. Yes, opto S/PDIF out already is connected to the other card's opto S/PDIF in, but they still are two separated cards and I didn't edit master clock. It's just for testing purpose, that I'll try to make them one virtual card, because I much more would like to use one card for audio, but by using the good sound quality AD/DA converters from one of my DATs via S/PDIF. The second sound card should be just to support a second separated MIDI output. This howto, http://www.jrigg.co.uk/linuxaudio/ice1712multi.html , is less confusing, why isn't it good for my Envy24 cards? On the quick I couldn't find a howto among your links. Thanx, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] PCI MIDI jitter - comparison Ubuntu (bad) and Suse (might be ok)
On Sun, Jul 11, 2010 at 11:36 AM, Ralf Mardorf ralf.mard...@alice-dsl.net wrote: This howto, http://www.jrigg.co.uk/linuxaudio/ice1712multi.html , is less confusing, why isn't it good for my Envy24 cards? On the quick I couldn't find a howto among your links. It's perfectly fine for the 1712, and the audio sync probably has nothing to do with midi jitter. It's just that your 1712 has few inputs to bridge, although two pairs is better than one... it is ultimately an AC97 codec which may or may not give you the audio results you want., and may behave differently at 44.1k than 48k as AC97 runs at 48k, and perhaps, resampling could be involved running at other rates. -- Niels http://nielsmayer.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] PCI MIDI jitter - comparison Ubuntu (bad) and Suse (might be ok)
On Sun, 2010-07-11 at 12:02 -0700, Niels Mayer wrote:
It's perfectly fine for the 1712, and the audio sync probably has
nothing to do with midi jitter.
Yep, I just wanted to underline that at the moment this are two cards,
but one virtual.
Unfortunately no kernel-rt is boot-able for my Ubuntu Studio 10.04. If
64 Studio isn't continued, I don't know any good DEB based audio Linux
for 64-bit architecture. AV Linux seems to be good, but is released only
as i386.
Hm, perhaps OT for this list:
I wonder if anybody run Ubuntustudio 10.04 with a kernel-rt.
Building a kernel failed.
And all kernel-rt from the repositories failed.
$ cd /usr/src
$ sudo synaptic
I checked if those packages were installed:
bin86
build-essential
bzip2
fakeroot
gcc
kernel-package
make
libncurses5-dev
$ wget ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.33.5.tar.bz2
$ wget
http://www.kernel.org/pub/linux/kernel/projects/rt/patch-2.6.33.5-rt23.bz2
$ tar xvjf linux-2.6.33.5.tar.bz2
$ rm linux-2.6.33.5.tar.bz2
$ mv linux-2.6.33.5 linux-2.6.33.5-rt23
$ ln -s linux-2.6.33.5-rt23 linux
$ cd linux
$ bunzip2 ../patch-2.6.33.5-rt23.bz2
$ patch -p1 ../patch-2.6.33.5-rt23
$ rm ../patch-2.6.33.5-rt23
$ cp /boot/config-2.6.32-23-preempt .config
$ make oldconfig
81 x Enter
$ make menuconfig
Edited from Generic-x86-64 to Opteron/Athlon64/Hammer/K8
Save an Alternate Configuration File
$ make oldconfig
Nothing to do
$ make-kpkg clean
$ export CONCURRENCY_LEVEL=2
This didn't work:
$ make-kpkg --rootcmd fakeroot --initrd kernel-image kernel-headers
kernel-source
50 minutes later
make[5]: *** [drivers/staging/comedi/drivers/quatech_daqp_cs.o]
Error 1
make[4]: *** [drivers/staging/comedi/drivers] Error 2
Hence I edited .config:
$ cat .config | grep COMEDI
CONFIG_COMEDI=m
# CONFIG_COMEDI_DEBUG is not set
CONFIG_COMEDI_PCI_DRIVERS=m
CONFIG_COMEDI_PCMCIA_DRIVERS=m
CONFIG_COMEDI_USB_DRIVERS=m
$ gedit .config
$ cat .config | grep COMEDI
# CONFIG_COMEDI is not set
# CONFIG_COMEDI_DEBUG is not set
# CONFIG_COMEDI_PCI_DRIVERS is not set
# CONFIG_COMEDI_PCMCIA_DRIVERS is not set
# CONFIG_COMEDI_USB_DRIVERS is not set
$ make oldconfig
Nothing to do
$ make-kpkg clean
$ make-kpkg --rootcmd fakeroot --initrd kernel-image kernel-headers
kernel-source
Another 50 minutes later
make[4]: *** [drivers/staging/pohmelfs/inode.o] Error 1
make[3]: *** [drivers/staging/pohmelfs] Error 2
Hence I edited .config:
$ cat .config | grep POHMEL
CONFIG_POHMELFS=m
# CONFIG_POHMELFS_DEBUG is not set
CONFIG_POHMELFS_CRYPTO=y
$ gedit .config
$ cat .config | grep POHMEL
# CONFIG_POHMELFS is not set
# CONFIG_POHMELFS_DEBUG is not set
# CONFIG_POHMELFS_CRYPTO is not set
$ make oldconfig
Nothing to do
$ make-kpkg clean
Here it is ok:
$ make-kpkg --rootcmd fakeroot --initrd kernel-image kernel-headers
kernel-source
80 minutes later
$ cd ..
$ sudo dpkg -i
linux-image-2.6.33.5-rt23_2.6.33.5-rt23-10.00.Custom_amd64.deb
When I tried to boot the kernel I got
'[0.499322] ACPI: Expecting a [Reference] package element, found
type 0
[0.811991] kernel panic - not syncing: VPS: Unable to mount root fs
on unknown-block (0,0)'
For the entry in grub.cfg initrd is missing:
menuentry 'Ubuntu, with Linux 2.6.33.5-rt23' --class ubuntu --class
gnu-linux --class gnu --class os {
recordfail
insmod ext2
set root='(hd1,11)'
search --no-floppy --fs-uuid --set 54b5bb8c-356a-4268-8592-e76aac7941a8
linux /boot/vmlinuz-2.6.33.5-rt23 root=/dev/sdb11 ro quiet splash
}
Unfortunately initrd is missing too:
$ ls /boot/initrd*
/boot/initrd.img-2.6.32-23-preempt
$ ls /boot
abi-2.6.32-23-preempt grub
System.map-2.6.32-23-preempt vmlinuz-2.6.32-23-preempt
config-2.6.32-23-preempt initrd.img-2.6.32-23-preempt
System.map-2.6.33.5-rt23 vmlinuz-2.6.33.5-rt23
config-2.6.33.5-rt23 memtest86+.bin
'Kernels
* Amd64
-generic will be installed if ubuntustudio-audio meta is NOT selected
during installation process
-preempt kernel will be installed if ubuntustudo-audio meta IS selected
during installation process
-lowlatency kernel is also available in Abogani's PPA -
https://launchpad.net/~abogani/+archive/ppa
-realtime kernel will be available in Ubuntu Studio PPA'
http://ubuntustudio.org/LucidLynx
So I added 'deb http://ppa.launchpad.net/abogani/ppa/ubuntu lucid main'
and
'deb-src http://ppa.launchpad.net/abogani/ppa/ubuntu lucid main'. Then I
installed the rt kernel from this repository.
When I try to boot kernel 2.6.33-23-realtime from the repository I get
'ACPI: Expecting a [Reference] package element, found type 0'
