18 Mar
2005
18 Mar
'05
11:24 a.m.
I'm writing an application that will use alsa in the common case, but be
jack-capable. I'm faced with the following design question: Do I wrap
the jack part to emulate the read/write of alsa, or do I wrap the alsa
part to emulate the callback style of jack? In other words, do I push or
pull from the audio segment of the program?
As I understand it, alsa can be asynchronous but it requires using SIGIO
which doesn't excite me. So I'd have to create another thread that
selects and fills a ringbuffer.
To adapt jack, I'd have a ringbuffer which is drained when the program
pulls the audio.
Adapting Jack seems the easier thing to do, but what do you think?
--
.O. Hans Fugal | De gustibus non disputandum est.
..O http://hans.fugal.net | Debian, vim, mutt, ruby, text, gpg
OOO | WindowMaker, gaim, UTF-8, RISC, JS Bach
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460
18 Mar
18 Mar
11:47 a.m.
I'm writing an application that will use alsa in
the common case, but be
jack-capable. I'm faced with the following design question: Do I wrap
the jack part to emulate the read/write of alsa, or do I wrap the alsa
part to emulate the callback style of jack? In other words, do I push or
pull from the audio segment of the program?
As I understand it, alsa can be asynchronous but it requires using SIGIO
which doesn't excite me. So I'd have to create another thread that
selects and fills a ringbuffer.
To adapt jack, I'd have a ringbuffer which is drained when the program
pulls the audio.
Adapting Jack seems the easier thing to do, but what do you think?
if your app is supposed to be a realtime audio app, then a callback
driven model is almost demonstrably more correct. SIGIO is not
appropriate for this. you would be better taking the same design that
JACK itself uses to interact with ALSA, and wrapping that as your ALSA
interface. Its also far from clear of the worth of a native ALSA
interface for most programs, though perhaps yours is an exception. If
there is any reason why the user might want to feed the output of
another program into yours (or vice versa), why confuse them with two
different I/O model options?
also, there is already a library that can convert a blocking
read/write app into a JACK client. xmms-jack uses it, i regret that i
forget its name. there is a link on the JACK site on the apps
page. Might be bio2jack. it adds latency to the app that uses it, but
it does work. There is another solution along the same lines, but less
invasive. I forget its name.
--p
12:07 p.m.
Am Freitag, 18. März 2005 16:47 schrieb Paul Davis:
also, there is already a library that can convert a
blocking read/write app into a JACK client. xmms-jack uses
it, i regret that i forget its name. there is a link on the
JACK site on the apps page. Might be bio2jack. it adds
latency to the app that uses it, but it does work. There is
another solution along the same lines, but less invasive. I
forget its name.
http://bio2jack.sf.net
Best regards
ce
12:23 p.m.
On Fri, 18 Mar 2005 at 10:47 -0500, Paul Davis wrote:
if your app is supposed to be a realtime audio app,
then a callback
driven model is almost demonstrably more correct. SIGIO is not
appropriate for this.
For context, the app is a softphone. All linux softphones stink in all
ways, plus none was readily adaptable to JACK. I, being an audio geek,
would like to hook up a call to a JACK graph. But most people would like
the thing to just work without hassle, hence the ALSA option (which
would probably be default). Is this realtime? Sort of. In any case,
hopefully more realtime than the existing softphones. But there's
network jitter which begs a jitterbuffer, and telephone conversations
aren't as sensitive to latency as many things we do here. But the
realtime programmer in me can't get excited about SIGIO.
--
.O. Hans Fugal | De gustibus non disputandum est.
..O http://hans.fugal.net | Debian, vim, mutt, ruby, text, gpg
OOO | WindowMaker, gaim, UTF-8, RISC, JS Bach
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460
19 Mar
19 Mar
1:01 p.m.
For context, the app is a softphone.
Kewl.
All linux softphones
stink in all ways, plus none was readily adaptable to JACK.
I, being an audio geek, would like to hook up a call to a
JACK graph. But most people would like the thing to just
work without hassle, hence the ALSA option (which would
probably be default).
If your softphone should be straightforward to the user, it
needed to support different soundsystems, and to try to
automatically select one during start time. Here one idea in
which order this could happen:
* JACK
* Arts
* esound
* ALSA/DMIX
* OSS
If you're an audio geek, you'll most probably make the app
pulled (native JACK) and then wraping it for the other
soundsystems.
Best regards
ce
2:14 p.m.
On Saturday 19 March 2005 17:59, Christoph Eckert wrote:
If your softphone should be straightforward to the
user, it
needed to support different soundsystems, and to try to
automatically select one during start time. Here one idea in
which order this could happen:
* JACK
* Arts
Cut that. aRts isn't maintained anymore. KDE is heading for another solution
and currently (kde3.4) half of the players in kde have their own plugin
system to support different soundservers / outputmethods to be independent
from aRts...
It won't live longer than kde 3.5, which will hopefully be the last kde3.x.
* esound
* ALSA/DMIX
* OSS
Arnold
--
There is a theory which states that if ever anyone discovers exactly what the
Universe is for and why it is here, it will instantly disappear and be
replaced by something even more bizarre and inexplicable.
There is another theory which states that this has already happened.
-- Douglas Adams, The Restaurant at the End of the Universe
3:10 p.m.
Cut that. aRts isn't maintained anymore. KDE is
heading for
another solution and currently (kde3.4) half of the players
in kde have their own plugin system to support different
soundservers / outputmethods to be independent from aRts...
It won't live longer than kde 3.5, which will hopefully be
the last kde3.x.
that's true, I forgot that. Thanks a lot for the pointer.
Best regards
ce
6:34 p.m.
On Fri, 2005-03-18 at 17:53 +0100, Tim Orford wrote:
[snip]
--
(
)
c[] // Jens M Andreasen
but presumably it doesnt support jack-transport..?
I am possibly ignorant, but here goes ..
Do jack-transport support SMPTE
Do jack-transport support MIDI song pointer
(guessing yes to above)
Then ... What is it that jack-transport do, that is so fantastic? That
we do not already have as part of MIDI?
19 Mar
19 Mar
9:29 a.m.
New subject: [linux-audio-dev] jack transport
On Fri, Mar 18, 2005 at 11:34:34PM +0100, Jens M Andreasen wrote:
Do jack-transport support SMPTE
Do jack-transport support MIDI song pointer
(guessing yes to above)
actually i beleive the answer is mostly no, although perhaps
its best to consider smpte and midi as paralle rather than
being supported by jack-transport.
http://jackit.sourceforge.net/docs/reference/html/transport-design.html
the job of jack-transport is to sync clients in position (eg
1min, 25.026secs). (Actually strictly speaking there is postional
information in jack without it, but jack-transport extends this,
and provides the commands neccesary to make use of it.) Without
this you only have speed sync (clients are sample synchronous and
can be mixed together without resampling). For example, to bounce
an audio track from Rosegarden to Ardour, you need to be able to
tell both clients to locate to *exactly* the same position and
play from there.
smpte is analogue so is not useful on a computer except for
compatibility with other systems. For a jack plugin or client
to generate a smpte signal to act as a master is relatively easy,
but extracting the clock from a sampled analogue smpte signal to
facilitate slaving is a non-trivial dsp task. I do beleive
Fons Adriaensen was working on this. Theoretically, smpte lock
between 2 stable systems could be quite tight, but not only is
it not as tight as Jack, it is way too complicated and cpu intensive.
at least Midi Spp is digital, but as its an asynchronous
message, it suffers from jitter, and cant acheive a tight lock.
Control commands such as MidiContinue make more sense, but not all
jack clients will want to support midi. Its mostly useful
for supporting external or uncooperative systems.
so while many people will claim they dont need sample accurate
positioning, jack-transport appears to be both the best and easiest
solution to control of intra-box Libre applications. And hopefully
will remain so when Jack gets extended to the LAN.
Then ... What is it that jack-transport do, that is so
fantastic? That
we do not already have as part of MIDI?
the reason i asked about jack-transport in relation to bio2jack
is that there are several unasked question on the mplayer lists
re how to get this working. People dont realise that bio2jack
only provides "jack 1.0 simple" or whatever you want to call it.
Syncing video playback to Ardour would be a great example of the
usefullness of jack-transport. Unfortunately, i guess the fact
is that the design of mplayer means it can never be a real jack
client. Perhaps a jack client could control mplayer via its slave
mode, for use with non-keyframe based video formats, but thats a
bit of a hack.
hope that helped:-)
--
Tim Orford
12:29 p.m.
New subject: [linux-audio-dev] jack transport
On Fri, Mar 18, 2005 at 11:34:34PM +0100, Jens M
Andreasen wrote:
correct. SMPTE provides positional sync with a resolution of 1 SMPTE
frame (on the order of 1/30th second) - in other words, appalling for
audio synchronization.
MIDI SPP provides positional sync with a resolution based on a tempo
map. Nice for musical sync, terrible for audio.
Do jack-transport support SMPTE
Do jack-transport support MIDI song pointer
(guessing yes to above)
actually i beleive the answer is mostly no, although perhaps
its best to consider smpte and midi as paralle rather than
being supported by jack-transport. Fons Adriaensen was working on this. Theoretically,
smpte lock
between 2 stable systems could be quite tight, but not only is
it not as tight as Jack, it is way too complicated and cpu intensive.
not entirely true. using a DLL for this is not very expensive and can
be rather accurate. but you are right that it still cannot provide
sample level sync.
the reason i asked about jack-transport in relation to
bio2jack
is that there are several unasked question on the mplayer lists
re how to get this working. People dont realise that bio2jack
only provides "jack 1.0 simple" or whatever you want to call it.
but thats for a very obvious reason: there is nothing in any of the
blocking i/o models that bio2jack is there to assist with that
corresponds to the notion of a transport model. what OSS or ALSA calls
would an application be making to do something like this? answer:
none. therefore, bio2jack doesn't so much provide "jack 1.0 simple" as
"blocking i/o via JACK". if you want transport stuff, you need an API
that has no analog in OSS or ALSA. AFAIK, for Linux at least, JACK is
the only API that provides such a concept.
--p
1:18 p.m.
New subject: [linux-audio-dev] jack transport
On Sat, Mar 19, 2005 at 11:29:57AM -0500, Paul Davis wrote:
i thought as much but its nice to have confirmation from the horses
mouth - thanks! But my point is that users in general dont know this. I
dont think its important exactly how one expresses it, but it should be
made clear, especially for example on the bio2jack site, that bio2jack
doesnt and will never provide full Jack support, contrary to what you
seemed to imply earlier in this thread. Perhaps not entirely appropriate
here, but I used an analogy to Mpeg Profiles, as they provide a well
defined and understood shortcut language of what parts of the standard
are implemented, thereby reducing misunderstandings.
fijn weekend to all
--
Tim Orford
correct. SMPTE provides positional sync with a
resolution of 1 SMPTE
frame (on the order of 1/30th second) - in other words, appalling for
audio synchronization.
each frame is divided into 80 'bits', referred to as subframes.
in addition, the rise time of the signal is defined in the standard
as 25 µs ± 5 µs (ascii: 25us +/-5us), so with an undegraded signal,
the accuracy can be much higher than the bit rate.
this doesnt change the fact that its of very limited usefullness
to us though.
People dont
realise that bio2jack
only provides "jack 1.0 simple" or whatever you want to call it.
but thats for a very obvious reason: there is nothing in any of the
blocking i/o models that bio2jack is there to assist with that
corresponds to the notion of a transport model. what OSS or ALSA calls
would an application be making to do something like this? answer:
none. therefore, bio2jack doesn't so much provide "jack 1.0 simple" as
"blocking i/o via JACK". if you want transport stuff, you need an API
that has no analog in OSS or ALSA. AFAIK, for Linux at least, JACK is
the only API that provides such a concept. 
8 Apr
8 Apr
12:53 p.m.
On Fri, Mar 18, 2005 at 10:47:55AM -0500, Paul Davis wrote:
Agreed 100%.
Write your app as a JACK client
I'm writing
an application that will use alsa in the common case, but be
jack-capable. I'm faced with the following design question: Do I wrap
the jack part to emulate the read/write of alsa, or do I wrap the alsa
part to emulate the callback style of jack? In other words, do I push or
pull from the audio segment of the program?
...
if your app is supposed to be a realtime audio app, then a callback
driven model is almost demonstrably more correct. 
18 Mar
18 Mar
12:14 p.m.
On Fri, 2005-18-03 at 08:24 -0700, Hans Fugal wrote:
I'm writing an application that will use alsa in
the common case, but be
jack-capable. I'm faced with the following design question: Do I wrap
the jack part to emulate the read/write of alsa, or do I wrap the alsa
part to emulate the callback style of jack? In other words, do I push or
pull from the audio segment of the program?
As I understand it, alsa can be asynchronous but it requires using SIGIO
which doesn't excite me. So I'd have to create another thread that
selects and fills a ringbuffer.
To adapt jack, I'd have a ringbuffer which is drained when the program
pulls the audio.
Adapting Jack seems the easier thing to do, but what do you think?
Definitely write everything as a "pulling" callback-based system, and
wrap that for alsa. A callback is simple to wrap in a blocking system,
but the other way around just doesn't work (certainly not with jack's RT
requirements anyway)
-DR-
1:38 p.m.
On Fri, Mar 18, 2005 at 08:24:01AM -0700, Hans Fugal wrote:
I'm writing an application that will use alsa in
the common case, but be
jack-capable. I'm faced with the following design question: Do I wrap
the jack part to emulate the read/write of alsa, or do I wrap the alsa
part to emulate the callback style of jack? In other words, do I push or
pull from the audio segment of the program?
maybe write the whole thing callback-based and use portaudio?
--
Paul Winkler
http://www.slinkp.com
6:53 p.m.
On Fri, 2005-03-18 at 08:24 -0700, Hans Fugal wrote:
As I understand it, alsa can be asynchronous but it requires using SIGIO
which doesn't excite me. So I'd have to create another thread that
selects and fills a ringbuffer.
Ehrm ... How will putting SIGIO in another thread improve your
performance? The job still have to get done, no?
--
(
)
c[] // Jens M Andreasen
19 Mar
19 Mar
11:37 a.m.
On Fri, 18 Mar 2005 at 23:53 +0100, Jens M Andreasen wrote:
On Fri, 2005-03-18 at 08:24 -0700, Hans Fugal wrote:
Sorry, the other thread idea is in order to avoid SIGIO. The thread
would select on the audio device and drain it into a ringbuffer for the
other thread to use.
--
.O. Hans Fugal | De gustibus non disputandum est.
..O http://hans.fugal.net | Debian, vim, mutt, ruby, text, gpg
OOO | WindowMaker, gaim, UTF-8, RISC, JS Bach
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460
As I understand it, alsa can be asynchronous but it requires using SIGIO
which doesn't excite me. So I'd have to create another thread that
selects and fills a ringbuffer.
Ehrm ... How will putting SIGIO in another thread improve your
performance? The job still have to get done, no?
20 Mar
20 Mar
11:57 a.m.
On Sat, 19 Mar 2005 at 11:35 -0500, Paul Davis wrote:
I want to do as little as possible. :-)
Part of the problem is that the non-audio thread goes to the network
which means blocking, which means I can't just do it all within
jack_process().
Thanks to all your comments and questions I think my head has cleared. I
will use a ringbuffer between jack_process() and the network thread, and
emulate that when using ALSA. Someday, when jack starts itself as
needed (as I understand is planned), I wouldn't need to support ALSA.
--
.O. Hans Fugal | De gustibus non disputandum est.
..O http://hans.fugal.net | Debian, vim, mutt, ruby, text, gpg
OOO | WindowMaker, gaim, UTF-8, RISC, JS Bach
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460
Sorry, the
other thread idea is in order to avoid SIGIO. The thread
would select on the audio device and drain it into a ringbuffer for the
other thread to use.
s/select/poll/ => welcome to JACK :))
you really want to do all this work over again?
11:28 p.m.
On Sun, 20 Mar 2005 at 12:00 -0500, Paul Davis wrote:
Do you mean jack_client_new()? Even without JACK_START_SERVER[1]
defined? 0.99.0?
1. http://jackit.sourceforge.net/docs/reference/html/jack_8h.html#a1
--
.O. Hans Fugal | De gustibus non disputandum est.
..O http://hans.fugal.net | Debian, vim, mutt, ruby, text, gpg
OOO | WindowMaker, gaim, UTF-8, RISC, JS Bach
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460
emulate that
when using ALSA. Someday, when jack starts itself as
needed (as I understand is planned), I wouldn't need to support ALSA.
current versions of JACK already do this if the client uses
jack_client_open().
11:46 p.m.
emulate that when using ALSA. Someday, when jack starts
itself as
needed (as I understand is planned), I wouldn't need to support ALSA.
=20
current versions of JACK already do this if the client uses
jack_client_open().=20 
21 Mar
21 Mar
12:33 a.m.
Paul Davis <paul(a)linuxaudiosystems.com> writes:
>> >emulate that when using ALSA. Someday,
when jack starts itself as
>> >needed (as I understand is planned), I wouldn't need to support ALSA.
>>=20
>> current versions of JACK already do this if the client uses
>> jack_client_open().=20
>
>Do you mean jack_client_new()? Even without JACK_START_SERVER[1]
>defined? 0.99.0?
That works, too. Define JACK_START_SERVER in your application before
you call jack_client_new().
The new interface is better, though. You might as well use it for any
new code you're writing. We continue to support jack_client_new(), as
well.
no, jack_client_open(). its a new API call, designed
to deal with the
inadequacies of jack_client_new() without breaking every existing client.
this covers the current release, not the version in CVS. the version
in CVS is actually better in every way that the current release - we
are anxious to wrap up the remaining details so that a new release can
be made.
Here's a description of the new interface...
http://www.joq.us/jack/reference-devel/html/jack_8h.html#a1
It's been stable and working in CVS for several months now. It will
be included in a new JACK release, Real Soon Now. Go ahead and give
it a try.
--
joq
11:31 a.m.
On Sun, 20 Mar 2005 at 22:47 -0500, Paul Davis wrote:
no, jack_client_open(). its a new API call, designed
to deal with the
inadequacies of jack_client_new() without breaking every existing client.
this covers the current release, not the version in CVS. the version
in CVS is actually better in every way that the current release - we
are anxious to wrap up the remaining details so that a new release can
be made.
Ok, that explains my confusion. I look forward to the release!
--
.O. Hans Fugal | De gustibus non disputandum est.
..O http://hans.fugal.net | Debian, vim, mutt, ruby, text, gpg
OOO | WindowMaker, gaim, UTF-8, RISC, JS Bach
---------------------------------------------------------------------
GnuPG Fingerprint: 6940 87C5 6610 567F 1E95 CB5E FC98 E8CD E0AA D460
6959
days inactive
6980
days old
linux-audio-dev@lists.linuxaudio.org
23 comments
10 participants
participants (10)
-
Alfons Adriaensen -
Arnold Krille -
Christoph Eckert -
Dave Robillard -
Hans Fugal -
Jack O'Quin -
Jens M Andreasen -
Paul Davis -
Paul Winkler -
Tim Orford