FLTK works with most threading approaches - you can use pretty much any thread lib, or C++ threads, or whatever you are used to and make it work.
FLTK doesn't provide any threading primitives of it's own but a minimal implementation is shown in the test/threads sample, that just wraps pthread_create() on most hosts or _beginthread() on WIN32 - the API is "similar enough" that it is trivial to wrap them up to look "the same" to the rest of your code.
If you are doing multi-threading with FLTK, do read and understand the "Advanced FLTK" chapter of the docs. first though.
Also, I'd advise you to only use the simplest thread mechanics - in 40-odd years of coding, I've seen all manner of incredibly clever and sophisticated thread schemes, and they always led to disaster!
Keep it simple...
Audio-wise, I personally still use portaudio, but again pretty much any portable audio lib should work.
As with threads, FLTK has no specific mechanism for audio - though the test/sudoku sample does implement a simple audio class that variously wraps ALSA (*nix systems) CoreAudio (OSX) or WIN32 audio.
In the sudoku sample it is only used to make beeps and pings, so doesn't need an extra thread to keep the audio stream fed, but the audio code that's there could handle more complex audio streams if needed.
For continuous audio a separate thread would probably make the most sense, it's certainly what I do, though if you can keep the audio output buffer filled from a simple timer callback, without blocking your main thread, that can be sufficient - I have certainly seen this done successfully, though it's not the way I'd do it myself!
Actually... I haven't checked, but I have an idea that might be what the test/blocks demo does - might be worth a look, at any rate!
I think it uses basically "the same" audio wrapper mechanics as the sudoku sample, but ISTR it has more complex audio outputs.