3 Feb
2003
3 Feb
'03
6:29 p.m.
Kidding aside, this may prove to be so ubiquitous that it will quickly
overshadow all other implementations. It's the MAS audio server that is
going to be implemented into the X server itself and will be
network-transparent.
Slashdot just posted a news blurb on it:
http://slashdot.org/article.pl?sid=03/02/03/2137213
For more info see:
http://www.mediaapplicationserver.net/indexframes.html
Any ideas if this will be also good for pro-audio stuff?
Ivica Ico Bukvic, composer, multimedia sculptor,
programmer, webmaster & computer consultant
http://meowing.ccm.uc.edu/~ico
============================
"To be or not to be" - Shakespeare
"To be is to do" - Socrates
"To do is to be" - Sartre
"Do be do be do" - Sinatra
"2b || ! 2b" - ?
"I am" - God
3 Feb
3 Feb
8:04 p.m.
Kidding aside, this may prove to be so ubiquitous that
it will quickly
overshadow all other implementations. It's the MAS audio server that is
going to be implemented into the X server itself and will be
network-transparent.
Slashdot just posted a news blurb on it:
http://slashdot.org/article.pl?sid=03/02/03/2137213
For more info see:
http://www.mediaapplicationserver.net/indexframes.html
Any ideas if this will be also good for pro-audio stuff?
no sign of that. this is the same old design. sigh. no sample sync,
the whole thing is still based on the idea of applications deciding
what and when to do their stuff. sigh, sigh, sigh. it looks like a
decent thing for network-based apps, but nothing more than that. clean
API, though.
--p
4 Feb
4 Feb
4:29 a.m.
Paul Davis wrote:
This is what I've attempted to explain you last time.
Do you remember? Fragmentation, fragmentation, fragmentation...
What we'd need is a global solution to audio server space.
The problem is that none exists (and jack is not an exception) and we're
doomed to suffer still for long time if we're not able to understand
that.
I hope that my point is now clear, at least to you.
I've thought more about your pro callback arguments and you've convinced
me that it may be a smarter solution for some class of applications.
Despite that I strongly think that an audio server that not permit in
native way the traditional approach (what you call blocking approach)
will never achieve the driving role we'd need.
--
Abramo Bagnara mailto:abramo.bagnara@libero.it
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
Kidding aside, this may prove to be so ubiquitous
that it will quickly
overshadow all other implementations. It's the MAS audio server that is
going to be implemented into the X server itself and will be
network-transparent.
Slashdot just posted a news blurb on it:
http://slashdot.org/article.pl?sid=03/02/03/2137213
For more info see:
http://www.mediaapplicationserver.net/indexframes.html
Any ideas if this will be also good for pro-audio stuff?
no sign of that. this is the same old design. sigh. no sample sync,
the whole thing is still based on the idea of applications deciding
what and when to do their stuff. sigh, sigh, sigh. it looks like a
decent thing for network-based apps, but nothing more than that. clean
API, though. 
7:17 a.m.
On Tue, 4 Feb 2003, Abramo Bagnara wrote:
Despite that I strongly think that an audio server
that not permit in
native way the traditional approach (what you call blocking approach)
will never achieve the driving role we'd need.
Well, given that Ardour, amsynth, alsaplayer, and freqtweak all use jack,
I'm pretty happy with how it is. It doesn't need to gain any more
applications to be considered a success as far as I'm concerned.
Taybin
--
http://www.piratesvsninjas.com
7:55 a.m.
On Tue, Feb 04, 2003 at 07:10:39 -0500, Taybin Rutkin wrote:
On Tue, 4 Feb 2003, Abramo Bagnara wrote:
I'd say that AMS, SSM, pd and ecasound mark it as a success :)
I dont see how nayone could dismiss JACK in this respect, it does one thing
(lowlatency synced audio for music creation apps) and it does it very well.
- Steve
Despite that I strongly think that an audio
server that not permit in
native way the traditional approach (what you call blocking approach)
will never achieve the driving role we'd need.
Well, given that Ardour, amsynth, alsaplayer, and freqtweak all use jack,
I'm pretty happy with how it is. It doesn't need to gain any more
applications to be considered a success as far as I'm concerned. 
6:13 p.m.
Steve Harris wrote:
On Tue, Feb 04, 2003 at 07:10:39 -0500, Taybin Rutkin
wrote:
Agreed. Different apps have different needs. Jack is probably serious
overkill
for a lot of simple audio playback needs, but something like MAS [isn't
that also
the name of MOTU's plugin API?] is obviously not serviceable for
pro-quality
work. I agree though that a MAS backend for JACK might be a good thing.
-dgm
On Tue, 4 Feb 2003, Abramo Bagnara wrote:
I'd say that AMS, SSM, pd and ecasound mark it as a success :)
Despite that I strongly think that an audio server
that not permit in
native way the traditional approach (what you call blocking approach)
will never achieve the driving role we'd need.
Well, given that Ardour, amsynth, alsaplayer, and freqtweak all use jack,
I'm pretty happy with how it is. It doesn't need to gain any more
applications to be considered a success as far as I'm concerned.
I dont see how nayone could dismiss JACK in this
respect, it does one thing
(lowlatency synced audio for music creation apps) and it does it very well.
- Steve
9:06 a.m.
Despite that I strongly think that an audio server that
not permit in
native way the traditional approach (what you call blocking approach)
will never achieve the driving role we'd need.
if linux developers continue to work with this traditional model, then
yes, i think you are right and its a deep problem.
but i see a brighter future because i think that slowly more and more
developers will choose to adopt the same models they would be required
to use on windows or macos. this will happen, even if its just because
the developers will be coming from windows/macos :)
besides, i think that the take-home message from so many of the
discussions about audio servers is that there is no truly universal
solution. what's needed are acceptable ways to move data between
"worlds". the "world" (the non-MOTU) MAS represents is very different
from the one JACK represents, but its quite possible to build a
gateway between them. this does perpetuate the different programming
models, but i think we just have to accept this. mac os x is the only
system to have gotten this right so far, and i see no way we can do
what they've done because nobody has enough control to impose a single
solution.
i suspect that even if someone stepped forward with a full linux
implementation of the AU/CoreAudio API, there would be just as much
resistance to it as there is to any other proposed "universal"
solution. developers for mac os x don't have the choice. alas, we do.
--p
3:53 p.m.
New subject: [linux-audio-dev] newest audio server for Linux (yep, yet another)
On Tue, 2003-02-04 at 06:03, Paul Davis wrote:
Right now the only ways to choose a callback model in Linux audio
applications are:
* use JACK. Using JACK directly only makes sense for:
1. applications whose only possible use in in a JACK graph (jackrack)
2. applications whose target audience is only people who are so into
RT audio that they're willing to obtain JACK and tweak latency
settings
* write a custom audio thread for ALSA or OSS. This takes a lot of
work and time to get right. I don't know of any applications that
actually do this.
* use PortAudio.
My point is that given the status quo, I don't think we will see a move
to callback-based design. OSS and ALSA are perceived as most native and
most ubiquitous, and these most naturally lend themselves to the
blocking model.
I'm not quite ready to toot my PortAudio horn yet, only because v19 is
not yet ready. Here's what I will say now: I think PortAudio has the
potential to be the unifying force in the fragmented Linux audio world.
Imagine being able to write to an API as simple and well-designed as
this: <http://www.portaudio.com/docs/v19-doxydocs/portaudio_8h.html>
Now imagine that linking against this library will give you access to
OSS, ALSA, JACK, and whatever other APIs come along *all in a single
build*. Imagine getting the same performance as if you had written to
these APIs directly. And imagine having your audio i/o be portable to
Windows and Mac with just a recompile.
This is becoming a reality. I have spent the last week rewriting
Audacity's audio i/o to use PortAudio v19 and simultaneously improving
my PortAudio ALSA implementation to be good enough to support it. The
results have been satisfying.
I foresee resistance from people who perceive portability APIs as a
compromise, as having poor performance. This is simply not the case.
No one would accuse JACK of having poor performance, though it works by
wrapping other APIs. The truth is that the combination of a
well-designed API and careful implementation can yield wrapper APIs that
perform just as well as programming directly to the underlying API.
A great deal of thought has gone into the PortAudio API, you can read a
record of the proposals that went into v19 at
<http://www.portaudio.com/docs/proposals/index.html>
I am interested to hear responses to this. Once PortAudio v19 is
released, would you all as application authors be willing to adopt it in
your programs? If so, why not? In my opinion, the only group of
applications that would not benefit from using PortAudio are those that
are so closely tied to JACK that they don't make sense outside of a JACK
graph.
Regards, Josh Haberman
Despite that I
strongly think that an audio server that not permit in
native way the traditional approach (what you call blocking approach)
will never achieve the driving role we'd need.
if linux developers continue to work with this traditional model, then
yes, i think you are right and its a deep problem.
but i see a brighter future because i think that slowly more and more
developers will choose to adopt the same models they would be required
to use on windows or macos. this will happen, even if its just because
the developers will be coming from windows/macos :) 
4:51 p.m.
New subject: [linux-audio-dev] newest audio server for Linux (yep, yet another)
On Tue, 2003-02-04 at 20:47, Josh Haberman wrote:
Imagine being able to write to an API as simple and
well-designed as
this: <http://www.portaudio.com/docs/v19-doxydocs/portaudio_8h.html>
Just out of interest, why are paNoDevice, paFloat32, etc, defines
instead of const values?
Bob
--
If you're happy and you know it, bomb iraq
7:33 p.m.
New subject: [linux-audio-dev] newest audio server for Linux (yep, yet another)
On Tue, 2003-02-04 at 13:41, Bob Ham wrote:
On Tue, 2003-02-04 at 20:47, Josh Haberman wrote:
I don't really know. Isn't that kind of a six/half-dozen detail? What
do const values give you besides a minute amount of extra type-safety?
I had almost no part in designing the API.
Josh
Imagine being able to write to an API as simple
and well-designed as
this: <http://www.portaudio.com/docs/v19-doxydocs/portaudio_8h.html>
Just out of interest, why are paNoDevice, paFloat32, etc, defines
instead of const values?
5 Feb
5 Feb
6:21 a.m.
New subject: [linux-audio-dev] newest audio server for Linux (yep, yet another)
On Wed, 2003-02-05 at 00:26, Josh Haberman wrote:
On Tue, 2003-02-04 at 13:41, Bob Ham wrote:
Probably. I think it was Bjarne Stroustrup who said something along the
lines of "Every use of a define is an instance of a programmer not
programming correctly." But I was just wondering if it was some
portability thing or something.
Bob
--
Bob Ham <rah(a)bash.sh>
On Tue, 2003-02-04 at 20:47, Josh Haberman
wrote:
I don't really know. Isn't that kind of a six/half-dozen detail? Imagine being able to write to an API as simple
and well-designed as
this: <http://www.portaudio.com/docs/v19-doxydocs/portaudio_8h.html>
Just out of interest, why are paNoDevice, paFloat32, etc, defines
instead of const values? 
4 Feb
4 Feb
5:11 p.m.
New subject: [linux-audio-dev] newest audio server for Linux (yep, yet
I am interested to hear responses to this. Once
PortAudio v19 is
released, would you all as application authors be willing to adopt it in
your programs? If so, why not? In my opinion, the only group of
PortAudio is the only solution I was looking at for output. It just seems
right.
9:10 p.m.
On Tuesday 04 February 2003 21.47, Josh Haberman wrote:
[...]
Right now the only ways to choose a callback model in
Linux audio
applications are:
* use JACK. Using JACK directly only makes sense for:
1. applications whose only possible use in in a JACK graph
(jackrack) 2. applications whose target audience is only people who
are so into RT audio that they're willing to obtain JACK and tweak
latency settings
* write a custom audio thread for ALSA or OSS. This takes a lot of
work and time to get right. I don't know of any applications
that actually do this.
I've never really thought of any other way to use ALSA or OSS...
Audiality does it, although the current (unreleased) version adds an
"interesting" twist with the new I/O layer... It allows interfacing
with both callback APIs and read()/write() APIs, while still having
only one master engine callback, and block oriented read()/write()
write callbacks for "drivers". Sort of weird. Might have done
something stupid. Or not. Either way, it's better than the old hack!
:-)
Anyway, am I missing the point?
* use PortAudio.
Well, there's one more, that doesn't do input but still: SDL.
My point is that given the status quo, I don't
think we will see a
move to callback-based design. OSS and ALSA are perceived as most
native and most ubiquitous, and these most naturally lend
themselves to the blocking model.
I'm not quite ready to toot my PortAudio horn yet, only because v19
is not yet ready. Here's what I will say now: I think PortAudio
has the potential to be the unifying force in the fragmented Linux
audio world. Imagine being able to write to an API as simple and
well-designed as this:
<http://www.portaudio.com/docs/v19-doxydocs/portaudio_8h.html> Now
imagine that linking against this library will give you access to
OSS, ALSA, JACK, and whatever other APIs come along *all in a
single build*. Imagine getting the same performance as if you had
written to these APIs directly. And imagine having your audio i/o
be portable to Windows and Mac with just a recompile.
That sounds *really* great, of course. It's just what I need for
Audiality, so it's obviously something I'll add in a not too distant
future.
Would be cool if even more platforms were supported, but OTOH, in the
case of Audiality, that's mostly for games that use it as a sound
engine - and SDL works fine for that.
(The only game to use it so far, my XKobo port "Kobo Deluxe", runs on
some 10 platforms. I don't know for sure if it does audio on the
PDA(s?) and 68k Amiga, but AFAIK, it does on Linux, Win32, Mac OS X,
FreeBSD, Solaris/SPARC, Solaris/x86, BeOS and probably some others I
can't remember right now.)
[...]
I foresee resistance from people who perceive
portability APIs as a
compromise, as having poor performance.
One would think people should know better these days... Any
performance issues with OpenGL? ;-)
This is simply not the
case. No one would accuse JACK of having poor performance, though
it works by wrapping other APIs. The truth is that the combination
of a well-designed API and careful implementation can yield wrapper
APIs that perform just as well as programming directly to the
underlying API.
I would say SDL (the graphics stuff) is a perfect demonstration of
this. The API is as simple as it gets, it runs on *loads* of
different platforms, and it's just about as fast as it gets on most
of them. Still improvements to be made (supporting some more h/w
acceleration APIs, for example), but I think my glSDL - a
proof-of-concept implementation of the 2D blitting API on top of
OpenGL - demonstrates that the API fits pretty much anything. (OpenGL
is *very* far from a raw framebuffer...)
A great deal of thought has gone into the PortAudio
API, you can
read a record of the proposals that went into v19 at
<http://www.portaudio.com/docs/proposals/index.html>
I am interested to hear responses to this. Once PortAudio v19 is
released, would you all as application authors be willing to adopt
it in your programs?
I would, definitely, since extreme portability is a major design goal
for most of my projects. Anything that works well on more than one
platform is of interest, basically. (As is anything that works
*really* well on Linux, of course, since that's where I'll be running
my software most of the time. :-)
If so, why not?
Indeed.
In my opinion, the only
group of applications that would not benefit from using PortAudio
are those that are so closely tied to JACK that they don't make
sense outside of a JACK graph.
That's not Audiality - which doesn't even have JACK support yet. :-/
OTOH, I'll need a nice replacement for the ALSA sequencer, if the
thing is to be usable for anything but music and SFX playback on
other platforms. Currently, the most "portable" control API I have is
OSS rawmidi... *heh*
I've considered hacking native Win32 MIDI support (the "new" MIDI API
with timestamps), but... let's just say I don't care enough for
Windows to spend time on that. (I'm in the middle of the final step
away from using Windows for music at all. Just need to hack
Rosegarden a little, and it'll fit the bill, I think...)
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
11:29 p.m.
New subject: [linux-audio-dev] newest audio server for Linux (yep, yet another)
On Tue, 2003-02-04 at 18:03, David Olofson wrote:
Would be cool if even more platforms were supported,
but OTOH, in the
case of Audiality, that's mostly for games that use it as a sound
engine - and SDL works fine for that.
What platforms are not supported that you would like to see? There is a
list of currently supported platforms at
<http://www.portaudio.com/status.html>
OTOH, I'll need a nice replacement for the ALSA
sequencer, if the
thing is to be usable for anything but music and SFX playback on
other platforms. Currently, the most "portable" control API I have is
OSS rawmidi... *heh*
I know practically nothing about MIDI. I would encourage you to
investigate PortMIDI and see if it would suit your needs. I'm curious
to know, since I know basically nothing about it. It appears to have an
ALSA implementation, but I have no idea how complete or usable it is.
<http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/music/web/portmusic/>
.- The Return of Audiality!
--------------------------------.
I always read "Audiality" as "Audacity." The names are too similar.
:-)
Josh
5 Feb
5 Feb
12:04 a.m.
On Wednesday 05 February 2003 05.21, Josh Haberman wrote:
[...]
Yeah - but AFAIK, I was first! ;-) Although this engine is the first
thing I'd actually count. The others were little more than
placeholders for the name. First one was a Win16/Win32 hybrid audio
engine + rudimentary GUI, and the second incarnation was supposed to
become an RTLinux based audio engine, but never got beyond a driver
API for porting Linux drivers to RTL and some stuff related to that.
Both were dropped as a result of superior platforms showing up.
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
--- http://olofson.net --- http://www.reologica.se ---
What platforms are not supported that you would like
to see? There
is a list of currently supported platforms at
<http://www.portaudio.com/status.html>
Well, that covers it, basically.
I bet a few users of PDAs, consoles, various old non-PC machines and
whatnot will complain if Kobo Deluxe can't do sound on their machines
- but as I said, SDL has that covered, and either way, it's not
something I'm willing to spend lots of time on.
Plenty of entries in the "supported platforms" list looks cool,
though. ;-)
[...]
Should work, but it doesn't seem to support the new Win32 API at this
point.
.- The Return
of Audiality! --------------------------------.
I always read "Audiality" as "Audacity." The names are too
similar. :-) 
9:45 a.m.
On Tuesday 04 February 2003 21:03, David Olofson wrote:
OTOH, I'll need a nice replacement for the ALSA
sequencer, if the
thing is to be usable for anything but music and SFX playback on
other platforms. Currently, the most "portable" control API I have is
OSS rawmidi... *heh*
Some support for mixer controls would be nice too (or am I just missing it
scanning the API?).
Cheers!
|-------------------------------------------------------------------------|
| Frederick F. Gleason, Jr. | Salem Radio Labs |
| Voice: 1-(540)-341-2880 | 87 Lee Highway, Suite 11 |
| FAX: 1-(540)-341-7176 | Warrenton, VA 20188 |
|-------------------------------------------------------------------------|
| Liberty is always dangerous, but it is the safest thing we have. |
| -- Harry Emerson Fosdick |
|-------------------------------------------------------------------------|
12:41 p.m.
New subject: [linux-audio-dev] newest audio server for Linux (yep, yet another)
On Wed, 2003-02-05 at 06:39, Fred Gleason wrote:
On Tuesday 04 February 2003 21:03, David Olofson
wrote:
PortAudio does not include mixer control, however to fill this void
Dominic Mazzoni wrote PortMixer which Audacity began using recently. It
doesn't have a web page, but here is the announcement:
http://techweb.rfa.org/pipermail/portaudio/2002-October/001241.html
Josh
OTOH, I'll need a nice replacement for the
ALSA sequencer, if the
thing is to be usable for anything but music and SFX playback on
other platforms. Currently, the most "portable" control API I have is
OSS rawmidi... *heh*
Some support for mixer controls would be nice too (or am I just missing it
scanning the API?). 
4 Feb
4 Feb
11:57 a.m.
On Mon, 3 Feb 2003, Paul Davis wrote:
no sign of that. this is the same old design. sigh. no
sample sync,
the whole thing is still based on the idea of applications deciding
what and when to do their stuff. sigh, sigh, sigh. it looks like a
decent thing for network-based apps, but nothing more than that. clean
API, though.
I'm the lead developer on the MAS project. Thanks for checking it out!
Here's my position: we didn't limit the architecture in any way that'd
restrict it from being used pro-audio applications; however, the necessary
stuff isn't exposed in the API now. It's all in the core, and if it
isn't, it will be. I'm pretty confident we didn't screw this part up.
Also, I hate the stream abstraction for audio. We're going to provide a
callback-style "pull" API to compliment the standard push API, and add
support for shared memory, and support for multiple threads in the server.
We planned for all this. It just, you know... takes a while.
That said, I think JACK is very cool. You guys had a different need -- to
make multi-client pro-audio possible on Linux, and I think you've done it.
We're coming at the audio (and time) problem from a different direction.
Our goal is to serve the users who want audio to follow their remote X
session and who want to make more than one sound at the same time, and to
do it in a way that's higher quality, lower latency, and easier than what
was possible before. And somehow, to do it such that the basic
architecture, without all the "other stuff(TM)", can support high-end and
pro applications.
So, yeah, we have all kinds of plug-ins that do actual work and mess with
the sound, like sample rate conversion and CODECs. But, my feeling is, if
you don't need 'em, don't use 'em. Ultimately, if you know you've got
N
clients all at 96/24, you can ditch the sample rate converter.
Anyway... we're working on documentation and more releases, and the actual
"soundserver" API. And I'm looking forward to seeing how MAS and JACK can
interoperate.
Mike Andrews
Lead Developer -- MAS Project
1:02 p.m.
-----Original Message-----
From: linux-audio-dev-admin(a)music.columbia.edu
[mailto:linux-audio-dev-admin@music.columbia.edu]On Behalf Of Mike
Andrews
Sent: Tuesday, February 04, 2003 8:50 AM
To: linux-audio-dev(a)music.columbia.edu
Subject: Re: [linux-audio-dev] newest audio server for Linux (yep, yet
another)
<SNIP>
I'm the lead developer on the MAS project. Thanks for checking it out!
<SNIP>
We're coming at the audio (and time) problem from
a different direction.
Our goal is to serve the users who want audio to follow their remote X
session and who want to make more than one sound at the same time, and to
do it in a way that's higher quality, lower latency, and easier than what
was possible before. And somehow, to do it such that the basic
architecture, without all the "other stuff(TM)", can support high-end and
pro applications.
<SNIP>
Mike,
Thanks for stopping by.
MAS looks exciting. I have to interface every day with engineers in
India. We need the ability to run applications remotely and share our work.
I look forward to seeing MAS help us out in that area. Currently we seem to
be most limited by Linux browsers not working with software developed to do
this on Windows, but things are getting better, and really integrated sound
and video in X would probably help. I hope to hear that over the next year
MAS will be part of that solution.
Cheers,
Mark
7:09 a.m.
On Mon, Feb 03, 2003 at 06:22:26 -0500, Ivica Bukvic wrote:
Kidding aside, this may prove to be so ubiquitous that
it will quickly
overshadow all other implementations. It's the MAS audio server that is
going to be implemented into the X server itself and will be
network-transparent.
I spoke with some of the people from MAS at the last LinuxTag, and I think
some other people on this list hade spoken to them too.
MAS itsself its not suitable for RT audio*, but I suggested that we might
want some MAS<->JACK interfaces for network transparent audio, and left a
bussiness card, they seemed enthusiastic, but I never heard back from the
MAS guys.
No sync, no latency control, no contrained audio format.
- Steve
7:22 a.m.
On Tue, 4 Feb 2003, Steve Harris wrote:
MAS itsself its not suitable for RT audio*, but I
suggested that we might
want some MAS<->JACK interfaces for network transparent audio, and left a
bussiness card, they seemed enthusiastic, but I never heard back from the
MAS guys.
Yes, I spoke to them too at LinuxWorld and thought that a MAS driver for
Jack would be a pretty neat thing, if one didn't care so much about
network latency.
Taybin
--
http://www.piratesvsninjas.com
7:50 a.m.
On Tue, Feb 04, 2003 at 07:15:07 -0500, Taybin Rutkin wrote:
On Tue, 4 Feb 2003, Steve Harris wrote:
Agreed, for RT operation then 1494 is probably the way to go, but when you
dont care about latency (or quality*) MAS is good too.
* IIRC MAS silently resamples, so I wouldn't use it in my studio. It would
be fine for playing mp3s though.
- Steve
MAS itsself its not suitable for RT audio*, but I
suggested that we might
want some MAS<->JACK interfaces for network transparent audio, and left a
bussiness card, they seemed enthusiastic, but I never heard back from the
MAS guys.
Yes, I spoke to them too at LinuxWorld and thought that a MAS driver for
Jack would be a pretty neat thing, if one didn't care so much about
network latency.
7999
days inactive
8001
days old
linux-audio-dev@lists.linuxaudio.org
21 comments
13 participants
participants (13)
-
Abramo Bagnara -
Bob Ham -
David Gerard Matthews -
David Olofson -
Fred Gleason -
Ivica Bukvic -
Josh Haberman -
Mark Knecht -
Mike Andrews -
Paul Davis -
Steve Harris -
Taybin Rutkin -
Tim Hockin