5 ms·

I have written quite a bit of cross platform audio code. Portaudio really works fine. If you need low latency on Windows, use the ASIO backend. Compiling it on

I have written quite a bit of cross platform audio code. Portaudio really works fine. If you need low latency on Windows, use the ASIO backend. Compiling it on Windows is a bitch, though.

stinos 12y ago
Didn't find compilation particularly hard on Windows, might be because I know the tools very well though. On the latency: do you (or anyone reading this) happen to knwo what's the current state of low latency audio (say <5mSec) on linux? A couple of years ago we did an application for human auditory system research which required stable (as in, not ever dropping any buffers) low latency. Original idea was to do it for both windows and linux, the gui would be Qt anyway so that got the cross-platform part coverd already. We were using an RME Multiface and on windows we'd just hook it up and select e.g. 48kHz 128samples buffersize, full duplex and it just worked without any problems with the standard ASIO samples. On linux we initially hardly managed to get anything out at all. And once that was fixed, it was impossible to get down to the required latencies without dropping buffers. Even with the semi-realtime kernel patches or whatever it's called. Anyway, we gave up back then but I still wonder: was it just our lack of knowledge, or was linux back then (about 7 years ago) really not up to the task, or was it a driver problem? And what is the state today?
- anon4 12y ago
  Today the state is (almost) as it always was: 1. Install and set up JACK. Enjoy your lack of latency. I haven't profiled it scientifically, but I've tried microphone monitoring with filters layered on and couldn't detect any latency between me speaking and my voice coming out the speakers. 2. Modern linux uses pulse. Pulse is kind of jingoist and slightly hostile to foreign presence. You'll need to edit its default.pa file to not load the udev-detect module and not try to just grab the soundcard for itself, but to load the jack-source and jack-sink modules. You'll also need to write a script to do the module loading because modern desktop linux doesn't have a race-free way to start daemons when a user logs in. Which you'll have to run manually once you log in. That script looks like this: #!/usr/bin/sh pacmd load-module module-jack-source channels=1 pacmd load-module module-jack-sink channels=2 Oh, and if it wasn't apparent, only one user can use the audio.
- jseg123 12y ago
  Using Gentoo, (no GUI just bash command line environment) and ALSA back-end, I got a latency of 64 samples, which seemed indistinguishable from dedicated sampler hardware when triggering audio files in Csound via a USB MIDI keyboard. This was using a 1.2 ghz Pentium M Toshiba laptop with basic on-board Intel soundcard. An i5 540m @ 2.67 ghz goes down to 16 samples (at least with no complaints from ALSA or Csound). An external USB soundcard on the i5 seems to go no lower than 32 samples. The main thing is making sure ALSA connects directly to your soundcard without going through dmix. This of course limits you to using one audio app at a time. If you need to have multiple applications making/receiving at low latencies , you will need to deal with the tedious per-session configuration of JACK.
- BFay 12y ago
  As anon4 mentioned, it's pretty easy now to set up low-latency audio now with jack. The hardest thing is probably navigating through the tons of documentation on it, much of which is outdated (the newer version of jack is a bit different to set up, you call jack_ctl instead of directly using jackd) For best results, you should install a low-latency or realtime kernel. On Ubuntu, it's easy to find low-latency kernels through the repos, and Fedora has a realtime kernel through the PlanetCCRMA repos (although this randomly crashed on my last, approx 5-year old laptop). On other distros you may have to compile your own patched kernel, and there's plenty of documentation on this. There's also some distros specifically for audio work, that are set up out of the box with great low-latency settings (Ubuntu Studio, KXStudio for example) On my current laptop, I'm running jack at 48kHz, with 3 buffers of 64 samples, using a Focusrite Scarlett 2i4 interface. I haven't really noticed any significant dropouts so far. This is on Ubuntu with a low-latency kernel. With the Pulseaudio jack sink, pulse is basically piping its output into jack, which is especially convenient if I want to do something like record audio streaming from a browser.
- CAMLORN 12y ago
  My problems with compilation of PortAudio were primarily related to ksgid.lib which is apparently now removed from Visual Studio. It's been a while since I did that one so i don't remember specifically what I had to do, but combined with the fact that (on my machine) all the backends but WinMM had to be turned off, it wasn't ultimately important either way. As I recall, it needed a code crawl to find the guilty pragma and some preprocessor definitions that killed it. Portaudio powered the audio for about 4 months before I finally got around to dropping it for the next option, primarily because of latency. Downgrading VS wasn't an option because I lean very heavily on C++11, especially smart pointers and closures.
CAMLORN 12y ago
I've got a lot of open questions about ASIO, including one interesting one: will it knock out other apps and can this be avoided? Finding this out has been on my to-do list forever, but I'm visually impaired and many of my users will ultimately be as well, so I can't have it just killing the assistive technology. I'm not sure how that fixes the higher channel count problems with PortAudio anyway. If you've got more info, I'm open to it-I'd love a solution to fall from the sky.

I have written quite a bit of cross platform audio code. Portaudio really works fine. If you need low latency on Windows, use the ASIO backend. Compiling it on Windows is a bitch, though.

stinos 12y ago

Didn't find compilation particularly hard on Windows, might be because I know the tools very well though. On the latency: do you (or anyone reading this) happen to knwo what's the current state of low latency audio (say <5mSec) on linux? A couple of years ago we did an application for human auditory system research which required stable (as in, not ever dropping any buffers) low latency. Original idea was to do it for both windows and linux, the gui would be Qt anyway so that got the cross-platform part coverd already. We were using an RME Multiface and on windows we'd just hook it up and select e.g. 48kHz 128samples buffersize, full duplex and it just worked without any problems with the standard ASIO samples. On linux we initially hardly managed to get anything out at all. And once that was fixed, it was impossible to get down to the required latencies without dropping buffers. Even with the semi-realtime kernel patches or whatever it's called. Anyway, we gave up back then but I still wonder: was it just our lack of knowledge, or was linux back then (about 7 years ago) really not up to the task, or was it a driver problem? And what is the state today?

anon4 12y ago
Today the state is (almost) as it always was: 1. Install and set up JACK. Enjoy your lack of latency. I haven't profiled it scientifically, but I've tried microphone monitoring with filters layered on and couldn't detect any latency between me speaking and my voice coming out the speakers. 2. Modern linux uses pulse. Pulse is kind of jingoist and slightly hostile to foreign presence. You'll need to edit its default.pa file to not load the udev-detect module and not try to just grab the soundcard for itself, but to load the jack-source and jack-sink modules. You'll also need to write a script to do the module loading because modern desktop linux doesn't have a race-free way to start daemons when a user logs in. Which you'll have to run manually once you log in. That script looks like this: #!/usr/bin/sh pacmd load-module module-jack-source channels=1 pacmd load-module module-jack-sink channels=2 Oh, and if it wasn't apparent, only one user can use the audio.
jseg123 12y ago
Using Gentoo, (no GUI just bash command line environment) and ALSA back-end, I got a latency of 64 samples, which seemed indistinguishable from dedicated sampler hardware when triggering audio files in Csound via a USB MIDI keyboard. This was using a 1.2 ghz Pentium M Toshiba laptop with basic on-board Intel soundcard. An i5 540m @ 2.67 ghz goes down to 16 samples (at least with no complaints from ALSA or Csound). An external USB soundcard on the i5 seems to go no lower than 32 samples. The main thing is making sure ALSA connects directly to your soundcard without going through dmix. This of course limits you to using one audio app at a time. If you need to have multiple applications making/receiving at low latencies , you will need to deal with the tedious per-session configuration of JACK.
BFay 12y ago
As anon4 mentioned, it's pretty easy now to set up low-latency audio now with jack. The hardest thing is probably navigating through the tons of documentation on it, much of which is outdated (the newer version of jack is a bit different to set up, you call jack_ctl instead of directly using jackd) For best results, you should install a low-latency or realtime kernel. On Ubuntu, it's easy to find low-latency kernels through the repos, and Fedora has a realtime kernel through the PlanetCCRMA repos (although this randomly crashed on my last, approx 5-year old laptop). On other distros you may have to compile your own patched kernel, and there's plenty of documentation on this. There's also some distros specifically for audio work, that are set up out of the box with great low-latency settings (Ubuntu Studio, KXStudio for example) On my current laptop, I'm running jack at 48kHz, with 3 buffers of 64 samples, using a Focusrite Scarlett 2i4 interface. I haven't really noticed any significant dropouts so far. This is on Ubuntu with a low-latency kernel. With the Pulseaudio jack sink, pulse is basically piping its output into jack, which is especially convenient if I want to do something like record audio streaming from a browser.
CAMLORN 12y ago
My problems with compilation of PortAudio were primarily related to ksgid.lib which is apparently now removed from Visual Studio. It's been a while since I did that one so i don't remember specifically what I had to do, but combined with the fact that (on my machine) all the backends but WinMM had to be turned off, it wasn't ultimately important either way. As I recall, it needed a code crawl to find the guilty pragma and some preprocessor definitions that killed it. Portaudio powered the audio for about 4 months before I finally got around to dropping it for the next option, primarily because of latency. Downgrading VS wasn't an option because I lean very heavily on C++11, especially smart pointers and closures.

CAMLORN 12y ago

I've got a lot of open questions about ASIO, including one interesting one: will it knock out other apps and can this be avoided? Finding this out has been on my to-do list forever, but I'm visually impaired and many of my users will ultimately be as well, so I can't have it just killing the assistive technology. I'm not sure how that fixes the higher channel count problems with PortAudio anyway. If you've got more info, I'm open to it-I'd love a solution to fall from the sky.