I can run beta with 2.6.23.11-rt14 kernel with no crackles.
But with 2.6.25.8-rt7 I get lots of crackles. Other audio apps are fine, eg. Ardour/Rosegarden/Qsynth/Hydrogen studio.
And 2.6.26 kernels have big realtime/MIDI/audio problems - see http://kerneltrap.org/Linux/Removing_the_Big_Kernel_Lock
Atleast .24 has lots of audio problems, including with renoise, but it’s not true there are no problems with other audio programs. The state is basically the same.
Please give us some more info about your setup. You are running a 64bit dist, so you are using Renoise with ALSA (not Jack), right? At which settings do you use ALSA in Renoise? Do you use the same settings in Jack or ALSA with the other applications? Is this a new Renoise 2.0 problem - aka works Renoise 1.9 just fine? Please make also sure that the “Realtime Prio” setting for ALSA in Renoise is enabled.
My setup:
OS - 64bit
Device type - ALSA
Sample rate - 44100
Buffer - 64
Periods/buffer - 2
Realtime priority - yes
Dither - yes
Realtime audio CPUs - 2
Same settings as for other apps.
Having a little trouble getting 1.9.1 to run now that I have 2.0 installed 
I ran uninstall.sh script in 1.9.1 and now when I click on the 1.9.1 renoise executable I get
“Caught an unhandled exception {Thread: GUI)”
and then the Desktop crashes and I’m back to the login screen.
But I’m happy to test further, with a little guidance…
…and as suva notes there are problems with other progs on .24 and .25 kernels, eg. totem-xine, mplayer, xmms…
Actually the programs you named don’t have much problems as they use HUGE buffers compared to Renoise or any other audio production software.
But Norv says he uses the same buffer size for the other apps? Which buffers do you mean then?
Norv: 64 samples is really not much. Which buffersize or number of periods do you need then to get Renoise running smoothly?
With 2.6.25.8-rt7 I have to go to 1024 samples buffer to eliminate crackles.
With 2.6.23.11-rt14 I can run at 16 samples buffer with no crackles.
With a jack/ardour/hydrogen/rosegarden/softsynth setup I can get xrun-free playback at 256 samples buffer on newer kernel but I get xruns when I switch windows.
This looks more like a kernel problem then, doesn’t it? Could you please try if disabling the record (capture) device in Renoises ALSA config improves things?
Disabling capture device gives major improvement with 2.6.25.8-rt7 - Renoise will run at 16 samples with no crackles.
Thats something I anyway wanted to look at, so let me see what I can do to improve this. Syncing playback and capture ALSA devices is really a pain in the a**, so I bet there is something we’ve missed on how to make this better…
And again Suva chimes in and reports: This is not just renoise problem. JACKd and Audacity also have this problem. On some soundcards there is some sort of problem when running in full duplex. The streams don’t seem to be in sync.
I am still wondering what exactly is the problem and how windows handles this. Does it really expect some sort of different buffer sizes and stuff for capture and playback, or contrary exactly the same?
I also have one of those cards in my laptop. And it has never worked well in full duplex. So I use it only for playback. Also I don’t know if and how it works on windows, as I have never had windows on this computer.
Thats not a hardware problem, but a driver design (or ALSA design) problem. With ASIO for example, there is no need to sync the two streams at all because you always fill them up in one operation / buffer call. This has of course the disadvantage that the capture and playback device must be in the same driver / on the same hardware.
Even if this is no Renoise problem, I think there is room for improvements in Renoise regarding this, thats why I would like to take a look at this again. If everything fails, we stll could show a warning that running ALSA in full duplex mode slows down things a lot - make people aware of this problem…
It was not my intention to blame Renoise for the problem.
I just wanted to alert devs and users to the audio problems that are emerging with these newer kernels.
More and more Linux users will be using the newer kernels as the various distros upgrade their repositories and they will be wondering WTF happened to their audio apps!
Yeah I agree. I have been using linux audio for many years. Things haven’t been that bad since maybe 1998. Since early 2000’s the linux audio has been rather stable, until now that is.
Ok, I know this is kind of an old thread but there are some issues with full duplex that I’ve been struggling to resolve using ardour jack alsa and an ews88mt soundcard. Here’s what I found and why it probably affects other cards / chipsets:
The ews88MT (ice1712 chipset) caused me problems using jackd to do full duplex in ardour, run in capture only I could get latencies of 64 samples, not xruns. Same in Playback only, full duplex I get xruns even with buffer sizes as big as 1024 (after that the driver won’t allocate anymore memory for the buffer - xruns get further apart for larger buffers but they always happens eventually). I put some diagnostics in the alsa driver for the card and built a custom jackd. What happens is that the time jackd spends waiting for the capture and record buffers to fill gradually drifts out of sync until one of the buffers (normally the capture one) overruns and an xrun occurs resetting the alsa driver so it can happen again a bit later. But both halves of the card (palyback and capture) run from the same physical clock (so the data sheets say) so how can they drift?
What appears to happen is this:
The capture and playback halves of the card count down the number of samples they have DMA’d and then interrupt (to alsa) when the count reaches zero (so you set the count to be the ‘-p’ value in jackd). Alsa then responds to the interrupt, looks at IRQ status to determine what caused it, and processes the audio in or out. The trouble is you can’t guarantee that the kernel will respond to an interrupt in less that 20uS (one sample period at 48K). If it does not then the counter will reset and begin counting again before the data has been processed (and the buffer pointers updated) - this means that the capture and playback buffer pointers gradually get out of sync, forcing jackd to wait longer in poll() for both halves of the card to be ready. Eventually one overuns before the other has captured / played enough samples. Therefore, it seems that you cannot guarantee full duplex operation with soundcards that use seperate IRQ/DMA channels for input and output - on playback only or capture only its not a problem as long as the kernel responds in the time taken for one buffer to be played/captured (5ms ish at 256 samples etc) which is normally easilly obtainable. Note: this is a problem for me at the moment on a 2.4GHz athlon X2 so its not just a case of needing a faster PC, you might be ok if your ‘lucky’ with a kernel that happens to be fast enough but its not a ‘hard’ parameter.
Why is this not a problem on windows? (it probably is, I could never get rid of crackles and pops with the 88MT and sometimes my recordings seemed as if they were slightly out of time - impossible I though, must be my playing…) I guess it depends on similar factors e.g. what windows ‘kernel’ you have and what other stuff you have in the system.
Some high end sound cards have clock settings. I had one RME card which had lots of clock settings under alsamixer. On some settings the card didn’t roll at all (expected some external clock signal apparently), on some settings it started to drift as described here, and in some settings it was working perfectly.
I recommend you to check alsamixer on this card and see what toggles and settings you have there, and try different combinations.
Thanks, yeah - I checked all the clock settings when I first had problems, the EWS88MT control panel either in alsamixer or the envy24control utility specifically for the chipset has options to change the clock source (this board can sync from spdif if necessary) and there are a couple of other modes, non of which made any difference. I recompiled the alsa drivers with some printk messages to tell me what the clock settings were on the chip and for each rate options / sync option they corresponded with what I expected from the data sheet but the two halves of the chip still drifted. The only thing that could stabilise it was switching the sample rate down (22050 and below stop xruns) but if I’m right about how it goes wrong then this probably only works because at that sample rate the kernel can respond in less than one sample period. But, this is not guaranteed, I think its reasonable to expect the kernel to respond to an interrupt in at least a few mS - so less than a buffer at 64 samples, but anything less than that and it may all go wrong again as soon as a new driver is installed or a different kernel is used so I don’t ‘like’ it as a solution - plus 22050 is unusable to me, I want my soundcard ti hear more than 10KHz… I’m experimenting with building a new alsa backend for jackd that works on a capture driven duplex mode so that if the card screws up when I’m recording, I only hear clicks in the monitor feed but my recording is still ok, for mixing I can run in playback only and everything is always fine.
Not sure if it’s related, but maybe modifying linux internal clock granularity may help. I think it was originally set on 1000 ticks per second. Not sure if it helps anything though.
I don’t think the clock granularity will help much in this case - I think it primarily influences the time at which the thread will wake up and process data, in this case the time from the alsa driver aquiring new data from the hardware and poll() waking up in jackd. This is not really where the problem lies because I have a maximum 21ms before the buffer runs out (1024 samples at 48KHz). The problem seems to be that it is not possible to determine that the top half of the interrupt handler will get called within 20us of the interrupt pin going high on the ice1712 because the kernel may be doing other things and / or may have switched the interrupts off temporarilly. This is entirely reasonable, it would require some quite ‘hard realtime’ tweaks to guarantee that sort of latency and that just isn’t where linux is at it seems (or windows) . The problem is that hardware manufacturers don’t appear to appreciate the necesity to have their input and output soundcard buffers in sync. As a result, it seems if you have a card that uses the ice1712 chipset or more specifically sperate IRQ/DMA channels for input and output then you may never get full duplex to work properly or if it does its more by luck than design and it will probably all come to bits if you add more hardware or change the kernel. I may be wrong (and I’m happy to be proved so) but from the evidence so far it appears I will never get this card to work reliably in the way I need. I can record and playback simultaneously using two jackd servers, one in capture only and one in playback only with no xruns but obviously my recordings drift in and out of sync periodically. If I try and run one jackd in full duplex mode I get xruns at any latency settings. I thought it was worth mentioning all of this so as to 'add it to the mix of things to consider when you get clicks and pops with audio… In the hope it may be of some help to others with the same problems I am having. If I find a way to fix it I’ll post it but I’m not optimistic.