news about the audio backend rewrite and the return of the dreaded mixahead

[Austin Hicks]

Hi,


As some of you know, I'm applying for the Holman prize to work on
accessible graphing. There's an explanatory blog post here:
http://camlorn.net/posts/March%202017/holman-prize-application.html


In addition Chris hofstader wants to discuss Libaudioverse at
LibrePlanet in a few weeks, with a possible eye to getting some sort of
funding.


So what does this have to do with anything? Well, there was going to be
a basic accessible graphing calculator demo as part of the Holman
Prize. Then Michael Curran decided to update libaudioverse in
AudioScreen and comes to me with a bit of the problem: "Hey, so, this
isn't working on one of my test machines." Which is of course what you
want to hear right as you're about to use your library for a big,
important, potentially money-making demo with a deadline 3 days away.
Obviously the demo didn't happen. Whether it matters, we'll see.


It turns out that somewhere along the way Windows 10 probably changed
default timer frequencies again, and we're super sensitive to whether or
not something that changes the timer frequency has done so. The main
culprit in the blindness community is still Chicken Nugget or anything
else using base. Probably this was a Windows 10 update, but most of the
people running Libaudioverse are also running something that uses base,
so no one caught it.


The moral of the story is that this makes the bindings generator rewrite
lower priority, so the next project is the audio_io refactor. And
LibrePlanet makes the Rust compiler work low priority because I've got a
deadline, so this should be happening over the next week. I cannot
patch it in such a way that it will continue working anymore; any
numbers I pick will break it for someone.


As for mixahead: the min latency and max latency stuff was a stupid idea
because of part of how audio APIs actually work, and the bugs to do with
timing have forced the min latency (which still exists internally, even
though you can't publicly set it) up. But you need some sort of knob
for when you're pushing things beyond where they can reliably mix in
less time than it takes to do a block (recall that the OS can randomly
sleep your threads), so I have to bring it back. For Python users, this
will be set for something reasonable. If you're using it directly from
C, there will be a minor API breakage with lav_serverSetOutputDevice. I
may go for a design that allows varying it at runtime in future, but
latency is going to be fixed again. Every other audio thing does it
this way, and I probably should have left well enough alone.


I will likely also bump our dependency on Boost up to 1.62 or maybe
1.63, with the intent to freeze it there; remove our dependency on glm
(because Boost now provides some 3D math stuff); and fold some or all of
the auxiliary repositories into Libaudioverse because they don't
actually work out so well separated like they are at the moment. This
last is primarily because developing Libaudioverse will be easier if I
am allowed to increase the coupling. Also logger_singleton is useless,
powercores can just be done via Boost, and speex_resampler_cpp will
probably go away because I need to write 75% or so of it as reusable
components for other parts of Libaudioverse. I doubt many people care
about this part of it, but nonetheless.

[Chris Norman]

Hey mate,

I wish you the very best of luck on all your funding attempts, as usual,
anything I can do to help please let me know.


Thanks as always for your work with LAV, it's very much appreciated.


Take care, and once again good luck!