Audio, Speex, and VoIP

[Peter Froehlich]

Hi all,

I doubt I'll be able to spend major amounts of time on this, but... I
think hacking a simple VoIP application in Go might be a nice example
for the lanuage? It's supposed to be for server work after all, why
not for a VoIP chat server (and client of course)?

I've looked around a little, and it seems that if we could get
together Go bindings for libspeex as well as for either libao or
libopenal we'd have the basic pieces for it. I know there are people
working on GUI stuff (which would be interesting for the client once
the basic stuff works) but I am not aware of anyone looking into those
audio-related libraries. If you feel like working on one of those,
please announce it loudly so I can follow your work and maybe help a
little here and there. :-D

BTW, I think there's actually a market for another free gaming-style
VoIP solution. The two dominant free/portable ones, TeamSpeak and
Mumble, both have various problems that make them somewhat of a bummer
to use. Something that covers the basics, uses current technologies,
has fewer dependencies, is free, eats comparatively few cycles, and
has a simpler server configuration/setup could actually make a big-ish
splash.

Cheers,
Peter
--
Peter H. Froehlich <http://www.cs.jhu.edu/~phf/>
Senior Lecturer | Director, Johns Hopkins Gaming Lab

[Peter Froehlich]

I just noticed the huge problem with audio APIs, and then I remembered
that someone else had complained about it already: No callbacks from C
into Go. :-/ I'd much rather have those pesky callbacks than new
semicolon rules... :-)

[Peter Froehlich]

Hi all,

On Sat, Dec 12, 2009 at 3:17 AM, Peter Froehlich
<peter.hans...@gmail.com> wrote:
> I just noticed the huge problem with audio APIs, and then I remembered
> that someone else had complained about it already: No callbacks from C
> into Go. :-/ I'd much rather have those pesky callbacks than new
> semicolon rules... :-)

I just realized that OpenAL should allow simple playback and record
without the need for callbacks. I am not sure yet, but it certainly
looks like it. So I am trying to do a very simple OpenAL binding:

http://github.com/phf/go-openal

I'd be happy to get some help, especially if anyone here has done
OpenAL in the past. I haven't. So for me it's quite a wild ride. :-D

Cheers,
Peter

[Uriel]

On Sun, Dec 13, 2009 at 11:57 PM, Peter Froehlich
<peter.hans...@gmail.com> wrote:
> I just realized that OpenAL should allow simple playback and record
> without the need for callbacks. I am not sure yet, but it certainly
> looks like it. So I am trying to do a very simple OpenAL binding:
>
> http://github.com/phf/go-openal
>
> I'd be happy to get some help, especially if anyone here has done
> OpenAL in the past. I haven't. So for me it's quite a wild ride. :-D

I added a link to your go-openal project to
http://go-lang.cat-v.org/library-bindings

Also, not sure if it does what you want, but there is:
http://github.com/moriyoshi/pulsego/

uriel

[Peter Froehlich]

Hi all,

On Sun, Dec 13, 2009 at 6:39 PM, Uriel <ur...@berlinblue.org> wrote:
> Also, not sure if it does what you want, but there is:
> http://github.com/moriyoshi/pulsego/

I saw that, but PulseAudio doesn't have a great reputation with
hardcore gamers. It's therefore less likely to be on any machine out
there than OpenAL (which plenty of game engines use), and since my
idea was to eventually build a VoIP system for games... :-D

[Peter Froehlich]

Hi all,

Just an update: I've been making more progress on this than I
expected, so we're actually a lot closer to some form of audio for Go.
However, I've also decided to change the binding to expose most of the
C API for OpenAL, and I am still refactoring all of that.

Two Go features I *love* as a result of this experience: Methods for
"basic" types and embedding of structs. You can see why in the
recently added openal/al and openal/alc packages on github.

OpenAL uses uint32 to name things it calls "sources" and "buffers".
Since I can add methods to something like "type Source uint32" dealing
with sources and buffers turns out to be efficient (well, as efficient
as cgo let's you be anyway) since I can save myself allocations *and*
the resulting "classes" make Go OpenAL code look a lot nicer than C
OpenAL code.

OpenAL also has things called "devices" and an addition called
"capture devices" to record audio that was added later. Since the C
API returns pointers for those, I have to wrap them into their own
*Device and *CaptureDevice things (otherwise the Go restriction
regarding implicit assignments is violated). So that's a drawback, but
it's minor. What's a major advantage is that I can define
CaptureDevice as follows:

type CaptureDevice struct {
Device;
}

Now all the "shared" operations work fine, *and* I get to add the
capture-specific methods in a way that totally avoids any possibility
for the programmer to call them on a non-capture device by accident.
It all worked out surprisingly well so far, making me a happy Go
hacker regardless of the brace syntax. :-D

[Peter Froehlich]

I am moderately done wrapping the "al" API of OpenAL. I still need to
write a few more convenience functions/methods to get rid of the "pass
an int to a generic function to tell it what to do" approach for most
of the binding. But otherwise it's done.

http://github.com/phf/go-openal/tree/master/al/

Of course it's useless by itself, but it gives you a flavor. After
grading exams I'll get back to the "alc" and "alut" APIs which are not
in good shape yet (so don't look). I'll do them in a similar style: As
close to C as possible, but refactored to look nicer in Go. That'll
probably take a week.

After that I can finally write the *really* nice Go API on top of
those layers. I am having fun. :-D