That sounds great, thanks Patrick!On Fri, Oct 4, 2013 at 11:14 PM, Patrick Shirkey <pshirkey at boosthardware.com wrote:
On Sat, October 5, 2013 2:44 pm, T. Joseph Carter wrote:
On Thu, Oct 03, 2013 at 06:51:05PM +1000, Patrick Shirkey wrote:
sigh Wasn’t ALSA supposed to fix all of that crap when it replaced
OSS?Not exactly. ALSA is what OSS would have been if Sampo had not taken it
private.But unlike OSS, ALSA is not implemented outside of Linux is it? And
there was mention of “Device or resource busy” using ALSA??? That’s
supposed to be one of the things that just doesn’t happen with ALSA.I can see how with things like PA providing emulation that those may
fail to support multiple users on an emulated interface in a graceful
manner. In which case, I might suggest that the emulated interface
should be considered an advanced feature to be used as a last ditch
effort to add network transparency to an application that doesn’t
know how to communicate with either it or JACK.In this case, it is generally appropriate for PA and JACK to both
talk to ALSA (and probably directly, since neither one appears to be
trying to provide the other’s functionality. The similarities appear
to be quite superficial, from what I can see.Nah, JACK is pretty useful. It’s what EsounD/aRts should
have been, and PulseAudio just looks like multimedia sound API by
committee. No wonder that ain’t working out well.PA was originally sponsored by Redhat and is now being driven mostly by
Intel. It is the default sound server for all the major distros and
several mobile OS’s too. Sure there are still some bugs but they can only
be fixed if they are reported.I guess my issue really is the multiple layers of abstraction and
indirection. To me, it’s like someone resurrecting SVGALib (now
that’s a blast from the past!) to port it to the Linux framebuffer
and then running X on top of SVGAlib! It’s madness.Now, I quite clearly remember the GGI project being very proud of
being able to do crazy crap like that, but I also remember that it
was primarily an exercise in geek cred to have accomplished some
ridiculously hair-brained setup like that just to prove that GGI
would do it.Plus JACK is now used much more widely than just the Linux audio
world. It gets used on the Mac for some professional audio stuff,
particularly if it’s available for Windows and Mac. I’ve also seen
it used on the iPhone, though as a client.You are correct. JACK is supported on Linux, OSX, iOS, Windows, Freebsd.
Unfortunately the Android and ChromeOS Teams have chosen to make it
technically impossible to run JACK on a standard Android build but they
did borrow significant amounts of the JACK codebase to write their own
versions of low latency audio servers for each platform. They just left
out all the good stuff like inter app comms. midi, networking, session
management. We still hold out hope that one day they will change their
policy on Android at least.Is what they use on Android at least an API subset as GLES is (in
theory) a subset of a corresponding OpenGL spec version? Or at
least, how that used to be the case until 3.x kind of blurred the
lines on that just a little???I don’t use it myself, but if I ran a Linux setup with a sound driver
that was not multi-open capable (again, wasn’t ALSA supposed to fix
that?), I’d definitely install JACK and make the various DEs connect
to it, either directly or via whatever server they require.IMO, JACK is about as close to CoreAudio as you’re going to see on a
platform where everyone does their own thing.IMO, the combination of PA + JACK provides a more powerful system than
coreaudio and it is a cross platform solution too.The nice thing about CoreAudio on the Mac is that generally all Mac
apps written to modern standards specifically for the Mac that do
anything substantive for the Mac use CoreAudio. That’s not the case
with JACK on Linux.Of course the same can be said of Direct3D on Windows, and I still
prefer OpenGL as a standard, cross-platform implementation. It was
admittedly kind of hard to argue in favor of OpenGL for awhile there
simply because Direct3D represented the hardware and the trends in
how it was being used and OpenGL had a bunch of incompatible
extensions that were comparatively pretty lame. Apparently the
converse is true today.Bottom line though, it seems that supporting JACK is essential on
Linux because there simply is no single “standard” for Linux that
just works. And of the various competing standards that aren’t ALSA,
JACK is probably the best of them.That’s my take, anyway.
ALSA is two things in one. It is the hardware/driver layer which is in the
kernel and it is also the ALSA-lib API. The point of JACK is to provide an
API which deals with the challenging issues of realtime low latency audio
and interapp communication. That way the developer just has to connect to
JACK to get all the professional audio features. JACK communicates via
ALSA lib but the additional very low latency context switches are as close
to the metal as it gets and are considered a worthy tradeoff for all the
open source professional audio apps and many multimedia apps too including
blender, open movie editor, vlc, ffmpeg, mencoder, etc…Pulse Audio is designed to deal with software mixing on the desktop in a
consumer system. That means things like connecting your headphones and
having the audio play through them automatically, handsfree bluetooth
support, and playing audio from skype, chrome and vlc at the same time. It
"hijacks" direct calls to alsa lib api and routes them through it’s own
internal graph. That gives uses the ability to adjust the volume and have
different apps sent to different audio devices.They serve two quite different purposes.
I had a quick look at the patch from the forum and it seems that the audio
codebase has changed a bit since then. I will try to spend some time on it
this next couple of weeks to get it to compile. Otherwise the basic
functionality looks like it will work just fine. We can get some eyeballs
from the jack devs to give it the once over before it is made official
though to make sure the implementation is as efficient as possible.–
Patrick Shirkey
Boost Hardware Ltd
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
