Hello.
Soon I will work on a linux kernel driver for a custom audio decoder device
that is being developed by a company I work for. If not going into
details, that devices reads A52-encoded stream from system memory, and
writes raw pcm stream to system memory.
Simplest thing to do is - implement a character device, where user-space
will write encoded stream, and from where user-space will read decoded
stream.
(driver for similar hardware, located at
http://sourceforge.net/projects/vs10xx/, does that).
However, perhaps a better architecture (e.g. in-kernel intergation with an
audio sink) is possible?
I'm looking for any related information - e.g. ideas on what interface to
implement, examples of drivers for similar devices, etc.
Thanks on any hints.
Nikita Youshchenko,
embedded linux developer.
I am playing around with GCC and Clang vector extensions, on Linux and
Mac OS X, and i am getting some strange behaviour.
I am working on jMax Phoenix, and its dsp engine, in its current state,
is very memory bound; it is based on the aggregation of very small
granularity operations, like vector sum or multiply, each of them
executed independently from and to memory.
I tried to implements all this 'primitive' operations using the vector
types.
On clang/MacOSX i get an impressive improvement in performance,
around 4x on the operations, even just using the vector types for
copying data; my impression is that the compiler use some kind of vector
load/store instruction that properly use the available memory bandwidth,
but unfortunately i do not know more about the x86 architecture.
On gcc/Linux, (gcc 4.5.2) the same code produce a *slow down* of around
2.5x.
Well, anybody have an idea of why ?
I am actually running linux (Ubuntu 11.04) under a VMWare virtual
machine, i do not know is this may have any implications.
Thanks,
Maurizio De Cecco
Hello,
A new/upcoming LV2 extension (from Lars Luthman) includes facilities for
sending host-calculated metric data for audio ports to a UI, for
metering and such. This is intended as a sane replacement for the
currently used kludge of having plugin control output ports provide this
information.
So, more DSP-minded folks, my question is: what data is required, and is
a reasonable compromise between overhead and expressiveness? The
current revision has the following:
/**
A data type that is used to pass peak and RMS values for
a period of audio data at an input or output port to an
UI, using port_event. See the documentation for
pui:floatPeakRMS for details about how and when this
should be done.
*/
typedef struct _LV2_PUI_Peak_RMS_Data {
/**
The start of the measurement period. This is just a
running counter that must not be interpreted as any
sort of global frame position. It should only be
interpreted relative to the starts of other
measurement periods in port_event() calls to the same
plugin instance.
This counter is allowed to overflow, in which case it
should just wrap around.
*/
uint32_t period_start;
/**
The size of the measurement period, in the same units
as period_start.
*/
uint32_t period_size;
/**
The peak value for the measurement period. This
should be the maximal value for abs(sample) over all
the samples in the period.
*/
float peak;
/**
The RMS value for the measurement period. This should
be the root mean square value of the samples in the
period, equivalent to sqrt((pow(sample1, 2) +
pow(sample2, 2) + ... + pow(sampleN, 2)) / N) where N
is period_size.
*/
float rms;
} LV2_PUI_Peak_RMS_Data;
Thanks,
-dr
Howdy!
TYOQA (the year of qtractor automation for the clueless) is now pretty
real. I'd say it's all been my my prerogative, again and again, doing
things my own way (do I hear Frank S. singing? nope. move along...).
Is this the time to do the unthinkable? Should I tag it as beta now?
Should I? There's one single reason for not doing so and a couple of
others to make it through:
1. basically it's all the same functionality that stays put or improved
in a few spots;
2. it just feels like it! :)
Now comes the mighty corrosive one: I'll be off on vacation soon. Summer
is waiting for me. And I just hate to miss that kind of deadline. Woohoo!
Is there anything else to mention? Go ahead, make your day:
Qtractor 0.5.0 (alpha zulu) is now released!
Release highlights:
* TYOQA! Audio/MIDI track and plugin parameter automation (NEW)
* MIDI controller catch-up behavior (NEW)
* All zooming in/out relative to views center (NEW)
* Audio gain/panning smoothing changes (FIX)
Happy summer 2 y'all!
Website:
http://qtractor.sourceforge.net
Project page:
http://sourceforge.net/projects/qtractor
Downloads:
- source tarball:
http://downloads.sourceforge.net/qtractor/qtractor-0.5.0.tar.gz
- source package (openSUSE 11.4):
http://downloads.sourceforge.net/qtractor/qtractor-0.5.0-3.rncbc.suse114.sr…
- binary packages (openSUSE 11.4):
http://downloads.sourceforge.net/qtractor/qtractor-0.5.0-3.rncbc.suse114.i5…http://downloads.sourceforge.net/qtractor/qtractor-0.5.0-3.rncbc.suse114.x8…
- from the dusty shelf: user manual (anyone?):
http://downloads.sourceforge.net/qtractor/qtractor-0.3.0-user-manual.pdf
Weblog (upstream support):
http://www.rncbc.org
License:
Qtractor is free, open-source software, distributed under the terms
of the GNU General Public License (GPL) version 2 or later.
Change-log:
- MIDI controller learn/catch-up sees the way in: MIDI controller
changes are now only effective after catching-up with their respective
program parameters, avoiding abrupt jumps and keeping a safe and
continuous behavior.
- Track/Height menu is now featured, giving access to Increase, Decrease
or Reset the current track height.
- All changes to audio gain and panning on tracks and buses are now
applied following a piece-wise linear ramp, reducing the old nasty
clicks, pops or zipper artifacts that might be awfully audible on some
situations, most specially on automation.
- All zooming in/out is now relative to either the viewport center or
current mouse cursor position if found laying inside.
- TYOQA! the underground sources have emerged:... after years in the
making, track automation, or dynamic curves as some like to call, is
finally a reality, tricky but real ;)
- Audio clip anti-glitch/ramp-smoothing effect is now slightly
independent of current buffer-size period (mitigating bug #3338113 effect).
- Once buried under the Edit menu, Clip menu has been finally promoted
to top main menu.
- Debugging stacktrace now applies to all working threads.
- Fixed muted loop playback on audio clips ending coincidentally with
the loop-turn/end point.
- Old/deprecated JACK port latency support added to audio recording
latency compensation.
- Audio clip merge/export lock-ups now untangled (fixes bug #3308998).
- LV2 extension headers update.
- Fixed configure of newer LV2 host implementation stack (LILV) when
older (SLV2) is not present.
Enjoy && Cheers!
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
---------- Forwarded message ----------
From: Lieven Moors <lievenmoors(a)gmail.com>
Date: Mon, Jul 25, 2011 at 12:55 PM
Subject: Re: [LAD] lv2 extension bugs
To: David Robillard <d(a)drobilla.net>
On Sat, Jul 23, 2011 at 10:46 PM, David Robillard <d(a)drobilla.net> wrote:
> On Sat, 2011-07-23 at 21:22 +0200, Lieven Moors wrote:
> > On Sat, Jul 23, 2011 at 09:10:42PM +0200, Lieven Moors wrote:
> > > On Sat, Jul 23, 2011 at 02:19:39PM -0400, David Robillard wrote:
> > > > On Sat, 2011-07-23 at 17:53 +0200, Lieven Moors wrote:
> > > > > On Sat, Jul 23, 2011 at 10:23:13AM -0500, Gabriel Beddingfield
> wrote:
> [...]
> > Since I'm not even sure it is a bug
> > in an LV2 extension, I might be forgiven
> > to post it here.
> >
> > It's a problem you run into when you
> > try to configure one of the drobilla
> > packages (I think it's flowcanvas).
>
> ... Well, this thread was pretty silly. If it's a problem with building
> my repository, hosted at drobilla.net, then yes, file bugs there :P
>
> (Though it's certainly not flowcanvas, which has nothing whatsoever to
> do with LV2)
>
> > Configure fails, says that ext/event/event-helpers.h
> > cannot be found, even though it's there.
> > After scratching my head for a while,
> > I found out it's the waf test that is
> > failing.
> >
> > On Harry Haaren's blog I found the
> > answer.
> >
> > modify line 28 in event-helpers.h
> > by removing http from the address.
>
> Line 28 in event-helpers.h is an include line that does not contain
> "http" anywhere:
>
> http://lv2plug.in/repo/trunk/ext/event.lv2/event-helpers.h
>
> The same is true of the version in the latest release of that extension:
>
> http://lv2plug.in/spec/lv2-event-1.2.tar.bz2
>
>
>
OK, what happened was that I landed on the http://lv2plug.in/ns/ext
page, was expecting a download extensions link, didn't find it, and
downloaded
the files manually from the links on those pages.
sorry for all the fuzz...
greetings,
lieven
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 25 Jul 2011 12:04:06 +0200
> From: Maurizio De Cecco <jmax(a)dececco.name>
> Subject: Re: [LAD] GCC Vector extensions
> Cc: linux-audio-dev(a)lists.linuxaudio.org
> Message-ID: <4E2D3F96.2010206(a)dececco.name>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> Short resume of my initial post: i found that using the gcc vector
> extensions induced a 2x slow down using gcc, and a 4x speed up in clang.
>
> I made more tests, isolating a small code example, on Mac OS and Ubuntu,
> and i found out the origin of the problem, even if i do not know what
> exactly happening.
>
> My original test used vectors of float of size 8; the gcc vector
> extension documentation says that if the vector size do not match the
> hardware vector size, the code is synthesized in some way.
>
> With a vector size of 8 i found the above results under Mac OS X, using
> clang and gcc4.2, and under Ubuntu 11.04, using clang and gcc4.5.2.
>
> When i move to a vector size of 4, things go better; clang slow down wrt
> the size of 8 of around 2x, and gcc obtains the same result; the
> interesting point is that gcc obtains essentially the same speed with
> and without vector extensions, meaning probably that the compiler is
> good enough in vectorizing the code, at least in the the test cases i used.
>
> I include the code, results and scripts to run the tests in a small zip
> if anybody want to make other tests; the test code compute an arbitrary
> vector computation (essentially 100 million multiply add), starting from
> a seed given as argument.
>
> The code is modeled around the way jmax compute, i.e. one vector
> operation at a time on vectors passed by pointers, and it is not
> designed to be the fastest possible code to implements this computation.
>
> Thanks for the help,
>
> Maurizio
You should really give the produced assembly code in each test case.
Stephane
Hello
I like to announce the first release of gxtuner, a simple, small and
lightweight guitar/bass tuner for jack.
gxtuner comes with a analogue like interface (scale), show the tune
(char) and the accumulated frequency (Hz) and is licensed under the GPL.
It's a break out of the guitarix tuner module, you can download it here:
http://sourceforge.net/projects/guitarix/files/gxtuner/gxtuner-1.0.tar.bz2/…
have fun
hermann
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi list,
i compiled the alsa sources with the dummy otion,
now finished using it, how do i get rid of it?
i tried to compile the sources without the dummy otion, but it didnt
work. (perhapes with an ice1724 option?)
i completley removed the alsa packages and reinstalled them without any
effort.
lsmod doesnt show any snd module...
im using natty with lowlatency kernel (11.04 + 2.6.38lowlatency)
and an ice1724 chip
thanks in advance
regards
Ck
- --
PGP Key ID 0x528422c1;
PGP Public Key / PGP Key verification:
pgp.mit.edu
pgp.zdv.uni-mainz.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOJ/OKAAoJEBra75lShCLBUgoIALVE0FCz+VCgAr4XelbbMENV
w355Ckvhu0oYAtx2fGqcbKZoFM2IDnXCC7RXXsiX+EyYv9kAy/E5fRFcYbzXN6Kp
Qgt08nUJvdrX2GlVeuWpvCDYP4RY8cjhk0lHyWFIKc88jKCvB/OB+LvPTQPdcN++
85FEeS6mYGZJupIy2mMLFivLIYH0jdG8VMb4B+fxchBMCNMqfPRCYilK0uC6RwZ5
2gFdS2rb/MTj3lC5r2cU10x6zM9tB4CpnGz11mleN9RlKA2EtV/myKDBn58TXcUq
tNDLMeqyahH5JB1ACKMuBA4iYEs+z65ASaH/0bU1BgSSEVoaACKmtykRkequ6cQ=
=HJAx
-----END PGP SIGNATURE-----
Friends:
Cal, the lead developer of Yoshimi, passed away on July 2 in Victoria, Australia.
http://tributes.couriermail.com.au/obituaries/couriermail-au/obituary.aspx?…
While this was not unexpected, we're all very sad to see him go.
I'm doubt that his family has any idea what he meant to us. If anyone has an idea on how we can show our appreciation, please share it.
-gabriel
