A quick response on-list, as Ollie and I have had rather a long email
discussion off-list around this.
The simple answer is yes, a PortAudio AudioServer implementation is
definitely on the cards, and something I hope to put together over the
next couple of month. My intention is to create a JNA wrapper ala
JNAJack for this purpose, unless a free, robust and reusable JNI
version becomes available. Between Ollie and I we know of a few
PortAudio wrappers in existence, but none that fulfil those 3 criteria
as yet.
This would be my preferred approach than wrapping the various platform
audio API's individually, which would basically be reimplementing
PortAudio in Java. The only downside (at least on Windows and Mac) of
PortAudio may be the need to ship the PortAudio binary, for which it
would be good to have a canonical source - the project doesn't seem to
provide its own binary builds as far as I can tell.
As for JACK on OSX Lion, hopefully the coming version fixes that -
keep us in the loop!
Best wishes,
Neil
> --
> JAudioLibs - http://code.google.com/p/java-audio-utils/
>
> You received this message because you are subscribed to the Google
> Groups "JAudioLibs" group.
> To post to this group, send email to jaudi...@googlegroups.com
> To unsubscribe from this group, send email to
> jaudiolibs+...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/jaudiolibs?hl=en?hl=en
--
Neil C Smith
Artist : Technologist : Adviser
http://neilcsmith.net
A PortAudioServer could be interesting!
A few comments to the latest postings:
As for Jack osx, Oliver, you can learn to control those crashes. Most users having reported this problem, and I am one of them, observe that the crash only happens if you do not start Jack as the first step, inter alias, always prior to starting any other relevant app, even Audio/Midi setup. If you start Jack first, it has not crashed once on my 10.7.3 Lion for several months, and fore example, it is quicker than “native” OSX audio to catch and adopt to sample rate given by the source (media player). If you set it to 96, it will handle anything from 16bit 44.1 to 24bit 192 on the fly. If you set it to 44.1 it may not handle 192, not on this machine, so in other words, there are a few weird hiccups with workarounds. The crash is a known issue yet without a fix. Just start Jack first and you are saved.
What I miss with Jack (osx), perhaps I am just ignorant, is the ability to start Jack server from my own app, via api. Jack OSX has no option for auto starting the Jack server, it must be done manually from Jack Pilot. As I have a wifi bug (A well known Lion bug) that makes it necessary to literally restart the machine several times a day here in 2012, I am getting bored with this humble startup procedure.
Just today, we did tests with Fidelia music player, which works just fine in two variants:
1. Via Jack, no JavaSound involved.
2. Using SoundFlower as intermediate routing point to our own app, which uses Javasound for input and output. However, there are currently many reports on trouble with SoundFlower at the moment (Lion). This configuration refreshes our interest for the JavaSound AudioServer.
And BTW, what I miss with Jack on Windows is the osx variant of Jack Router that acts as a virtual audio device. So as to capture all audio streams. This is not so on Windows, and therefore Jack osx is much more interesting for our use which is to capture ANY audio stream and route it into our SoundPimp audio enhancer.
Carl
--
Few comments below.
On 27 February 2012 22:59, Carl H Janson <c...@hdsoundlab.com> wrote:
> What I miss with Jack (osx), perhaps I am just ignorant, is the ability to
> start Jack server from my own app, via api.
Using Jack.openClient(...) without JackNoStartServer in the options
EnumSet should automatically start the Jack server (using the last
settings from QJackCtl (or whatever it's called on OSX)).
There is currently no way to control this using the AudioServer API,
though this will come in v1.1. In the meantime, you could create a
client purely for the purposes of controlling the server. If you
don't activate it, it shouldn't show up anywhere.
> 2. Using SoundFlower as intermediate routing point to our own app,
> which uses Javasound for input and output. However, there are currently many
> reports on trouble with SoundFlower at the moment (Lion). This configuration
> refreshes our interest for the JavaSound AudioServer.
>
Why? If SoundFlower doesn't work, doesn't that make the JavaSound
AudioServer *less* useful for you???
>
> And BTW, what I miss with Jack on Windows is the osx variant of Jack Router
> that acts as a virtual audio device. So as to capture all audio streams.
> This is not so on Windows, and therefore Jack osx is much more interesting
> for our use which is to capture ANY audio stream and route it into our
> SoundPimp audio enhancer.
Jack on Windows has JackRouter, just it only works with ASIO capable
software - given Jack's position as a pro-audio solution this isn't
entirely surprising. It is possible to get various media players to
output to ASIO.
Neil
-----Original Message-----
From: jaudi...@googlegroups.com [mailto:jaudi...@googlegroups.com] On
Behalf Of Neil C Smith
Sent: 28. februar 2012 11:00
To: jaudi...@googlegroups.com
Subject: Re: [jaudiolibs] Other audio IOs? Portaudio?
Hi,
Few comments below.
On 27 February 2012 22:59, Carl H Janson <c...@hdsoundlab.com> wrote:
> What I miss with Jack (osx), perhaps I am just ignorant, is the ability to
> start Jack server from my own app, via api.
Using Jack.openClient(...) without JackNoStartServer in the options
EnumSet should automatically start the Jack server (using the last
settings from QJackCtl (or whatever it's called on OSX)).
[Carl Henrik ] I did not understand that, but I suppose I will if I take a
closer look. Any code example available would be good for me :-)
There is currently no way to control this using the AudioServer API,
though this will come in v1.1. In the meantime, you could create a
client purely for the purposes of controlling the server. If you
don't activate it, it shouldn't show up anywhere.
> 2. Using SoundFlower as intermediate routing point to our own app,
> which uses Javasound for input and output. However, there are currently
many
> reports on trouble with SoundFlower at the moment (Lion). This
configuration
> refreshes our interest for the JavaSound AudioServer.
>
Why? If SoundFlower doesn't work, doesn't that make the JavaSound
AudioServer *less* useful for you???
[Carl Henrik ] Because SoundFlower is so widely in use that one could
anticipate that the current problems will pass within the short timeframe (a
month or two). SoundFlower normally works fine on our machines.
>
> And BTW, what I miss with Jack on Windows is the osx variant of Jack
Router
> that acts as a virtual audio device. So as to capture all audio streams.
> This is not so on Windows, and therefore Jack osx is much more interesting
> for our use which is to capture ANY audio stream and route it into our
> SoundPimp audio enhancer.
Jack on Windows has JackRouter, just it only works with ASIO capable
software - given Jack's position as a pro-audio solution this isn't
entirely surprising. It is possible to get various media players to
output to ASIO.
[Carl Henrik ] Yes, JackRouter is available from ASIO-compliant DSPs and
from media players with ASIO output like FooBar, Winamp, etc. We use
SoundPimp in this context and all is well. However, this rules out layman
daily use of non-compliant software like e.g browsers, e.g. radio streaming
or Youtube videos.
Perhaps the "pro-audio" solution is not the whole story here. There is a
special competence needed in order to enter the KS mode of Windows and
produce "virtual audio devices", and I am not sure if this is currently a
core competence in the Jack community? Perhaps not. The whole concept of
Jack has only the last mile to go to open a floodgate of usage on WIN and
OSX platforms. The pro-user type of thinking should be put aside on the IT
museum ASAPractical.
Carl
Neil
--
Neil C Smith
Artist : Technologist : Adviser
http://neilcsmith.net
--
eg. If you forked the JackAudioServer and removed the
JackOptions.JackNoStartServer from the options EnumSet here -
http://code.google.com/p/praxis/source/browse/audio.servers.jack/src/org/jaudiolibs/audioservers/jack/JackAudioServer.java#101
- the server should auto start.
To not need to fork the code, you should be able to call
jack.openClient("UNUSED", null, null); before starting the server to
get the same effect (not tested!)
> Perhaps the "pro-audio" solution is not the whole story here. There is a
> special competence needed in order to enter the KS mode of Windows and
> produce "virtual audio devices", and I am not sure if this is currently a
> core competence in the Jack community? Perhaps not. The whole concept of
> Jack has only the last mile to go to open a floodgate of usage on WIN and
> OSX platforms. The pro-user type of thinking should be put aside on the IT
> museum ASAPractical.
>
Disagree! Read this article -
http://0pointer.de/blog/projects/when-pa-and-when-not.html Basically
what you're wanting JACK to do is become PulseAudio. Pro and consumer
audio have different requirements. There are some Windows builds of
PulseAudio around btw, and there is a JavaSound implementation in
OpenJDK - whether that could all be brought together I have no idea.
N
Interesting and well written article. Of course there are differences
between the needs of pro user and layman, but arguments based on "what does
it cost" and "what is there already" is not that relevant when discussing
what is possible to achieve in computer audio anno 2012.
We did a test this weekend as we have Jack running on windows now. We used
foobar2000 and Reaper as media source, both providing ASIO output in
compliance with JackRouter ASIO input. For perfect playback, Jack could be
set to 256 frames/period which is a fair layman latency value. But the
system could not handle 128 or 64. Stuttering sound. The same stuttering was
also observed when starting another application (Spotify), i.e. the startup
process destroyed Jack performance.
On the other hand, our SoundPimp Java app has played perfect with 64samples
latency for several years (e.g. with Asio4all driver or Motu ASIO drivers).
This is based on a callback solution very similar to what is available with
JackAudioServer. Since Jack is also an ASIO driver we discovered it works
very well with this callback module as long as we did not press for low
latency. (We will test JackAudioServer soon also). Using Asio4all, there is
no stuttering when Spotify is started (similar to example above).
So Jack-ASIO is clearly outperformed by the "pure" ASIO setup. Why ? To my
understanding, the (main) reason is that ASIO is using Win KS mode, while
Jack is at application level, thus more vulnerable to cpu competition from
other running applications. So this is perhaps interesting in the context of
PRO and Layman system differences.
Further, using 3 different "audio capture virtual devices" products, we may
also capture any audio stream into this low latency setup using ASIO. 24bit
192 kHz, very low latency. So one could assume that this is a feature that
could be interesting to many Jack users, but as I said last time, Jack does
not offer this.
Carl
-----Original Message-----
From: jaudi...@googlegroups.com [mailto:jaudi...@googlegroups.com] On
Behalf Of Neil C Smith
Sent: 28. februar 2012 13:24
To: jaudi...@googlegroups.com
Subject: Re: [jaudiolibs] Other audio IOs? Portaudio?
N
--
Seen as I can't find the phrases you're quoting in the article it's
hard to comment! :-)
The rest of your email would be better addressed at the JACK list, or
the JACK on Windows developers. In general though, the design of JACK
is such that it's meant to add nothing to latency, and I can get
similar performance with and without it.
Neil
These were not intended as direct quotes to that article, so feel free to
comment in a more general manner.
Yes, the Jack list. Absolutely, but this line of questioning tend to get
unclear answers when there is none :-)