Greetings,
I am fairly new to USB dev (in linux in particular, but also in general), but I
would very much like to try to get support for the above device working in
snd-usb-audio.
- Is this an appropriate place to discuss snd-usb-audio?
- Are there any recommended reading pointers for behavior of the quirk table?
I patched parse_audio_format_rates_v2(), get_sample_rate_v2(), and
set_sample_rate_v2(), and through some sort of beginner luck was able to get
aplay audio out of the first two channels. That was incomplete hackery though
(eg fixed sample rate), and I would like to learn how to properly add quirk
support. There have been other reports that this device worked OOTB, but I
fail to see how!
I've also been examining the traffic to the device with wireshark and a
win7 vm, but the learning curve for USB is a bit steep, so I am digesting. (:
If anyone can provide suggestions on lsusb output alone, here's what I have:
http://pastebin.com/pA9MLQet
cheers,
Greg
[x-post from alsa-devel due to empty thread -
see: http://mailman.alsa-project.org/pipermail/alsa-devel/2015-July/094682.html]
Some updates on <http://kokkinizita.linuxaudio.org/linuxaudio/downloads/index.html>
zita-ajbridge-0.6.0
- Added -S option, disables resampling but of course
requires word-clock sync.
- Auto selection of best resampler filter lenght.
- Cleanup and bug fixes.
zita-mu1-0.2.2
- Bugfix: will now exit when zombified or when
jackd terminates.
- Added proper license headers and GPL3 copy.
I also completely replaced the code in Jack1 that
calculates the proper running order of clients.
The previous algorithm failed to do this in some
cases. It could not be 'fixed' easily as it was
basically using the wrong algorithm.
Affected files are
modified: include/engine.h
modified: include/internal.h
modified: jackd/clientengine.c
modified: jackd/clientengine.h
modified: jackd/engine.c
There seems to be no interest from the Jack devs,
but if anybody wants to test this I can either
provide the modified files or a patch against
git commit 5af5815c47630b77cc71c91a460f8aa398017cf7
(current HEAD).
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 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
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 8 Aug 2015 16:48:45 +0000
> From: Fons Adriaensen <fons(a)linuxaudio.org>
> To: Linux Audio Developers <linux-audio-dev(a)lists.linuxaudio.org>
> Subject: [LAD] Strange Jack1 problem
> Message-ID: <20150808164845.GA7139(a)linuxaudio.org>
> Content-Type: text/plain; charset=us-ascii
>
> Hello all,
>
> I've been testing some new features of zita-njbridge. The test
> setup was:
>
> zita-n2j -> jack_delay -> zita-j2n
>
> with the loop closed via the network. The purpose of the test was to
> verify the added latency. It produced the expected result - until I
> started another (unrelated) Jack app. Suddenly the delay increased
> by one period. Stopping the other app had no effect. Restarting it
> made the measured delay return to its original value. Then each
> time another app (no matter which one) was started or any ports
> were connected or disconnected, the delay switched been these two
> values.
>
> First I suspected some bug in zita-njbridge - it has some logic to
> detect skipped cycles etc. and handle them gracefully. But I found
> no error there, and the problem also occured when no cycles were
> skipped.
>
> The I let n2j write the jack usecs time at the start of its process()
> to shared memory, and j2n read it and print the difference with its
> own process() time. This confirmed what I suspected: when the delay
> increased, the order of execution of n2j and j2n was reversed.
>
> Note that as far as Jack is concerned there is no loop in the
> graph, and hence no ambiguity as to the correct order.
>
> So the conclusion seems that Jack1 is doing something unexpected
> each time the graph order is recalculated.
>
> This seems to depend on how many apps or ports are active before
> the test is started. When the test apps are the first ones all
> seems to be OK.
>
> I could not reproduce the problem with Jack2.
>
> Has anyone noticed similar things ?
>
> Ciao,
>
> --
> FA
>
I am surprised also JACK1 does no do topological sort which obviously is the needed way...
Note that JACK2 does not need to do topological sort of the client graph, since it's client activation system is based on a "data flow" model. Client "order" is found out with this "activation token" model that goes progressively from inputs to outputs during a given cycle. It means that for instance the following graph :
IN ==>A ==> OUT
IN ==> B ==> OUT
where A and B are connected to IN and OUT, and that would be topologically sorted to 2 correct activation sequences (either IN ==> A ==> B ==> OUT) (or IN ==> B ==> A ==> OUT) would be activated in parallel in JACK2, so A can possibly run before B, or the contrary, or both at the same time on 2 different cores….
Stéphane
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)
