From: Tomasz G. <tgr...@gm...> - 2008-08-18 14:42:48
|
Hello! I'm writing to the mailing list about xruns because I get them ONLY when I try to use Rosegarden. My OS is: Debian (unstable) with kernel 2.6.24.7 + real time patches (-rt17) applied; software raid1 is used for all partitions. Hardware is AMD64 x2 6400+, 4 GB RAM, and Edirol FA-66 as the sound unit. I usually start QSynth (witch four engines), ZynAddSubFX, Hydrogen, Muse, Ardour, and JACK in the following way: jackd -R -P70 -t2000 -dfreebob -dhw:0 -r48000 -p128 -n3 -D Then I have no issues, I can work for several hours without an xrun. But when I try to use Rosegarden instead of Muse, I start getting xruns, more less one per a minute. It happens to hear a click/crackle then (not at every xrun), and additionally Rosegarden somehow looses its synchronization (or BPM measurement, I don't know how to call it), and starts playing noticeably slower - for example, Hydrogen starts playing a beat at 57th bar while Rosegarden reaches a 50th bar then. This synchronization loss does not happen at every xrun neither, just sometimes, but often enough to make Rosegarden unusable for me. I have followed instructions/suggestions about real time kernel preparation, mainly at: http://tapas.affenbande.org/wordpress/?page_id=40 My interrupts are: daemon:~/bin# cat /proc/interrupts CPU0 CPU1 0: 149 27 IO-APIC-edge timer 1: 0 3301 IO-APIC-edge i8042 4: 0 1 IO-APIC-edge 8: 4387 4605172 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 16: 339745 9307 IO-APIC-fasteoi nvidia 19: 3979385 78 IO-APIC-fasteoi ohci1394 20: 67599 2670 IO-APIC-fasteoi sata_nv, HDA Intel 21: 117173 2744 IO-APIC-fasteoi sata_nv 22: 0 29 IO-APIC-fasteoi ehci_hcd:usb2 23: 1 64256 IO-APIC-fasteoi ohci_hcd:usb1, sata_nv 505: 686520 1715 PCI-MSI-edge eth0 NMI: 0 0 Non-maskable interrupts LOC: 4103774 4101798 Local timer interrupts RES: 7526734 7904732 Rescheduling interrupts CAL: 797 855 function call interrupts TLB: 3268 4503 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts SPU: 0 0 Spurious interrupts ERR: 0 I also set the FIFO sch., and high prio to the IRQ-8 & IRQ-19 processes: * chrt -f -p 98 `pidof IRQ-8` chrt -f -p 82 `pidof IRQ-19` ** echo 8192 > /proc/sys/dev/rtc/max-user-freq * Next I start JACK, and other audio software. In the htop processes look like this then: *http://picasaweb.google.com/tgrzelak/Audio/photo#5235864409871263538 *[you can see there are quite many xruns reported] Now... what I have tried before asking you for help: 1. Starting JACK with larger buffer: jackd -R -P70 -t2000 -dfreebob -dhw:0 -r48000 -p512 -n3 -D 2. Having used the 'nv' driver instead of the binary 'nvidia' one (I have GeForce 8800GTX if that matters), and some light window manager - Window Maker. 3. Rosegarden 1.7.1 compiled from source (currently I have 1.7.0 in Debian repositories). 4. JACK 0.112.1 compiled from svn repositories. 5. JACK 0.112.1 with FFADO backend instead of FreeBoB. No matter what I have tried, the situation looked the same every time - not possible to work with Rosegarden, no problems with Muse. I must say I'm running out of ideas. I don't know what to check/try more, especially xruns happen ONLY while using Rosegarden! Rosegarden seems to be a great environment with lots of useful features, and convenient usage, and I'd like to have it as the main MIDI seq software, but somehow it is unusable for me. I'd be thankful for help with this issue. Regards, Tomasz Grzelak |
From: Tomasz G. <tgr...@gm...> - 2008-09-01 07:31:18
|
Hello! It seems that I have finally got rid off the xrun problems with Rosegarden (I spent several hours during last weekend composing my music, and got only a few xruns, but during some background downloading process, or screensaver operation; any way during composing situation was fine). I'll do more testing in next several days/weeks, 'cause I'm going to focus more on my music, but at the moment I'm quite satisfied with results. So thanks to you all for ideas/suggestions - I decided to try some audio dedicated distribution. But it didn't stop only on installing the new OS, I made quite many changes to the basic setup. Let me share my experience, and all what I did to make it work, maybe someone finds it useful: 1. I chose 64studio, and installed it on a single disk (without RAID) - two partitions: one for /, and another for /home (+ swap of course). The distribution is mainly based on Debian Etch. Everything worked OK from the very beginning, but 'stability' of the OS was a problem for me - I really needed newer software (e.g. Hydrogen from SVN repositories). The option was to compile it, but without 'fresh' libraries, and development packages, it was rather impossible. So I made another crusial step: 2. Upgrade to Debian Sid (unstable) :) The process was not so smooth, but I managed to get through it. After the upgrade, the situation was OK still - no xruns with RG detected. Encouraged I decided to go further: 3. Compiled a newer kernel (2.6.24.7) with realtime patches (rt17). I used the same kernel config as on my "normal" system on which I had RG xrun problems. But running 'unstable' 64studio on my own kernel config was still fine - no problems detected. So the next step was to: 4. 'upgrade' the software & drivers. I downloaded & compiled: * FFADO (beta 2.0 if I remember correctly) * JACK 0.112.1 (SVN version) * Hydrogen (current SVN checkout) * Rosegarden 1.7.1 * Ardour 2.5 * ZynAddSubFX (current CVS checkout) - using the distribution provided zynaddsubfx I had quite high CPU load, and xruns when running with qsynth simultaneously. When I compiled zyn from CVS, CPU load decreased about 20-30%, and I observed no more xruns when using it with qsynth at the same time. And the final step was (and is still) to: 6. Test the new environemnt. Several hours spent during the weekend with satysfying results is quite optimistic. But I suppose next few days/weeks will give the final answer about 'stability' of the solution. Any way when I think of the 64studio installation, and my "normal" Debian unstable I can see the really big difference in using RAID in "normal" OS, and no RAID in the audio setup. Of course, there's a lot of more software installed on my usual work system, but I don't think it could have had a negative impact on processing audio (I tried to turn off most of daemons running too). The more I think of it now the more I suspect the RAID deamon process having bad influence on Rosegarden. But why Rosegarden only?... I don't think I will be able to answer the question.... Any way, I'll stop thinking about it, and I hope to focus more on music now, and not on installing/configuring my OS :) Thanks again for your help! Cheers! |
From: D. M. M. <ros...@gm...> - 2008-09-02 13:50:53
|
On Monday 01 September 2008, Tomasz Grzelak wrote: > The more I think of it now the more I suspect the RAID deamon process > having bad influence on Rosegarden. > But why Rosegarden only?... I don't think I will be able to answer the > question.... I don't think we'll know the answer to that ourselves, but I'm glad to see you're finally enjoying success here. That's great. I was very frustrated for you. -- D. Michael McIntyre |
From: Tomasz G. <tgr...@gm...> - 2008-09-02 20:31:09
|
D. Michael McIntyre pisze: > On Monday 01 September 2008, Tomasz Grzelak wrote: >> The more I think of it now the more I suspect the RAID deamon process >> having bad influence on Rosegarden. >> But why Rosegarden only?... I don't think I will be able to answer the >> question.... > > I don't think we'll know the answer to that ourselves, but I'm glad to see > you're finally enjoying success here. That's great. I was very frustrated > for you. > Thanks Michael! I was very frustrated, becase so many people could use RG while I had not been able to, and didn't know why. Maybe now I don't know neither, but at least found another way to use it. Maybe I only lied about the ZynAddSubFX from CVS in my previous mail :/ I just screwed something up, and noticed it later. Setting '-p256' (instead of 128) in the JACK command line got rid off the problem I had described (so no need to compile zyn from cvs). Now I must say I'm very satisfied with my audio environment, becase I can use many other apps, and RG finally! The more I use it, the more I see how GREAT piece of software it is! Wishing you all continuous success with using & developing RG! :) Cheers! Tomek |
From: david <gn...@ha...> - 2009-12-08 10:06:28
|
Tomasz Grzelak wrote: > I downloaded & compiled: > > * FFADO (beta 2.0 if I remember correctly) > * JACK 0.112.1 (SVN version) I switched to JACKDMP aka Jack2. > * Hydrogen (current SVN checkout) > * Rosegarden 1.7.1 Now you need to go download and compile Rosegarden 1.7.3. ;-) -- David gn...@ha... authenticity, honesty, community |
From: D. M. M. <mic...@ro...> - 2008-08-19 01:31:50
|
On Monday 18 August 2008, Tomasz Grzelak wrote: > I'd be thankful for help with this issue. Since this only happens with Rosegarden, it probably does point a finger at us in some way. I wish I could help, but I'm afraid I have no idea what else to suggest. You've already done a great job of trying to solve your own problem. All I can do from here is hope that Chris has some insight when he gets back from vacation. He knows the inside of the audio code vastly better than I do. -- D. Michael McIntyre |
From: Tomasz G. <tgr...@gm...> - 2008-08-20 14:58:50
|
D. Michael McIntyre pisze: > On Monday 18 August 2008, Tomasz Grzelak wrote: > >> I'd be thankful for help with this issue. > > Since this only happens with Rosegarden, it probably does point a finger at us > in some way. I wish I could help, but I'm afraid I have no idea what else to > suggest. You've already done a great job of trying to solve your own > problem. > > All I can do from here is hope that Chris has some insight when he gets back > from vacation. He knows the inside of the audio code vastly better than I > do. Nice to see some feedback... I hope this issue won't be ignored, but investigated deeper. I've just make another test - I have run JACK & Rosegarden only, without any other audio applications. Look at what I've got after 10 minutes of doing nothing (Rosegarden was only run, and in the meantime I was reading mails): http://picasaweb.google.com/tgrzelak/Audio/photo#5236609217996444898 almost 30 xruns in ten minutes of doing nothing, only with Jack & Rosegarden running :/ In comparison, when I work simultaneously with many audio applications (Muse+Qsynth+ZynAddSubFX+Hydrogen+Ardour) I usually get only 2 or 3 xruns when starting synthesizers programs, and then can work as long as I want without any problems (no xruns). I hope the Rosegarden issue will be fixed soon. Cheers! Tomasz Grzelak |
From: Emanuel R. <xb...@we...> - 2008-08-20 16:13:51
|
2008/8/18 Tomasz Grzelak <tgr...@gm...>: > 3. Rosegarden 1.7.1 compiled from source (currently I have 1.7.0 in Debian > repositories). > > 4. JACK 0.112.1 compiled from svn repositories. > > 5. JACK 0.112.1 with FFADO backend instead of FreeBoB. > Hello The first thing, I would try on your place, would be to use stable sources. jack 0.112.1 has not been released yet and thus rosegarden likely has not been tested with it. I'd also recommend to install jackd in /usr not in /usr/local if you haven't done so, since that's been an error source in the past. also set the tmpdir to /dev/shm |
From: Tomasz G. <tgr...@gm...> - 2008-08-20 20:23:05
|
Emanuel Rumpf pisze: > 2008/8/18 Tomasz Grzelak <tgr...@gm...>: >> 3. Rosegarden 1.7.1 compiled from source (currently I have 1.7.0 in Debian >> repositories). >> >> 4. JACK 0.112.1 compiled from svn repositories. >> >> 5. JACK 0.112.1 with FFADO backend instead of FreeBoB. >> > Hello > The first thing, I would try on your place, would be to > use stable sources. > jack 0.112.1 has not been released yet and > thus rosegarden likely has not been tested with it. > > I'd also recommend to install jackd in /usr not in /usr/local > if you haven't done so, since that's been an error source in the past. > also set the tmpdir to /dev/shm before I started using JACK 0.112.1, I had used version 0.109.2 directly from Debian repositories which is also placed in /usr, not /usr/local. So unfortunately it's not a problem as you suggested. It must be something else. Problems with Rosegarden made me experiment with other versions of different software, and that's why I started using the 0.112.1 version. Besides when I use Muse both version of JACK work fine with audio applications on my system. Cheers! |
From: Emanuel R. <xb...@we...> - 2008-08-21 12:54:25
|
2008/8/20 Tomasz Grzelak <tgr...@gm...>: > > Besides when I use Muse both version of JACK work fine with audio > applications on my system. > OK Let's think about it again: xruns (at playback) occur, if rosegarden is unable to deliver buffers to jack within a range of time. possible reasons: - rosegarden doesn't get enough cpu time possible reason: it cannot accuire real-time-priority so another process is stealing cpu time (maybe just every minute) - rosegardens timer does not work as expected and is not in sync with muse for example. possible solutions: make all program use the same clock make rosegarden use the system timer (see options dialog), instead of the rtc. (( This doesn't sound logical, but I've myself had "out-of-sync" problems, when using rosegarden with rtc. I still don't understand all of this timer-stuff, but I've read somewhere, that linux would use the most accurate timer available. If that is true, the system timer would somehow be run by the rt-clock anyway. )) I've just checked, and yes, actually, rosegarden is using the system timer here. Have a look at the rosegardensequencer process-threads with: htop -H For comparision: I have to two threads running with prio 20 (low priority threads) and one running with prio -88 (rt-thread) Other things to try: killall crond deamon processes killall powersave processes killall cpu-frequency scaling processes good luck |
From: Tomasz G. <tgr...@gm...> - 2008-08-21 21:12:17
|
Emanuel Rumpf pisze: > 2008/8/20 Tomasz Grzelak <tgr...@gm...>: >> Besides when I use Muse both version of JACK work fine with audio >> applications on my system. >> > OK > > Let's think about it again: > xruns (at playback) occur, if rosegarden is unable to deliver xruns occur, but not only in playback. I can leave Rosegarden (and only Rosegarden without any other JACK application running) doing nothing for several minutes, and when I return I can see several xruns more. On the other hand, I can run Muse doing nothing for an hour (with many other JACK applications), and then I don't get a particular xrun. I've made this kind of tests too. I've even tried to compose/play my music with some big software having compiled in the background on two CPU cores, from time to time rotating my compiz cube, and what's interesting - only one xrun occured during that quite long time os the stress. But I've noticed one interesting thing - it seems to get 3 or 4 times more xruns when a screensaver (OpenGL) activates in the meantime of doing nothing. But like I wrote before - I tried to run Rosegarden in WindowMaker (without any screensaver) on open source "nv" driver, and it didn't change anything about xruns. So no matter if I use the open "nv" or proprietary "nvidia" driver, it does not make any difference. > buffers to jack within a range of time. > possible reasons: > - rosegarden doesn't get enough cpu time > possible reason: it cannot accuire real-time-priority > so another process is stealing cpu time > (maybe just every minute) only one so important I can think of would the RAID daemon, but why do other apps work fine somehow? I'm confused... > > - rosegardens timer does not work as expected and is not > in sync with muse for example. > what do you mean by "... is not in sync with muse"? I do not run those applications simultaneously; Either Muse or Rosegarden, but not both at the same time > > possible solutions: > > make all program use the same clock hmm... I don't think I know how to do that :/ > make rosegarden use the system timer (see options dialog), instead of the rtc. yes, this one I've found and set to system timer - xruns occur still, maybe a little bit slower or maybe it's just an illusion, but they do any way... > (( This doesn't sound logical, but I've myself had > "out-of-sync" problems, when using rosegarden with rtc. > I still don't understand all of this timer-stuff, but > I've read somewhere, that linux would use > the most accurate timer available. > If that is true, the system timer would somehow > be run by the rt-clock anyway. )) > > I've just checked, and yes, actually, rosegarden is using the system timer here. By default mine was setup to (Auto). I've checked RTC, and system-timer - no success unfortunately. > > Have a look at the rosegardensequencer process-threads with: > htop -H > > For comparision: I have to two threads running with prio 20 (low > priority threads) > and one running with prio -88 (rt-thread) > I have one rosegarden thread with prio 20, three rosegardensequencer threads with prio 20, and one rosegardensequencer thread with -70 prio (rt) > > Other things to try: > killall crond deamon processes killed - no change unfortunately > killall powersave processes and how could they be called? I don't know what to kill... if any > killall cpu-frequency scaling processes I suppose this is OK: daemon:~# cpufreq-info cpufrequtils 004: cpufreq-info (C) Dominik Brodowski 2004-2006 Report errors and bugs to cp...@li..., please. analyzing CPU 0: no or unknown cpufreq driver is active on this CPU analyzing CPU 1: no or unknown cpufreq driver is active on this CPU > > good luck > thanks for your help! I still have no clue, but as others suggested I'll try to see what happens with an audio dedicated distribution. I'll try to get some LiveCD for the beginning, and let you know how it goes. Cheers! |
From: david <gn...@ha...> - 2008-08-22 04:31:52
|
Tomasz Grzelak wrote: > Emanuel Rumpf pisze: >> 2008/8/20 Tomasz Grzelak <tgr...@gm...>: >>> Besides when I use Muse both version of JACK work fine with audio >>> applications on my system. >>> >> OK >> >> Let's think about it again: >> xruns (at playback) occur, if rosegarden is unable to deliver > > xruns occur, but not only in playback. I can leave Rosegarden (and only > Rosegarden without any other JACK application running) doing nothing for > several minutes, and when I return I can see several xruns more. > On the other hand, I can run Muse doing nothing for an hour (with many > other JACK applications), and then I don't get a particular xrun. I've > made this kind of tests too. > I've even tried to compose/play my music with some big software having > compiled in the background on two CPU cores, from time to time rotating > my compiz cube, and what's interesting - only one xrun occured during > that quite long time os the stress. > > But I've noticed one interesting thing - it seems to get 3 or 4 times > more xruns when a screensaver (OpenGL) activates in the meantime of > doing nothing. > But like I wrote before - I tried to run Rosegarden in WindowMaker > (without any screensaver) on open source "nv" driver, and it didn't > change anything about xruns. So no matter if I use the open "nv" or > proprietary "nvidia" driver, it does not make any difference. No real contribution, but it sounds to me like your video and sound hardware might be sharing an interrupt. Perhaps it's not normally noticeable until the video card is doing something more demanding (like running OpenGL)? -- David gn...@ha... authenticity, honesty, community |
From: Tomasz G. <tgr...@gm...> - 2008-08-22 15:21:38
|
david pisze: > No real contribution, but it sounds to me like your video and sound > hardware might be sharing an interrupt. Perhaps it's not normally > noticeable until the video card is doing something more demanding (like > running OpenGL)? > I described my interrupts in the first post. I can see no conflict here: daemon:~/bin# cat /proc/interrupts CPU0 CPU1 0: 149 27 IO-APIC-edge timer 1: 0 3301 IO-APIC-edge i8042 4: 0 1 IO-APIC-edge 8: 4387 4605172 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 16: 339745 9307 IO-APIC-fasteoi nvidia 19: 3979385 78 IO-APIC-fasteoi ohci1394 20: 67599 2670 IO-APIC-fasteoi sata_nv, HDA Intel 21: 117173 2744 IO-APIC-fasteoi sata_nv 22: 0 29 IO-APIC-fasteoi ehci_hcd:usb2 23: 1 64256 IO-APIC-fasteoi ohci_hcd:usb1, sata_nv 505: 686520 1715 PCI-MSI-edge eth0 NMI: 0 0 Non-maskable interrupts LOC: 4103774 4101798 Local timer interrupts RES: 7526734 7904732 Rescheduling interrupts CAL: 797 855 function call interrupts TLB: 3268 4503 TLB shootdowns TRM: 0 0 Thermal event interrupts THR: 0 0 Threshold APIC interrupts SPU: 0 0 Spurious interrupts ERR: 0 I also set the FIFO sch., and high prio to the IRQ-8 & IRQ-19 processes: chrt -f -p 98 `pidof IRQ-8` chrt -f -p 82 `pidof IRQ-19` echo 8192 > /proc/sys/dev/rtc/max-user-freq If you see anything wrong with it, let me know please. Cheers! Tomasz Grzelak |