Hi,
(1) I've written a command line MIDI sequencer for lightweight systems and
am successful in making it work using the ALSA queue API. However, one
drawback of the API is its lack of callback functions. I wish to be able
to track events as they are drained by the queue.
(2) I know and have successfully worked on a work around whereby the
application itself subscribes to the output port so as to see events as
they are played.
However, I wish to be able to make the sequencer or player work without the
use of the ALSA queue nor the workaround in (2).
Here's the pseudo-code of the relevant MIDI player routine:
for (i = 0; i < number_of_events; i++)
{
usleep(event[i].delta_time_in_microseconds);
output_and_drain_event(event[i]);
}
This routine gives a non-bearable latency on 2.4 kernels but not so much on
2.6 kernels.
How could I get the app to <u|nano>sleep() in the most accurate way in
userspace without using the ALSA queue nor the extra subscription to an
output port? Or, is there a drain or output routine that supports
callbacks? If so, I will be grateful if you could point them out. I seem
not to find any output callback routine under the docs.
Thank you very much.
Best Regards,
Carlo
--
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, Diliman 1101, Quezon City
Philippines
http://www.astra.ph
--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp
Hi,
i planned to write this for quite a while and finally got to it [though it's
not 100% working yet - It's a small program. If experienced unix hackers
might look over y use of waitpit i'd be happy :)]:
lash_wrap
It's a small program which can be used to "smuggle" non LASH apps into a LASH
session provided they meet some requirements:
- If they are jack clients, there must be a way of determining the jack client
name at startup time
- If they are ALSA seq clients the client ID must be known at client startup
time or their alsa seq name must be uniquely determined
- They must require a way to specify their state via the commandline (e.g. we
can tell ardour to load a certain ardour session at startup)
So here's how i would smuggle ardour2 into a LASH session:
lash_wrap -j ardour -- ardour2 ~/sound/ardour/brazil/brazil.ardour
The -j [--jack-name] option tells lash_wrap it must register the jack
name "ardour" with LASH. the "--" seperates the options for lash_wrap from
the commandline to start the program in question.
If we wanted also all ALSA SEQ connections of ardour to be restored we could
do:
lash_wrap -a ardour -j ardour -- ardour2 ~/sound/ardour/brazil/brazil.ardour
The -a [--alsa-name] option specifies a name which will be used to find out
the client ID of ardour by regularly searching all ALSA clients until one
named "ardour" is found. This ID is then passed to LASH.
CAUTION!!!! YOU MIGHT LOSE WORK!! READ ON:
- lash_wrap does not care for saving the state of the app in question. So
before hitting "close" in your favourite LASH session handler, be sure to
save the session in e.g. ardour manually.
- if the passed jack or alsa client names do not match for whatever reasons,
then connections won't be restored properly.
You have been warned. Nonetheless this might be useful for people who
otherwise use scripts to manage their audio sessions.
Download it here:
http://tapas.affenbande.org/lash-wrap
Regards,
Flo
P.S.: Apps like rosegarden are a bit difficult to handle, because they use
wrapper scirpts themself that exit immediately and confuse my little app
[into thinking the app exited, thus LASH thinks rosegarden has quit, too]
--
Palimm Palimm!
http://tapas.affenbande.org
--- joq(a)io.com wrote:
On 7/20/07, Paul Davis <paul(a)linuxaudiosystems.com>
wrote:
> > On Fri, 2007-07-20 at 15:31 +0000, arisstotle.52613058(a)bloglines.com
> > wrote:
> > > I've been working with the 2.6 series kernel now for some
time with satisfactory
> > > results ie (about 24 msec of latency and solid
stability). I chose the 2.6
> > > series because its the latest, and I wouldn't
have to patch as much to get
> > > support for my hardware (firewire alsa
realtime etc...). But I've been reading
> > > more and more about how the
2.4 kernels can outperform 2.6 when patched properly,
> > > any truth to
this?
> >
> > no truth. its an old data point, no longer valid. that is,
assuming we
> > are talking about RT-patched 2.6 vs. RT-patched 2.4. if you
mean vanilla
> > 2.6 vs. RT-patched 2.4, the latter is still better.
>
> I'm not sure that is even true any more. No recent data, but I tested
jackd
> extensively in about the 2.6.7 to 2.6.11 time-frame, and found those
vanilla
> 2.6 kernels quite competitive with RT-patched 2.4 ones, at least
on the
> machines I was running at the time (all uniprocessors).
>
> The
very early 2.6.x kernels were another story. :-)
> --
> joq
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev(a)lists.linuxaudio.org
>
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
>
when
you all say RT Patched you mean realtime module built, loaded configured and
used by jack correct?
I've been trying to get a kernel built that will run smoothly, but this is
the problem I keep running into, I compile the kernel with SMP processor support,
because my processor is a dual core (duh right?) but as some may know, this
automatically builds in APIC support. This then leads to unruly IRQ assignments,
in my case, a quick cat /proc/interrupts will almost allways show my soundcard
being shared with a usb port. of of course, to tease me even more, no assignment
on irq 5, i've tried the whole hop-scotch game with the pci slots, nothing
works.
Help?
-Thanks again
Hi, All!
Say, we have such audio-chain:
1. analogue source (say, mic-amp),
2. sound card's line input (let sound card be rme hdsp9632),
3. JackRack (or some other JACKified LADSPA host) with the only LADSPA plugin,
let last one be a simple aplifier,
4.1. sound card SPDIF output.
4.2. sound card analogue output,
OK, ALSA-driver, HdspMixer, JACK-server and something else are somewhere
inside this "user' POV" list.
The questions are:
- what is full strict list of "audio-entities" steps in such roughly-presented chain?
- which formats (float/integer, bitdepth) are used on each step?
- which format convertions between steps may be treated as lossless and whcih as "lossness"?
And more generally: are there common rules for keeping sound quality intact? I mean
only format-related probable issues rather hardware issues like jitter and such.
Andrew
I've been working with the 2.6 series kernel now for some time with satisfactory
results ie (about 24 msec of latency and solid stability). I chose the 2.6
series because its the latest, and I wouldn't have to patch as much to get
support for my hardware (firewire alsa realtime etc...). But I've been reading
more and more about how the 2.4 kernels can outperform 2.6 when patched properly,
any truth to this?
Hallo list!
I am searching for a sparse matrix library (prefered for C++, otherwise
C) for an audio project.
However, I found really many libraries and am a little bit confused
which one I should take - so I wanted to ask here if someone can give me
comments/suggestions to libraries they use ?
Many thanks for any comment,
LG
Georg
Hi again,
QjackCtl 0.3.1a (unstable-qt4) crash-fix released!
This is an emergency crash-fix release and everyone is envited to ditch
yesterdays one.
The change-log just says it all:
- An immediate showstopper crash upon client start was irradicated,
which was affecting those with the system-tray icon disabled,
as is the default (thanks to Ken Ellinwood for first reporting
this sloppy one).
Again, the fix source tarball is made available from:
http://qjackctl.sourceforge.nethttp://sourceforge.net/projects/qjackctl
Cheers && Enjoy,
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
I am relatively new to audio programming, but I have a task that requires converting between various audio formats:
unsigned 16 bit linear to signed 16 bit linear
u_law to signed 16 bit linear
a_law to signed 16 bit linear
unsigned 8 bit linear to signed 16 bit
signed 8 bit linear to signed 16 bit
Anyone know what the conversion functions for these would look like? Or even what a good reference is where I can find these? I have been googling around for about an hour and I have come up empty.
____________________________________________________________________________________
Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469
Greetings y'all,
Just one week after a no-regrets migration, here comes this second
iteration over the Qt4 framework for the JACK Audio Connection Kit
"cutie" GUI front-end that everybody loves or at least ought to :)
QjackCtl 0.3.1 (unstable-qt4) is out!
The main feature on this release, besides for the bug-fixes, is that
it's the very first time ever QjackCtl is made available to build and
run on all major desktop platforms: X11/Linux, Windows and Mac OS X. Yes
you read it right, Windows, and it is thought to behave consistently on
all those. One just have to take advantage from the Qt4 open-source
edition and license which in fact is the same as QjackCtl's: GPL2.
Yes, there's no turning back. QjackCtl is definitely a Qt4 application,
this release marking the departure from the old, aged Qt3 code base,
despite this one being tagged as "stable-qt3" anyway. The current branch
has "unstable-qt4" on its middle name still, but not for long ;)
Being a so-called shallowed bug-fix release, the change-log says some
thingies that were shoved out, and nothing about the ones that still are
creepin':
- The current DSP load percentage activity is now also displayed on the
system-tray icon tooltip.
- An illusive but nasty Connections/Patchbay item tooltip crash bug has
been hopefully fixed (Qt >= 4.3).
- Now using QSystemTrayIcon class facility if available (Qt4 >= 4.2)
making the system-tray option available on most platforms, notably on
Windows and Mac OS X (EXPERIMENTAL).
- Usage of QProcess class has been severely refactored, now using
QProcess::start() instead of QProcess::startDetached(), giving much
tighter control over the started jackd(mp) process. Downside is that
QjackCtl lost its ability and option to leave the process detached upon
quitting the application. Too bad.
- A new eye-candy bit has sneaked in: server mode display, that is the
RT indicator, now blinks when server/client is started/active.
- Combo-box setup history has been corrected on restore, which was
discarding the very initial default (factory) contents.
- Now that Qt4 is accessible to open-source Windows appplications,
there's some experimental stuff sneaking in for jackdmp support on win32
(http://www.grame.fr/~letz/jackdmp.html).
- Connections list items were initially sorted in descending order by
default. Fixed. Client items are now naturally sorted, again.
As usual, the source tarball might be found here:
http://qjackctl.sourceforge.nethttp://sourceforge.net/projects/qjackctl
Cheers && Enjoy,
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
