Question for the DSP gurus:
How hard would it be to implement an AC3 encoder as a LADSPA plugin that
could be used in an ALSA config to encode stereo and 5.1 sources on the
fly? Many Windows drivers seem to contain one, and it would be a nice
response to the naysayers on LKML who doubt the power of ALSA.
It appears that a simple AC3 encoder is ~1500 lines of code:
http://www.koders.com/c/fid04210C5E2BC83FC0BA5E0A2A1C37D52503E31EFD.aspxhttp://www.telos.de/Surround_Sound_Formats.360.0.html#1051
FWIW, when emu10k1/2 based cards first came out Creative claimed the DSP
was powerful enough to do AC3 encoding on the fly, but, they never
shipped an implementation - their drivers did it in software. One of
their engineers said the DSP wasn't suited for the frequency domain
processing required to encode AC3.
Lee
Hi,
new to this list and knowing absolutely nothing about C++ audio
programming I would like to ask for a little bit of help.
I want to create a console keyboard to MIDI application and for this I
would like to read the physical status of keyboard keys. Thank you.
Carlo Capocasa
Reuben Martin:
>> (Why hasn't anyone made a ladspa plugin with a GUI by the way? Its
>> really simple just spawning of a gui process program.)
>>
>
>Because you have no way of knowing if the platform you are running it
>
No no, you misunderstand. I said "spawning of a gui process" (I should
rather have said "spawning off a gui process", but I didn't. :-) ).
Well, I guess the question was more retorical. I personally think reason
is that linux programmers aren't that much into bells and whistles as
windows programmers.
>on will have support for the toolkit needed by the GUI. It would be
>nice to append the LADSPA spec to allow for a simple markup language
>to describe the GUI, and then depend on the host to render that markup
>language into a GUI. It would make it toolkit independent.
No, that would not be nice at all. Far too complicated for the hosts, and
guis would be different from host to host, and limited by the markup
language
What would be nice was if we used a common gui-designer like qdesigner
or glade, so that someone could make an automatic gui-spawner library
that used the xml-files from qdesigner or glade to make guis. That way,
anyone could make/edit gui's quite easely. The idea was proposed some
years ago, but no one has picked it up. Its not much work to do, but I
guess no one has got the time. It must be a community project as well,
because it would be useless if no one bothered to make guis for the
various plug-ins or the hosts didn't support it. (well, the host-problem
could be fixed automatically by making a wrapper ladspa plugin, but its
not the ideal solution)
Lee Revell:
> > Won't help if the code is to be part of a GPL'd
> > application.
>
> The Linux kernel is a GPL'ed application yet Nvidia
> gets away with linking into it.
Quite different. Anyone can distribute the kernel
without caring about the existence of the nVidia
drivers. But if an application includes the VSTSDK, it
presumably isn't complete without it.
Chris
Screenshot:
http://www.kvraudio.com/forum/viewtopic.php?
t=114488&postdays=0&postorder=asc&highlight=linux&start=105
i will be interested to see just how good its audio handling
capabilities are.
--p
Lee Revell writes:
> On Fri, 2006-01-27 at 15:57 +0100, Michael Bohle wrote:
> > But anyway, VST on Linux is dead now, beause
> > most of the user are not
> > able to compile it for themself.
>
> Wrong. You just need to write a wrapper that
> handles the compiling.
Won't help if the code is to be part of a GPL'd
application.
Also, I think (?) you have to register to download the
VSTSDK.
Chris
One Harold Chu on LKML is insisting that POSIX requires
pthread_mutex_unlock to reschedule if other threads are waiting on the
mutex, and that even if the calling thread immediately tries to lock the
mutex again another thread must get it. I contend that both of these
assertions are wrong - first, I just don't read the standard that way,
and second, it would lead to obviously incorrect behavior - unlocking a
mutex would no longer be an RT safe operation. What would be the point
of trylock() in RT code if unlocking is going to cause a reschedule
anyway?
Can anyone back me up on this?
Lee
Hello
I started a session in Ardour - drag and dropped a .wav file, then recorded (sucessfully) from a Jack input.
Checking the session folder, Ardour appears to record to disc as it's going along (on-the-fly).
I presume Ardour can also route the incoming sound to its outputs, for monitoring.
Does anyone know what mechanism Ardour uses to do this?
(I'll walk blindly into speculation. Ardour uses a jack ringbuffer on its Jack input port, in the approved way - but that only leaves one read on the ringbuffer output...)
Robert
Hacked some test code here and discovered something "interesting" with
lo_server_add_method() and method handling. If I try to do it like in
the examples and add the default/debug ("match all") method first, it
gets called for every incoming message, before the real handler is
called. That is, I see an error message - and then the correct method
handler is invoked anyway.
Looking quickly at the code, I'd actually expect this behavior, as
lo_server_add_method() does indeed add methods at the end of the
list.
Trying the examples again, I realize that they demonstrate this
behavior as well, so maybe it's not just my code doing something
funny. :-)
This is with liblo 0.22 on Gentoo/AMD64.
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
'-- http://www.reologica.se - Rheology instrumentation --'
Hello everybody !
I've just added a resampling function to my code thanks to the
excellent work of Erik de Castro Lopo (thanks a lot !). Combined with
libsndfile (thanks again) it is really easy to load any sound file I
want. But I'd like to make sure I'm using it correctly.
I process my input data in one pass using src_simple() and I have to
compute the length of the output data buffer beforehand. So I did
somehting like this :
out_len = (long int) ceil((double) in_len * ratio);
It seems that my output buffer is always one frame too big (I checked
this by reading the output_frames_gen field of the SRC_DATA structure
after the processing is done).
Is it safe to assume that using floor() instead of ceil() will not lead
to a too short output buffer in some cases ?
I can live with wasting a malloced float but I'd like to be sure it
cannot be done in a prettier way.
Thanks.
--
David