Linux Audio the way to go!?

[Telstar]

I'll ask again: There is any VST host for linux such as console/bidule?

Without that I cannot try it

BTW, I was considering linux mint to give it a try

 

[soundcheck]

I am not that deep into it, perhaps below helps a bit.

As you know Linux uses the opensource LADSPA interface only. I am not aware of any official VST support.

However there are ways...

Usually you need to compile the required stuff by yourself or you source ready-made binaries from somewhere else.


Here is is an application called fst: http://www.joebutton.co.uk/fst/

Ardour: Supports it - you need to compile it manually to enable VST support.

There also seems to be ways to route vst streams into Ardour via Jack. This would make the manual compilation of Ardour obsolete,

Here is a howto which is making use of wine: http://www.64studio.com/howto_vst

Not all .dlls will work properly. 64bit systems won't seem to work at all.

As far as I can see, all this might scare Linux newbies off.

However, I didn't went that deep into it to see if some of the Pro-Audio distributions support VST by default.

Good luck

 

[Telstar]

As far as I can see, all this might scare Linux newbies off.

I found also this:
http://dssi.sourceforge.net/download.html
But I think that a routing host is still lacking.

However, I didn't went that deep into it to see if some of the Pro-Audio distributions support VST by default.

I hope that!

 

[ratza]

I am thinking about moving to Linux for my next PC build.

Do I start by reading this thread or is there a better way to get me up to speed for setting up a "Linux" PC?

Linux is just the kernel and there are a lot of distributions based on it. My recommendation is to try live CDs which will not affect your hard disk content. It will offer you the chance to see how it looks and to get used with it. The distribution should be one which is compatible with all your hardware and also well supported by the programming community. Just for info, I'm using openSUSE for three years. I also had Ubuntu for half an year and I tried several other distributions: Red Hat, Debian, Fedora, Mandriva, DSL, Knoppix and Gentoo.

More information can be found under www.linux.org and as a comment, once you go with it, there's no way back to Windows. No money to pay (except you consider a donation) and you get an incredible system stability. There's a comparison between Windows and Linux: in Linux, first you bang your head on the monitor, then you read the documentation and finaly you use the system. Under Windows this cycle runs backwards.

 

[AndrewT]

Thanks for the newbie pointers.

 

[Geek]

There's a comparison between Windows and Linux: in Linux, first you bang your head on the monitor, then you read the documentation and finaly you use the system. Under Windows this cycle runs backwards.

What a nice description of the user flowchart

IMO, the comparison between Windows and Linux is like that between a Humvee and a Prius.... the only thing they really have in common is four wheels and go from "A" to "B".

Cheers!

 

[UnixMan]

HDCD software decoding + hi-quality SOX upsampling with ALSA

Hi guys,

On my system I've recently set-up automatic HDCD decoding plus (optionally) Sox advanced upsampling.

(HDCD decoding is done using Christoper Key's "hdcd" software decoder. It's free, but to get a copy of it you must contact him directly).

Here's how...

in my ~/.asoundrc I've setup a pipe:

pcm.HD {
         type file
         slave {
                 pcm null
         }
         format "raw"
         file "| /usr/local/bin/sox-resample.sh %c %b %r"
}

and this is the "sox-resample.sh":

#! /bin/bash
# Resampling + HDCD decoding script for file plugin

# If input rate equals maximum rate, no resampling via sox.

# Since sox supports only 16-bit alsa output, it pipes data to aplay for playback

CHANNELS="$1"   # no. of (input stream) channels

BITS="$2"       # input stream bit-depth (word-length)

RATE="$3"       # input stream sample rate

#ALSA_DEVICE="plughw:0"
ALSA_DEVICE="hw:1"

MAX_44100=176400       # avoid "odd" rate resampling
#MAX_44100=192000        # same output rate for all (avoid switching which is troublesome on my setup)
MAX_48000=192000

SOX_DEBUG="-V"
#SOX_DEBUG="-V -S"

APLAY_DEBUG="-v"
APLAY_EXTRAS="-F 1000000"                # minimum IRQs

#SOX_RATE_PARAMS="-v -s"                # best resampling
SOX_RATE_PARAMS="-v -I -b 99.7 -a"    # custom resampling...

APLAY=`which aplay`
SOX=`which sox`
HDCD=`which hdcd`

if [ "$RATE" == $MAX_44100 ] || [ "$RATE" == $MAX_48000 ]; then
        # already at maximum rates, no need for resampling, direct output
        OUTPUT_RATE=$RATE
else
        RESAMPLE="true"
        if [ "$RATE" == 44100 ] || [ "$RATE" == 88200 ]; then
                # 44100 family
                OUTPUT_RATE=$MAX_44100
        else
                # 48000 family
                OUTPUT_RATE=$MAX_48000
        fi
fi

echo "RATE=$RATE, BITS=$BITS, CHANNELS=$CHANNELS"

CDDA=""
if [ "$RATE" == 44100 ] && [ "$BITS" == 16 ] && [ "$CHANNELS" == 2 ]; then
        echo -e "\nCDDA format detected: will try to detect/decode HDCD before resampling..."
        CDDA="true"
        BITS="24"   # hdcd decoder always output 24 bit audio stream
fi

# resampling command
SOX_CMD="$SOX $SOX_DEBUG -t raw -c $CHANNELS -b $BITS -r $RATE -s - -t raw -b 32 - rate $SOX_RATE_PARAMS $OUTPUT_RATE"
echo "$SOX_CMD"

# aplay command
APLAY_CMD="$APLAY $APLAY_DEBUG -t raw -r $OUTPUT_RATE -c $CHANNELS -f S32_LE $APLAY_EXTRAS -D$ALSA_DEVICE"
echo "$APLAY_CMD"

if [ -z $RESAMPLE ]; then
        # no resampling, aplay only
        cat | $APLAY_CMD
elif [ "$CDDA" == "true" ]; then
        echo "detecting/decoding HDCD before resampling..."
        hdcd -r -c | $SOX_CMD | $APLAY_CMD
else
        $SOX_CMD | $APLAY_CMD
fi

The scripts are based on an example (doing sox upsampling only) I've found somewhere on the net.

Overall they do work quite well (though you need A LOT of CPU power...). Only problem is that with some "front-end" software (e.g. "quodlibet") you got an error and/or a crash at the end of the first file/stream played because of "broken pipe" or something like that. If you have an idea about how to fix that I would appreciate it.

 

[phofman]

Unixman,

when I wrote the script, sox did not support 24bit alsa playback. If you have a recent sox version, you can remove all the aplay stuff, sparing the extra process and pipe latency. Check sox output first to make sure sox outputs correct sample rate and format for your particular card.

What is the error message you get at the end of the first track? The error message is produced by the frontend or the sox chain?

If the frontend closes the alsa device between the tracks, the input pipe to sox gets closed and sox quits (possibly complaining about a closed pipe). But it is not a problem since the chain gets restarted upon opening the device when playing next track. You get a bit longer latency though but it does not matter for pure playback.

Unfortunately the piping file plugin does not work correctly for some SW which reads hw parameters of your card first and adjusts the stream params accordingly. Perhaps it is possible to fix the file plugin so that it overwrites the card parameters with a new set stored in the config file.

 

[UnixMan]

when I wrote the script, sox did not support 24bit alsa playback. If you have a recent sox version, you can remove all the aplay stuff, sparing the extra process and pipe latency.

good to know... I'll check that, tnx.

What is the error message you get at the end of the first track? The error message is produced by the frontend or the sox chain?

I'm not sure... don't have the system at hand now, will check next W.E.

BTW, I think it's the front-end which complaints about its output pipe which get closed at the end of the stream, i.e. that the problem is related to the alsa piping plugin. If I remember correctly, the same problem arise also without sox being involved in the pipe. Or maybe is the problem you noted.

 

[soundcheck]

Con Kolivas back!

Hi folks.

For the ones interested in kernel talk!

Con Kolivas is back. He introduced a new scheduler: BFS (Brain **** Scheduler)

Of course it's a patch.

Interesting read:

http://ck.kolivas.org/patches/bfs/bfs-faq.txt


Background: In 2007 Con left the scheduler scene. He was competing against
Ingo Molnar all the time. At that time Molnars CFS made it into
the kernel Con backed off. CFS consisted partially of Cons code.
From an audio perspective Cons preempted kernel patch was IMO
performing best for audio purposes at that time.


Cheers

 

[UnixMan]

just checked...

If you have a recent sox version, you can remove all the aplay stuff

I can confirm that my version of sox (14.3.0-1 from Debian) supports 24bit out. But...

Check sox output first to make sure sox outputs correct sample rate and format for your particular card.

my card (ESI Juli@) only accepts S32_LE.

Though I can use it by setting AUDIODEV="plughw:1", I'm not sure about possible side-effects (e.g. dmix gettin' into the mix and/or ALSA going back down to 16bit?).

What is the error message you get at the end of the first track?

This is from "quodlibet":

RATE=44100, BITS=16, CHANNELS=2

CDDA format detected: will try to detect/decode HDCD before resampling...
detecting/decoding HDCD before resampling...
hdcd -r -c |
/usr/bin/sox -V -t raw -c 2 -b 24 -r 44100 -s - -t alsa -b 24 rate -v -I -a 192000
/usr/bin/sox: SoX v14.3.0

Input File     : '-' (raw)
Channels       : 2
Sample Rate    : 44100
Precision      : 24-bit
Sample Encoding: 24-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no


Output File    : 'plughw:1' (alsa)
Channels       : 2
Sample Rate    : 192000
Precision      : 24-bit
Sample Encoding: 24-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no

/usr/bin/sox INFO sox: effects chain: input      44100Hz 2 channels
/usr/bin/sox INFO sox: effects chain: rate       192000Hz 2 channels
/usr/bin/sox INFO sox: effects chain: output     192000Hz 2 channels
In:0.00% 00:01:28.05 [00:00:00.00] Out:16.9M [   -==|==-   ]        Clip:0    RATE=44100, BITS=16, CHANNELS=2

CDDA format detected: will try to detect/decode HDCD before resampling...
detecting/decoding HDCD before resampling...
hdcd -r -c |
/usr/bin/sox -V -t raw -c 2 -b 24 -r 44100 -s - -t alsa -b 24 rate -v -I -a 192000
/usr/bin/sox: SoX v14.3.0

Input File     : '-' (raw)
Channels       : 2
Sample Rate    : 44100
Precision      : 24-bit
Sample Encoding: 24-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no

/usr/bin/sox FAIL formats: can't open output file `plughw:1': snd_pcm_open error: Device or resource busy
error processing buffer
python: pcm_file.c:398: snd_pcm_file_add_frames: Assertion `file->wbuf_used_bytes < file->wbuf_size_bytes' failed.
Aborted
In:0.00% 00:01:28.24 [00:00:00.00] Out:16.9M [    ==|=-    ]        Clip:0    HDCD not detected
In:0.00% 00:01:28.65 [00:00:00.00] Out:17.0M [   ===|==-   ]        Clip:0
Done.

first track plays ok, then crash trying to play the next.

This is from "Amarok" (with xine backend):

/usr/local/bin/sox-resample.sh: line 51: echo: write error: Broken pipe
/usr/local/bin/sox-resample.sh: line 55: echo: write error: Broken pipe
/usr/local/bin/sox-resample.sh: line 73: echo: write error: Broken pipe
/usr/local/bin/sox-resample.sh: line 76: echo: write error: Broken pipe
/usr/bin/sox: SoX v14.3.0

Input File     : '-' (raw)
Channels       : 2
Sample Rate    : 44100
Precision      : 24-bit
Sample Encoding: 24-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no


Output File    : 'plughw:1' (alsa)
Channels       : 2
Sample Rate    : 192000
Precision      : 24-bit
Sample Encoding: 24-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no

/usr/bin/sox INFO sox: effects chain: input      44100Hz 2 channels
/usr/bin/sox INFO sox: effects chain: rate       192000Hz 2 channels
/usr/bin/sox INFO sox: effects chain: output     192000Hz 2 channels
In:0.00% 00:00:31.95 [00:00:00.00] Out:6.13M [   -==|===   ] Hd:5.9 Clip:0    /usr/local/bin/sox-resample.sh: line 51: echo: write error: Broken pipe
/usr/local/bin/sox-resample.sh: line 55: echo: write error: Broken pipe
/usr/local/bin/sox-resample.sh: line 73: echo: write error: Broken pipe
/usr/local/bin/sox-resample.sh: line 76: echo: write error: Broken pipe
/usr/bin/sox: SoX v14.3.0

Input File     : '-' (raw)
Channels       : 2
Sample Rate    : 44100
Precision      : 24-bit
Sample Encoding: 24-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no

/usr/bin/sox FAIL formats: can't open output file `plughw:1': snd_pcm_open error: Device or resource busy
In:0.00% 00:00:32.14 [00:00:00.00] Out:6.14M [   -==|===   ] Hd:5.9 Clip:0    /usr/bin/sox WARN alsa: under-run
error processing buffer
amarokapp: pcm_file.c:398: snd_pcm_file_add_frames: Assertion `file->wbuf_used_bytes < file->wbuf_size_bytes' failed.
In:0.00% 00:00:32.32 [00:00:00.00] Out:6.19M [     =|==-   ] Hd:5.9 Clip:0    HDCD not detected
In:0.00% 00:00:32.70 [00:00:00.00] Out:6.28M [ -====|====  ]        Clip:0
Done.

Unfortunately the piping file plugin does not work correctly for some SW which reads hw parameters of your card first and adjusts the stream params accordingly.

I'm afraid that this is the problem...

Perhaps it is possible to fix the file plugin so that it overwrites the card parameters with a new set stored in the config file.

hope someone will do it soon...

 

[phofman]

UnixMan,

my card (ESI Juli@) only accepts S32_LE.

Though I can use it by setting AUDIODEV="plughw:1", I'm not sure about possible side-effects (e.g. dmix gettin' into the mix and/or ALSA going back down to 16bit?).

The plug plugin (used in plughw) provides automatic conversion to the closest format supported directly by the card. In your case all it does is conversion from 24bit to 32bit supported by ice1724 in your Juli.

You may want to use hw:1 and specify the output format in sox to 32bits by "-b 32".

Why do you upsample from 44.1 to 192kHz, instead of 176.4Hz? The non-multiple conversion is more complicated, taking more CPU. Generally it takes an oversampling to the common multiple of input and output fs, followed by downsampling to the desired output fs. The new algorithm in sox may work a little bit differently, but 4x is a safe way. You can easily determine the correct multiple in the bash script since you know supported fs of your card and the incoming rate substituted to the %r parameter.

The errors you are getting are produced by the script called by the file plugin, right? I do not think it is the problem I talked about. Post here the actual script so that we can take a look at the line numbers throwing the errors.

 

[UnixMan]

You may want to use hw:1 and specify the output format in sox to 32bits by "-b 32".

of course I tried, but unfortunately it does not work:

$ AUDIODEV=hw:1 sox *.flac -t alsa -b 32 rate -v -I -a 192000
sox WARN formats: alsa can't encode to 32-bit
sox FAIL formats: can't open output file `hw:1': select_format error: Operation not permitted

(oddly enough, if I specify -b 32 with plughw it works... )

Why do you upsample from 44.1 to 192kHz, instead of 176.4Hz?

'cause I have some problem with the DAC/I2S interface... locking at the highest rates (176.4 & 192 KHz) is somewhat problematic (maybe I'd need some signal conditioning), so switching between streams at different "base" rates is troublesome. Thus until I'll eventually solve the interface problem (if it's not an inherent problem of the DAC...) I prefer to keep a fixed rate - and I choose the highest supported rate (though given that most of my source material is from CDDA, perhaps I should rather use 176.4 as the fixed rate instead).

The errors you are getting are produced by the script called by the file plugin, right? I do not think it is the problem I talked about. Post here the actual script so that we can take a look at the line numbers throwing the errors.

wait... I guess those "write error"s (from the script trying to write some info/debugging messages to stdout using "echo") are harmless (and I can easily get rid of them commenting out the corresponding lines). I guess the real problem can be seen on the last lines:

/usr/bin/sox FAIL formats: can't open output file `plughw:1': snd_pcm_open error: Device or resource busy
error processing buffer
python: pcm_file.c:398: snd_pcm_file_add_frames: Assertion `file->wbuf_used_bytes < file->wbuf_size_bytes' failed.
Aborted

from "quodlibet" and the following from Amarok/xine:

/usr/bin/sox FAIL formats: can't open output file `plughw:1': snd_pcm_open error: Device or resource busy
In:0.00% 00:00:32.14 [00:00:00.00] Out:6.14M [   -==|===   ] Hd:5.9 Clip:0    /usr/bin/sox WARN alsa: under-run
error processing buffer
amarokapp: pcm_file.c:398: snd_pcm_file_add_frames: Assertion `file->wbuf_used_bytes < file->wbuf_size_bytes' failed.

that is, sox can't open the ALSA output device - perhaps still busy from the previous stream?!?

 

[UnixMan]

sox and/or Linux kernel/scheduler problem!?

I was quite happy with the sound of my sox-resampled system... but it caused 100% load on my Intel E5200 2.5GHz dual-core CPU. Even just touching the mouse caused skips! (underruns).

I was puzzled... ok the algorithm is heavy, but this is a system which was (and is) capable of smoothly playing full-HD movies with full software decoding of both multichannel HD audio and x264 video (...before vdpau ). So how on earth could be that it could just barely do a (relatively) "simple" upsampling of a 2 channel CD audio stream to 24/192?!

Today I tried to fix at least the skip problems giving realtime priority to the sox process (using schedtool). It worked (in the sense that skips were avoided), but the system became completely unusable while playing. And when I say unusable I mean just that: almost fully stuck!

Yet this was another "mistery", 'cause even if the sox process was eating up the 100% of one CPU core, the other one was not so much loaded - say some ~ 30%.

Another rather "strange" thing was that the sox process was continuously "jumping" back and forth from one CPU (core) to the other (why the hell the scheduler would do that?!?).

Then I tried to also assign "CPU affinity" on the schedtool options to force sox running always and only on the first CPU (core) and... miracle! the sox CPU load all of a sudden went down from 100% to a mere ~ 20% !!!

I also noticed that while before (No "CPU affinity", 100% CPU load) sox was spawning a 2nd thread for processing, now it doesn't do that (that is it runs as a single thread).

Whatever, now I have no more skips (even without RR, though I kept that) and the system keeps running smoothly (and being fully useable) while playing.

I would say that clearly there must be a BIG NASTY BUG somewhere! (...either in sox, the kernel or both).

 

[UnixMan]

BTW:

(oddly enough, if I specify -b 32 with plughw it works... )

OK, in fact it doesn't... it only *seems* to.

 

[soundcheck]

I was quite happy with the sound of my sox-resampled system... but it caused 100% load on my Intel E5200 2.5GHz dual-core CPU. Even just touching the mouse caused skips! (underruns).

I was puzzled... ok the algorithm is heavy, but this is a system which was (and is) capable of smoothly playing full-HD movies with full software decoding of both multichannel HD audio and x264 video (...before vdpau ). So how on earth could be that it could just barely do a (relatively) "simple" upsampling of a 2 channel CD audio stream to 24/192?!

Today I tried to fix at least the skip problems giving realtime priority to the sox process (using schedtool). It worked (in the sense that skips were avoided), but the system became completely unusable while playing. And when I say unusable I mean just that: almost fully stuck!

Yet this was another "mistery", 'cause even if the sox process was eating up the 100% of one CPU core, the other one was not so much loaded - say some ~ 30%.

Another rather "strange" thing was that the sox process was continuously "jumping" back and forth from one CPU (core) to the other (why the hell the scheduler would do that?!?).

Then I tried to also assign "CPU affinity" on the schedtool options to force sox running always and only on the first CPU (core) and... miracle! the sox CPU load all of a sudden went down from 100% to a mere ~ 20% !!!

I also noticed that while before (No "CPU affinity", 100% CPU load) sox was spawning a 2nd thread for processing, now it doesn't do that (that is it runs as a single thread).

Whatever, now I have no more skips (even without RR, though I kept that) and the system keeps running smoothly (and being fully useable) while playing.

I would say that clearly there must be a BIG NASTY BUG somewhere! (...either in sox, the kernel or both).

That's interesting your "CPU affinity" finding. I think the kernel guys are still challenged to get this load balancing under control. I also made the experience in the past that assigning a CPU was improving things.

Are you running 2.6.29-rt ? The new 2.6.31-rt should be ways better. They've completely
rewritten the code.

 

[phofman]

of course I tried, but unfortunately it does not work:

I see, alsa output plugin of sox does not support 32 bits. I have sent a patch to sox mailing list, in case it takes long to proliferate to CVS I am enclosing the patch with this message.

that is, sox can't open the ALSA output device - perhaps still busy from the previous stream?!?

Please post the script you use. It is possible sox did not end correctly or some other program did really occupy the device in between.

The other error messages are xruns (see the info about under-runs). The chain did not keep up. Most likely you have solved that by the schedtool tweaks.

I also noticed that while before (No "CPU affinity", 100% CPU load) sox was spawning a 2nd thread for processing, now it doesn't do that (that is it runs as a single thread).

That is correct. Sox uses the omp library to enable multithreading of effects. By setting afinity to a single CPU the library probably turns multithreading off since it would make no sense anyway.

You can get the same result with the parameter --single-threaded, see man sox.

As for the xruns:

In http://www.diyaudio.com/forums/showthread.php?t=150253 I have talked about how the PCI chain works. You want the largest buffer and appropriate period producing the largest delay in controlling actions you are willing to accept. That way your playback chain has maximum time to satisfy the insatious soundcard.

Many players allow for external setup of the alsa buffer and period size. If you look at alsa.c in the sox source code, these values are hardcoded in sox. The buffer size is approx. 8 times to the processing buffer in sox (counted in samples), and period (i.e. interrupt rate) is 1/8 of the alsa buffer. 1/8 looks like a sensible value - if the card throws interrupt, the driver has 7/8 of the buffer playback time to rewrite the already played part with fresh audio data.

That means the only parameter you can tweak without hacking the code (which is trivial BTW) is the processing buffer size --buffer - again see man sox. The default buffer size value yields about 200IRQs/s. Just increasing this parameter, without tweaking the code, I can get down to 50IRQs per second on ice1724 at 192kHz. When hacking the code to increase the period to 1/2 of the buffer I get down to 12 IRQs. I guess the hard-coded value of 1/8 is OK.

 

[soundcheck]

Alsa 1.0.21 is out

Hi folks.

Some of you might be aware of it. Alsa has been stepped up to 1.0.21 recently.

I just updated my Alsa upgrade script at Ubuntu forums.

Just follow the link in my signature if you intend to try it.

More infos you'll find over there.

Enjoy.

 

[UnixMan]

Are you running 2.6.29-rt ? The new 2.6.31-rt should be ways better. They've completely rewritten the code.

No, I'm running the stock Debian Lenny Kernel (2.6.26-2-686).

I may try the testing/unstable version (currently 2.6.30), but would have too many drivers to rebuild... I'm lazy...

 

[UnixMan]

I see, alsa output plugin of sox does not support 32 bits. I have sent a patch to sox

great! Tnx a lot.

Please post the script you use. It is possible sox did not end correctly or some other program did really occupy the device in between.

no, it looks like the problem is that either alsa, the file plugin or sox itself close the pipe *before* the last samples have been actually played (i.e. some buffer emptied).

But the application don't know about that (pipe is closed...). So it reopens the output device (that is re-open the pipe running another copy of the script) while the (real) output device is still busy playing the end of the previous track.

Thus sox fails and the app crash.

I'm not sure whether this is a bug of the script, of sox, of the file plugin or may be of alsa itself.

I guess sox should NOT return before it actually finished playing and actually freed the out device... but maybe it is ALSA that reports it's done before time...

(BTW, among the other things I've also tried to alter sox buffers using an input buffer slightly smaller/larger than the processing one to no avail).

Nevertheless, I have managed to at least work around this problem by adding some check (and looping) to the script.

The new script works ~ perfectly with Amarok/xine and sort of works (you get some "quirks" when changing tracks) also with quodlibet.

Only problem is that you get a "Zombie" of the script (which does not go away until you quit the player) every time you manually switch from one track to another (automatically "continuing" to the next in the playlist does not, at least with Amarok/xine).

The new script will follow in the next post... didn't fit here.

The default buffer size value yields about 200IRQs/s. Just increasing this parameter, without tweaking the code, I can get down to 50IRQs per second on ice1724 at 192kHz.

which size would you recommend for sox input & processing buffers ?