Windows build / switch to PortAudio

[ghost]

Well, I was thinking about porting cava to Windows & OS X, and I think a switch to PortAudio would be great, because it solves some of the issues.

Also: I think you can use PortAudio on Android, so that'd be nice.

PortAudio is a free, cross-platform, open-source, audio I/O library. It lets you write simple audio programs in 'C' or C++ that will compile and run on many platforms including Windows, Macintosh OS X, and Unix (OSS/ALSA).

[anko]

Observations:

• Windows has no ncurses—the console rendering library we'd like to use.
• Cross-platform support without automated tests (Automated unit tests? #21) is painful.
• Since rendering likely differs most between OSs, having the code calculating bar heights separated from rendering (Raw output? #24) would help.

I think those are prerequisites for a Windows / OSX port.

If the bar calculation code were extracted to a “libcava” library, it would likely be easiest to treat “Linux cava”, “Windows cava”, et cetera as separate projects, as they'd share very little code.

[ghost]

Windows has no ncurses—the console rendering library we'd like to use.

We could go with cygwin, which supports ncurses. You can distribute it with cygwin's dll to make cava standalone.

Since rendering likely differs most between OSs, having the code calculating bar heights separated from rendering (#24) would help.

Framebuffer graphics would be great.

The biggest issue is that the code is so painfully nonmodular (i.e. the "shared" variable, which makes everything hard). I've tried to separate different parts (i.e. move input_alsa -> input/alsa.c; input_fifo -> input/fifo.c; drawing -> output/terminal.c; etc.), but I wasn't able to do it.

[karlstav]

Sounds possible. I think it would help if we where able to separate cava in to three different "parts" first:

• Audio extraction (separate: portaudio, fifo, alsa...)
• Bar calculation (shared)
• rendering (separate: ncurses, printf...)

(@CelestialWalrus I was just writing this when you commented. )

The shared variable is, I admit, not ideal... I needed a way to pass the audio from the audio thread to the main thread. Any other way of doing this?

[ghost]

@karlstav maybe pointers, but I'm not sure if those work with pthread. Or execute the input_* function in realtime (i.e. while (whatever = input_alsa(args))).

I'd like to suggest a directory structure if you don't mind:

|
|- input
   | alsa.c/alsa.h
   | fifo.c/fifo.h
|- output
   | terminal.c/terminal.h
| cava.c
| Makefile

(...and that autoconfigure thing, but I'm not sure how to exactly use it)

[karlstav]

Looks good.

If you're thinking about executing the alsa input audio as a function, not a thread, every time cava is supposed to listen to audio. I already tried it en early early development. It didn't work very well as I missed huge chunks of the audio.

Pointers might work, I think I tried that as well, but because I suck at pointers I got nowhere.

[nikp123]

Ironically enough I made a "working" WIN32 renderer (which compiles only under cygwin for now) only to find this. Would like to switch to a non-Pulseaudio/ALSA thing to make this actually usable.

[karlstav]

@nikp123 portaudio is the thing then. I don't think the implementation would be so difficult now, as the problems disused in this thread have been solved.

One question that remains is how to capture audio from application or output in portaudio.

[nikp123]

@karlstav someone already asked that question, but I'm not sure how accurate are the results that the guy got.

[nikp123]

@karlstav This and this commit may be of interest.
_{^{I made the darn thing, YAY!}}