

The Horror of Cross-platform Audio Output - ctoth
http://camlorn.net/posts/december2014/horror-of-audio-output.html

======
caf
I still remember when audio output meant writing your own interrupt handler
and directly poking IO ports, so at least we've come a _little_ way since
then.

~~~
spacemanmatt
or breadboarding a DAC-to-parallel-port "sound card" because the piezo buzzer
just didn't cut it

~~~
ackalker
Ah the Covox[1] craze, sweet memories.

BTW: I think you meant to say "parallel-port-to-DAC", where "DAC" all too
often meant just a simple cobbled-together resistor ladder.

Who cares about HiFi when you can have actual sampled sounds instead of tinny
beeps? :-)

~~~
caf
It was also possible to play sampled sounds through the PC speaker using
pulse-width modulation. Now _that_ was a hack.

------
demarq
Interesting to see that a number of complaints have been levelled against the
build systems.

It shows just how careful maintainers should be about creating smoother build
experiences. Anyway I hope the author of the article will post a follow up
with his new library.

~~~
chris_wot
That is 100% the reason why Libreoffice has taken often leave Apache
OpenOffice in the dust. Seriously.

~~~
vog
Interesting idea. Do you have any evidence for that theory?

~~~
chris_wot
Ever tried to build Apache Open Office?

------
Derbasti
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
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
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.

------
th0br0
Why not simply use FMOD / FMODEx? AFAIR their cross-platform support is quite
excellent, and their license is free for anything open source or <$100k budget

------
anon4
For a library like that, isn't it also a good idea to let me plug in my own
backend? That is, let me specify the sample format I want and either provide a
function I can call that will fill a buffer with samples, or ask me to give
you a callback that you can call once you have samples ready. Preferably, let
me choose which model fits my use better.

~~~
CAMLORN
Libaudioverse separates the audio backend from the audio simulation. It is
already possible to do this: you create what I call a read simulation, set up
your objects and connect them, and then use getBlock on it. Allowing the
computation of an arbitrary number of samples is not permitted because it
introduces a number of performance headaches and code complexities; in
addition, I've not yet seen anything related to audio output that randomly
resizes the blocks on you. If there's enough people that need me to add a
queue that automatically breaks the blocks, I will do so. Either way, you can
already send it anywhere, and I could have it working on platforms without
backends with a minor code change.

More interestingly, if you are connected to an audio device, you can use a
GraphListener. GraphListeners call a callback on you every time a block gets
processed. As a consequence, it's also more than possible to do stuff like
live stream over the internet. I am debating the merit of a backend that
advances the simulation without playing: I can see potential uses for it, I'm
just not sure if they're good ones.

------
RossBencina
As one of the developers of PortAudio, I would appreciate it if the author of
the post could clarify the specific bugs that he found. We received no bug
reports from the author.

------
JoshTheGeek
MathJax ([http://www.mathjax.org/](http://www.mathjax.org/)) will render LaTeX
math in the browser. The result is quite pretty.

------
frozenport
Use Qt, as a bonus it has a widget kit?

~~~
Derbasti
As a downside, you don't get access to the audio data.

------
chris_wot
Why is cubeb not its own library?

~~~
gcp
It is?

The problem is that the authoritative source sits inside the Firefox tree.
Mozilla makes a standalone version (that doesn't require that tree) available
on GitHub, but you're not going to have much luck contributing back if your
contributions break the Firefox build.

The solution proposed would be to make the GitHub the authoritative source,
and patch the Firefox version. But that shifts the maintenance burden in the
way that's opposite to the main developers' interests. I can see why there's
no enthusiasm.

I've contributed to libcubeb and had no problems with the above. But my
contributions were not of the "lol I don't like automake so let me replace
your entire buildsystem" kind. Honestly if that's the kind of thing you're
trying to do, I think almost any open source project will push back.

~~~
chris_wot
Ok, didn't realize that. I'm abut suspicious of the main article now.

