12 Jan
2010
12 Jan
'10
2:15 p.m.
Hi,
We are considering using PortAudio for Linux hardware support (and
Windows/Mac as well). What's the word on the quality, reliability,
ease-of-programming, latency and performance in Linux?
Our product (Receptor) is used in live situations by non-programmers, so
the support can't be "tweaky" if you know what I mean. The product only
needs to support a couple of sound cards, though, so it won't have to
target lots of hardware.
Thanks for any feedback,
Michael Ost
Muse Research, Inc.
12 Jan
12 Jan
2:24 p.m.
On Tue, Jan 12, 2010 at 1:15 PM, Michael Ost <most(a)museresearch.com> wrote:
Hi,
We are considering using PortAudio for Linux hardware support (and
Windows/Mac as well). What's the word on the quality, reliability,
ease-of-programming, latency and performance in Linux?
it works. its development seems to be an issue. it will not fix any of
the issues that you'd otherwise have to tackle on linux.
however, i'm puzzled: you guys are already running on linux - what are
you using now, and why the switch? cross-platform?
2:29 p.m.
Paul Davis wrote:
On Tue, Jan 12, 2010 at 1:15 PM, Michael Ost
<most(a)museresearch.com> wrote:
Can you say more about that last sentence? I'm not quite getting it.
Hi,
We are considering using PortAudio for Linux hardware support (and
Windows/Mac as well). What's the word on the quality, reliability,
ease-of-programming, latency and performance in Linux?
it works. its development seems to be an issue. it will not fix any of
the issues that you'd otherwise have to tackle on linux. however, i'm puzzled: you guys are already running
on linux - what are
you using now, and why the switch? cross-platform?
Yes, cross platform. I'm investigating Windows/MacOS support. We've got
our own portability layer, but it's only really implemented for Linux.
BTW - I looked at JACK, but a quick google scan suggests that its not
quite ready for prime time in Windows.
Thanks!
- mo
2:38 p.m.
On Tue, Jan 12, 2010 at 1:29 PM, Michael Ost <most(a)museresearch.com> wrote:
I don't think that is true, but its not clear that you want your
product based on a server/client model anyway. The windows
installation seems to work quite well, but it requires an
ASIO-supported interface. I think JACK for Windows works more or less
as well as JACK on linux or OS X, but its likely to create a lot of
extra friction in terms of user experience for your particular use
case. OTOH, stephane does have a trick in jack2 whereby you can make
the app *become* the server, and then run the app, so to speak, as an
internal client, so that there is no IPC overhead at all. i don't know
if this works in windows.
Paul Davis wrote:
portaudio doesn't replace ALSA, it sits on top of it. so any issues
that you might have with ALSA on linux will still exist to some degree
even if you use portaudio.
On Tue, Jan 12, 2010 at 1:15 PM, Michael Ost <most(a)museresearch.com>
wrote:
Can you say more about that last sentence? I'm not quite getting it.
Hi,
We are considering using PortAudio for Linux hardware support (and
Windows/Mac as well). What's the word on the quality, reliability,
ease-of-programming, latency and performance in Linux?
it works. its development seems to be an issue. it will not fix any of
the issues that you'd otherwise have to tackle on linux. however,
i'm puzzled: you guys are already running on linux - what are
you using now, and why the switch? cross-platform?
Yes, cross platform. I'm investigating Windows/MacOS support. We've got our
own portability layer, but it's only really implemented for Linux.
BTW - I looked at JACK, but a quick google scan suggests that its not quite
ready for prime time in Windows. 
3:20 p.m.
Le 12 janv. 2010 à 19:38, Paul Davis a écrit :
On Tue, Jan 12, 2010 at 1:29 PM, Michael Ost
<most(a)museresearch.com> wrote:
I don't think that is true, but its not clear that you want your
product based on a server/client model anyway. The windows
installation seems to work quite well, but it requires an
ASIO-supported interface.
I does not *require* an ASIO interface. JACK2 on Windows use PortAudio (yes !!) for its
audio backend, and since PortAudio sits on top of either WinMME, DirectSound or ASIO, then
JACK2 can access either WinMME, DirectSound or ASIO cards.
Then the JACK on Windows package contains an ASIO/JACK bridge called JackRouter, that is
an ASIO driver on one side and a JACK client on the other side. Then any ASIO capable
application can access the JACK server.
Paul Davis wrote:
portaudio doesn't replace ALSA, it sits on top of it. so any issues
that you might have with ALSA on linux will still exist to some degree
even if you use portaudio.
On Tue, Jan 12, 2010 at 1:15 PM, Michael Ost <most(a)museresearch.com>
wrote:
Can you say more about that last sentence? I'm not quite getting it.
Hi,
We are considering using PortAudio for Linux hardware support (and
Windows/Mac as well). What's the word on the quality, reliability,
ease-of-programming, latency and performance in Linux?
it works. its development seems to be an issue. it will not fix any of
the issues that you'd otherwise have to tackle on linux. however,
i'm puzzled: you guys are already running on linux - what are
you using now, and why the switch? cross-platform?
Yes, cross platform. I'm investigating Windows/MacOS support. We've got our
own portability layer, but it's only really implemented for Linux.
BTW - I looked at JACK, but a quick google scan suggests that its not quite
ready for prime time in Windows. I think JACK for Windows works more or less
as well as JACK on linux or OS X, but its likely to create a lot of
extra friction in terms of user experience for your particular use
case. OTOH, stephane does have a trick in jack2 whereby you can make
the app *become* the server, and then run the app, so to speak, as an
internal client, so that there is no IPC overhead at all. i don't know
if this works in windows.
Never actually tried, but not reason it would not work.
Stéphane
3:45 p.m.
On Tue, Jan 12, 2010 at 2:20 PM, Stéphane Letz <letz(a)grame.fr> wrote:
Sorry for the misinformation Stephane. What I had meant of course was
that JACK on Windows *provides* an ASIO interface to other non-JACK
applications.
Le 12 janv. 2010 à 19:38, Paul Davis a écrit :
I don't
think that is true, but its not clear that you want your
product based on a server/client model anyway. The windows
installation seems to work quite well, but it requires an
ASIO-supported interface.
I does not *require* an ASIO interface. JACK2 on Windows use PortAudio (yes !!) for its
audio backend, and since PortAudio sits on top of either WinMME, DirectSound or ASIO, then
JACK2 can access either WinMME, DirectSound or ASIO cards.
3:21 p.m.
Paul Davis wrote:
I don't think that is true, but its not clear that you want your
product based on a server/client model anyway. The windows
installation seems to work quite well, but it requires an
ASIO-supported interface. I think JACK for Windows works more or less
as well as JACK on linux or OS X, but its likely to create a lot of
extra friction in terms of user experience for your particular use
case. OTOH, stephane does have a trick in jack2 whereby you can make
the app *become* the server, and then run the app, so to speak, as an
internal client, so that there is no IPC overhead at all. i don't know
if this works in windows.
Thanks for the update. That's a nice summary of where the windows
version is.
-mo
On Tue, Jan 12, 2010 at 1:29 PM, Michael Ost
<most(a)museresearch.com> wrote:
Oh I see. Maybe you're referring to earlier problems with ALSA that we
were having that were posted to this list. IIRC that turned out to be a
subtle problem with thread priority.
Paul Davis wrote:
portaudio doesn't replace ALSA, it sits on top of it. so any issues
that you might have with ALSA on linux will still exist to some degree
even if you use portaudio. On Tue, Jan 12, 2010 at 1:15 PM, Michael Ost
<most(a)museresearch.com>
wrote:
Can you say more
about that last sentence? I'm not quite getting it. Hi,
We are considering using PortAudio for Linux hardware support (and
Windows/Mac as well). What's the word on the quality, reliability,
ease-of-programming, latency and performance in Linux?
it works. its development
seems to be an issue. it will not fix any of
the issues that you'd otherwise have to tackle on linux. however, i'm puzzled: you guys are already running
on linux - what are
you using now, and why the switch? cross-platform?
Yes, cross platform. I'm
investigating Windows/MacOS support. We've got our
own portability layer, but it's only really implemented for Linux.
BTW - I looked at JACK, but a quick google scan suggests that its not quite
ready for prime time in Windows.
3:33 p.m.
case. OTOH, stephane does have a trick in jack2
whereby you can make
the app *become* the server, and then run the app, so to speak, as an
internal client, so that there is no IPC overhead at all. i don't know
if this works in windows.
Well the "trick" in question is that the code using the JACK API can be linked
with "libjackserver.lib" instead of the normal "libjack.lib". Then the
"jack_client_open" call will create an server internal client, instead of a
separated process JACK based client.
This mecanism uses the "jackdrc" file on Linux or OSX to know what server
parameters have to be used. I'm not sure this currently works on WIndows... Otherwise
another way is to use the control API to completely control the server.
Stéphane
2:55 p.m.
On Tue, Jan 12, 2010 at 10:15:33AM -0800, Michael Ost wrote:
We are considering using PortAudio for Linux hardware
support (and
Windows/Mac as well). What's the word on the quality, reliability,
ease-of-programming, latency and performance in Linux?
Our product (Receptor) is used in live situations by non-programmers, so
the support can't be "tweaky" if you know what I mean. The product only
needs to support a couple of sound cards, though, so it won't have to
target lots of hardware.
If it makes any sense at all to connect your product not
just to a soundcard but to other audio applications as well
(and I really don't know of any for which this is not the
case) then on Linux it should support Jack.
PortAudio IIRC has some support for Jack, but it's not
what it could and should be - it considers Jack to be
'a soundcard' which it isn't.
Making Jack apps 'easy to use for the non-technical' is
not difficult at all, basically you should allow the user
to connect to whatever he/she wants, either using a GUI
inside your app or using external tools, remember those
connections as part of a 'preset' or 'config' or whatever
applies to your app, and re-make the connections when
that preset or config is reloaded.
Ciao,
--
FA
4:11 p.m.
On 01/12/2010 07:15 PM, Michael Ost wrote:
We are considering using PortAudio for Linux hardware
support (and
Windows/Mac as well). What's the word on the quality, reliability,
ease-of-programming, latency and performance in Linux?
PortAudio on Linux is very reliable in my experience. It's rather easy to
program with, although I personally dislike its massive-camel-case syntax.
Latency is quite ok. PortAudio actually gives you hints on low and high
latencies for a particular device. For instance, on a HDA Intel consumer
soundcard, it ranges from 10ms to 45ms. I'm using the high one in my app,
although I can't remember exactly why ATM.
But as others are saying in this thread, nowadays a Linux app really needs JACK
support, and you shouldn't rely on Portaudio for this purpose, because it
doesn't play well with the JACK ports paradigm.
Another reason you might want to add JACK support (perhaps in addition to
PortAudio) is that unless I missed something it is still required by FFADO for
firewire devices support.
Our product (Receptor) is used in live situations by
non-programmers, so
the support can't be "tweaky" if you know what I mean. The product only
needs to support a couple of sound cards, though, so it won't have to
target lots of hardware.
I've now maintained a JACK app, namely Jackbeat, for several years, and although
it doesn't have a massive user base, I can tell you that JACK can indeed be
tricky for some linux/audio newbies.
This is why I've added extra options: PortAudio and PulseAudio. This way, the
user can get the app up and running in seconds. But if he/she wants more (lower
latency, connecting with other JACK apps, etc..), then he can switch to JACK,
which is easily performed in many cases.
I think this is the way it happens in many circumstances, not only on Linux: an
easy default is provided, and one can optimize his/her setup with a few efforts.
--
Olivier
4:14 p.m.
Olivier Guilyardi wrote:
On 01/12/2010 07:15 PM, Michael Ost wrote:
<snip>
Thanks for insights... mo
We are considering using PortAudio for Linux
hardware support (and
Windows/Mac as well). What's the word on the quality, reliability,
ease-of-programming, latency and performance in Linux?
PortAudio on Linux is very reliable in my experience. It's rather easy to
13 Jan
13 Jan
7:58 p.m.
The only issue I currently have with PortAudio is that it does not
work very well with pulseaudio. It seems to have problems using the
alsa-plugin mechanism. I have mentioned this on the portaudio list,
but none of the developers responded, only a couple of other users
said they had similar problems.
To use portaudio on Linux, I always have to kill pulseaudio.
Otherwise, it's fine.
Victor
On 12 Jan 2010, at 20:11, Olivier Guilyardi wrote:
On 01/12/2010 07:15 PM, Michael Ost wrote:
We are considering using PortAudio for Linux
hardware support (and
Windows/Mac as well). What's the word on the quality, reliability,
ease-of-programming, latency and performance in Linux?
PortAudio on Linux is very reliable in my experience. It's rather
easy to
program with, although I personally dislike its massive-camel-case
syntax.
Latency is quite ok. PortAudio actually gives you hints on low and
high
latencies for a particular device. For instance, on a HDA Intel
consumer
soundcard, it ranges from 10ms to 45ms. I'm using the high one in my
app,
although I can't remember exactly why ATM.
But as others are saying in this thread, nowadays a Linux app really
needs JACK
support, and you shouldn't rely on Portaudio for this purpose,
because it
doesn't play well with the JACK ports paradigm.
Another reason you might want to add JACK support (perhaps in
addition to
PortAudio) is that unless I missed something it is still required by
FFADO for
firewire devices support.
Our product (Receptor) is used in live situations
by non-
programmers, so
the support can't be "tweaky" if you know what I mean. The product
only
needs to support a couple of sound cards, though, so it won't have to
target lots of hardware.
I've now maintained a JACK app, namely Jackbeat, for several years,
and although
it doesn't have a massive user base, I can tell you that JACK can
indeed be
tricky for some linux/audio newbies.
This is why I've added extra options: PortAudio and PulseAudio. This
way, the
user can get the app up and running in seconds. But if he/she wants
more (lower
latency, connecting with other JACK apps, etc..), then he can switch
to JACK,
which is easily performed in many cases.
I think this is the way it happens in many circumstances, not only
on Linux: an
easy default is provided, and one can optimize his/her setup with a
few efforts.
--
Olivier
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
5489
days inactive
5490
days old
linux-audio-dev@lists.linuxaudio.org
11 comments
6 participants
participants (6)
-
fons＠kokkinizita.net -
Michael Ost -
Olivier Guilyardi -
Paul Davis -
Stéphane Letz -
Victor Lazzarini