Hi Ralf, thanks for the info.
So Ubuntu uses Horgand version 1.14, not the recent version 1.15. Also, I found some more buffer overflows.
However my main problem remains: I would like to find those authors. Their email adresses in the README alas don't work.
Wouter Boeke
libsoundio is a C library providing cross-platform audio input and output
for real-time & consumer software. It supports JACK, PulseAudio, ALSA,
CoreAudio, and WASAPI.
It is an alternative to PortAudio, RtAudio, and SDL audio.
http://libsound.io/
Hi all.
After upgrading to fc22 during summer, I'm having issues with 32bit jack
clients running in my 64bit jackd.
I'd be thankful for any clues to what's going on, and ways to debug
this. And if others would care to check, and confirm/disprove the same
behavior, please tell me what you get.
Here's what happens:
The 32bit clients connect well, but the callbacks never seem to return,
making jackd send out a steady stream of xruns and errors:
JackEngine::XRun: client = simple_client was not finished, state = Triggered
I'm checking with jack2 installed (jack-1.9.10), with .i686 and .x86_64
versions installed using the standard fedora packages.
The same 32bit clients work well in fc21, fc20, and ubuntu 14.04 (in a
vm on the same hardware). Afaik, nothing has changed vs. the -mixed
flag in jackd, and would expect 32bit clients to run well inside a 64bit
jackd.
Checking with example-clients/simple-client.c from the jack sources:
$ gcc -m32 -g -O -lm -ljack simple_client.c -o simple_client
$ ./simple_client
- results in the noted behavior. Without -m32 everything's fine.
Thanks,
-anders
Hi Can anyone point me out to code that extracts the spectral envelope
of a signal. Due to my tight time constraints I can't dig much into the
topic to develope such an extractor, so somewhat working C/C++ code is
appreciable.
Thanks Gerald
On Sat, Aug 15, 2015 at 05:14:12PM +0100, Simon SD1 wrote:
>
> > On 15 Aug 2015, at 16:06, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
>
> > 'Delayed' connections (those that create a cycle) can be
> > reverted to normal ones as soon as possible (the current
> > implementation does this only when the entire graph has
> > becomes cycle-free).
>
> The options discussed in 2004 were to revert those connections
> when the entire graph became cycle-free, or never to revert them
> so long as they existed.
Waiting for all cycles (if there were ever more than one) to be
broken seems IMHO no better than reverting ASAP. In both cases
the changes are probably not anticipated by the user. My personal
preference would be to never revert such connections.
> The rationale for never reverting them was that a pair of connected
> clients would suddenly be running in a different order — and a buffer’s
> worth of data between them would vanish
But that can happen anyway in Jack1 if a cycle is skipped.
> The rationale for reverting them was lower latency, and to prevent
> pathological cases where a chain of clients could be running in entirely
> the wrong order because of cycles that used to exist but don’t any more.
Seems rather unlikely. If such things are a real problem, then the clean
solution is to make things explicit to the user, but this requires a
change of the API: when a connection is made, you could have the options
- don't care (default), but return result,
- must be normal, fail if not possible,
- must be delayed, fail if not possible.
I've done this in a multithreaded single-process framework (for
things like softsynths, mixers, etc.) It allows to set up feedback
connections in a controlled way.
With the algorithm I have in mind, never reverting is the easiest,
doing so ASAP comes next, and reverting only if the result would
be completely cycle free would be the hardest.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
Hi all,
The Center for Computer Research in Music and Acoustics (CCRMA) at
Stanford University is a multi-disciplinary facility where composers and
researchers work together using computer-based technology both as an
artistic medium and as a research tool
(https://ccrma.stanford.edu/about). We are (still) currently looking for
a great person to help lovingly take care of and feed our servers,
workstations, and multichannel audio setups.
The right person will be working with and helping a diverse community of
interdisciplinary students (ranging from undergrads to DMAs and PhDs,
studying Music, EE, CS, and many other fields), researchers, and faculty
from all over the world. Our computers mostly run GNU/Linux but there
are Macs in the studios and even a couple of Windows machines in the
NeuroMusic lab. We do complex multichannel audio setups in our studios
and for concert diffusion (3D sound in up to 25.8 channels), we maintain
all our own servers and backups, and we package our own software (and
other developers' open source free software) in repositories so that
anyone can install it easily. All this is quite a lot of work and we
need help!
Qualities sought: curious, tenacious, responsible, self-motivated,
tech-savvy, willing to learn, artist- and wizard-compatible, strong team
player who can work independently.
Full details about the job are here:
https://stanfordcareers.stanford.edu/job-search?jobId=66452
-- Fernando
On Mon, Aug 10, 2015 at 04:43:01PM -0400, Paul Davis wrote:
> it provides output indicating the logic decisions that lead to the
> execution order.
I spent most of the day trying to convinve myself that I was
overlooking something. But in the end the conclusion of all
that work is this:
* The algorithm used by Jack1 to determine the order of
* running clients in each cycle is fundamentally flawed.
The reason in mathematical terms is quite simple.
Both the relations 'A feeds B' and its transitive closure
'A feeds B, maybe indirectly' define only a *partial order*
on the set of clients. Now all classical sorting algorithms,
including the merge sort used in this case, assume a *total
order* of the set to be sorted, and may not produce the
correct result if only a partial order is defined.
It's easy to see this in a less abstract way. All classical
sorting algos are designed to reduce the number of compare()
calls. For example, if they find that a == b and a == c
they will in most cases avoid testing b against c, since
under total order it must be true that b == c.
Now if a '0' return from the compare() function does not
mean equality but rather 'not connected' things change.
Using the example above, you *can not* conclude that b
and c are not connected.
So all it takes is a few unconnected clients or two
or more independent chains to increase the probability
that a classical sort algorithm will fail to produce
a correct sequence.
I actually worked out the example I posted yesterday
with pencil and paper, including all the merge sorts.
This produced exactly the results posted. So there
is no bug in the current code, it is just the wrong
algorithm.
To find a linear sequence preserving the order of a
partially ordered set you need what is known as
'topological sorting'. It's usually implemente using
depth-first search (DFS) with post-order output.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)