Hi all,
Today we (I should say Pau Arumà and Maarten de Boer) have given a
tutorial on Professional Audio tools in GNU/Linux in the context of some
conferences on Free Software held near Barcelona, Spain.
We have showed a great deal of applications. The final demonstration
consisted on reproducing a real professional recording studio situation.
This has been accomplished using Ardour for multitrack recording and
mixing, RoseGarden for MIDI sequencing, Jamin for mastering, qjackctl for
connecting it all and, of course, ALSA. We have recorded live audio tracks
(bass guitar) as well as MIDI from a keyboard controller. Ardour and
RoseGarden have been synchronized and the output of RoseGarden has been
recorded into Ardour. After applying some LADSPA plugins in Ardour, the
final mix has been sent to jamin for the mastering process. All
connections via Jack.
Everything has worked perfectly so I just wanted to share the success with
all the community and especially congratulate all the developers behind
those great applications and GNU/Linux audio in general.
------------------------
Xavier Amatriain
Music Technology Group
Universitat Pompeu Fabra
www.iua.upf.es/~xamat
-------------------------
BEAST/BSE version 0.6.2 is available for download at:
ftp://beast.gtk.org/pub/beast/v0.6/
or
http://beast.gtk.org/beast-ftp/v0.6/
This is a development version of BEAST/BSE, the BEdevilled Audio SysTem
and the Bedevilled Sound Engine. BEAST is a powerful music composition
and modular synthesis application released as free software under the
GNU GPL and GNU LGPL, that runs under unix.
The project is hosted at:
http://beast.gtk.org
A mailing list is available at:
http://mail.gnome.org/mailman/listinfo/beast/
This new development series of BEAST comes with a lot of
the internals redone, many new GUI features and a sound
generation back-end separated from all GUI activities.
Outstanding new features include support for skins, many sample
file formats, MIDI file import abilities, an improved piano roll
widget, the track editor which allows for easy selection of
synthesisers or samples as track sources, loop support in songs
and unlimited Undo/Redo capabilities.
Overview of Changes in BEAST/BSE 0.6.2:
* Rewrote scrollbar sizing, so tracks and parts are easily resizable
* Lots of small GUI enhancements and fixes
* Added CPU usage information view
* Enabled tooltips on menu items
* Rewrote logging, messaging and error reporting system
* Fixed attack time handling in SimpleADSR
* Added support for 1/32, 1/64 and 1/128 notes and quantization steps
* Added skin and row highlighting support to the pattern editor
* Adjusted skins (pacified some of the more disturbing ones)
* Added British English translation [Gareth Owen]
* Added Canadian English translation [Adam Weinberger]
* Added Brazilian Portuguese translation [Raphael Higino]
* Updated Catalan translation [Xavier Conde Rueda]
* Updated Czech translation [Miloslav Trmac]
* Updated Dutch translation [Tino Meinen]
* Updated Croatian translation [Robert Sedak]
* Updated Spanish translation [Francisco Javier F. Serrador]
* Updated Russian translation [Alexandre Prokoudine]
* Updated Portuguese translation [Duarte Loreto]
* Updated Albanian translation [Laurent Dhima]
* Various sfidl fixes [Stefan Westerfeld, Tim Janik]
* First steps taken towards mixer infrastrukture
* Fixed user configurable debugging support
* Lots of adaptions to GLib/Gtk+-2.4
---
ciaoTJ
>>>
Please specify if you mean per fragment (buffer, usually 2) latency or
total latency.
<<<
Sorry, yes, I mean per-buffer latency. WDM lets buffer sizes get down
to 1.5 msec.
>>>
the Tascam guys that produce Gigastudio, would have dropped their own
low latency driver model (GSIF) and would have
adopted WDM,ASIO which would ease the pain of integrating Gigastudio
with other audio apps.
The other theory why they still use GSIF (now they even developed GSIF
further by releasing GSIF2) because it would
be too time consuming (perhaps they need to rewrite a large section of
code to adapt Gigastudio to WDM/ASIO) .
<<<
When Gigastudio first came out they still needed to support Win95 and
Win98. WDM doesn't exist or work very well on these operating systems.
Combine this with the fact that Giga does a lot of processing in kernel
mode and it's understandable why they needed to invent something like
GSIF.
They still do work in the kernel, which would also rule out ASIO. ASIO
is a user-mode API, not a kernel mode driver model.
I'm surprised they don't do WDM today, but I really doubt it's because
of some inefficiency in WDM. They can keep all their code in the kernel
and still do KS.
>>>
at any cost. I think one of the best tradeoffs is simply writing VST
plugins (or using other plugin APIs) because hosts are usually
optimized for low latency audio I/O, can use whatever audio drivers they
wish/need and reinventing the wheel for the
audio application developer is simply a waste of time.
Not to mention that using a plugin API you get perfect integration in a
virtual studio.
<<<
Plugin APIs are different than driver models. You can run VST plugins
in ASIO hosts apps, WDM host apps or even MME host apps. If you were
developing an audio host app you would need to choose both which driver
model you wanted to support, as well as which kind of plugins you want
to support.
>>>
I don't see why WDM should not become the only driver model
standard in the windows pro audio world.
<<<
Totally agree.
>>>
As said I'm not an expert in low leven windows drivers but I guess WDM
is still not perfect so audio apps producers
prefer to go their own way to squeeze out the maximum from the hardware
(especially for virtual instruments it's very important
to achieve low latencies so that the instruments can be played live).
<<<
In the last few years every pro sound card that's come out has had both
WDM drivers and ASIO drivers. Steinberg applications only support ASIO,
so if the h/w vendors want to support both Steinberg and others, they
need to write both kinds of drivers. It's about being compatible with
more applications.
>>>
I am preparing some slides about Linux audio, and while comparing Linux
with Windows, I have been wondering how the ASIO drivers manage to
obtain low latency on MS Windows, an operating system that does not seem
capable of low latency in any other way. So what tricks did Steinberg
come up with to get around that? I'd like to be able to say why the
Linux
approach is better/cleaner.
<<<
ASIO provides an interface directly to the kernel mode driver, typically
through a private device I/O control between the user mode ASIO DLL and
the kernel mode driver. By talking right to the driver, they bypass the
system component known as KMIXER, which adds 30 msec of latency to all
audio in Windows.
But ASIO isn't the only way around KMIXER. With the advent of Win32
Driver Model (WDM) Kernel Streaming (KS), the Windows O/S is indeed
capable of very low latency. WDM KS has a standardized device I/O
control set that's part of the Windows audio stack. KS makes it
possible to stream audio at sub 5-msec latency -- approaching 1 msec
latency -- using a direct interface to the "miniport" driver in the
Windows driver stack.
I wrote a white paper about all this a few years back:
http://www.cakewalk.com/DevXchange/audio_i.asp
There's a diagram of the audio stack in Windows which might be helpful.
Note that we never needed to create custom IOCTLs for Windows.
Microsoft followed up after this meeting by disclosing the Windows
kernel IO controls for everyone to use, known as DirectKS:
http://www.microsoft.com/whdc/device/audio/DirectKS.mspx
As far as I know the ASIO4All driver is built using DirectKS.
----------
Ron Kuper
VP / Engineering
Cakewalk
http://www.cakewalk.com
On Tue, Jul 06, 2004 at 12:33:30PM +0100, Rui Nuno Capela wrote:
> martin rumori wrote:
> >> Is anybody out there using an ATI Radeon card with DRI and DRM ?
> >
> > jackd with realtime-lsm from the cmdline is fine, with qjackctl it
> > fails. qjackctl with realtime but no-mlock works fine.
> >
>
> Either with no-mlock, LD_ASSUME_KERNEL or whatever switch I've been trying
> to reproduce those nasty lockups some of you are suffering.
>
> Using qt-3.3 on kde-3.2, it that matters.
>
> I think we're narrowing around drm, realtime mode mlock and the 2.6
> kernel, are we?
appears like that. as soon as i switch to the vesa driver (direct
rendering off) there is no problem. no problem, too, on my other
machine with nvidia binary driver.
on my machine, it's qt-3.2.3(-mt) from debian unstable.
bests,
rm -ri
Hello,
I am preparing some slides about Linux audio, and while comparing Linux
with Windows, I have been wondering how the ASIO drivers manage to
obtain low latency on MS Windows, an operating system that does not seem
capable of low latency in any other way. So what tricks did Steinberg
come up with to get around that? I'd like to be able to say why the Linux
approach is better/cleaner.
Maarten
Hi all,
I am using the latest 2.6.7 kernel (tried also 2.6.5) but with hdsp I cannot select anything lower than 1024x2 buffer settings in jackd without having massive xruns.
Asoundrc is fine, modprobe.conf is fine too.
The hdsp runs fine with the aforementioned settings but anything lower simply is horrible.
The kernel is patched with all kinds of mm patches but I am not currently using -r option nor the realtime module (a bit scared of freezing my machine :-). Is this the best one can do in user-space?
Any help is greatly appreciated!
Best wishes,
Ico
I thought it might worth mentioning 2 days of intense LAD-friendly
talks at the Libre Software Meeting on July 7th and 8th. The program
will include:
Dave Phillips on "The Scene"
Yann Orlarey on Faust
Takashi Iwai on ALSA
Steve Harris on RDF & Audio
Julien Villain on Gestural/Listening training
Paul Davis on Ardour (talk + 2hr workshop)
Julien Ottavi on APODIO
Damien Cirotteau on AGNULA
If you're in the Southwest corner of France and want to come and fill
the rooms just a little more, not to mention sample of the "young
upstart" red and white wines of the region (quite a political battle
in the region, apparently), check with lsm2004.abul.org. A glass of
decent wine will be considered partial downpayment on your copy of the
Ardour manual :)
--p
Hi everyone,
It's been a while, although this time there's not much. Just minor fixes,
nothing very outstanding. However here it is, a new public release for
QjackCtl, the little Qt (cutie:) application to control the JACK sound
server daemon, specific for the Linux Audio Desktop infrastructure.
Check it out from the usual place:
http://qjackctl.sourceforge.net
>From the changelog:
- Patchbay socket dialog client and plug list option items are now
properly escaped as regular expressions.
- JACK callbacks are now internally mapped to QCustomeEvent's instead
of using the traditional pipe notifications.
- The system tray popup menu is now featured as a context menu on the
main application window too.
- The reset status option is now included in the system tray popup menu.
- Server stop command button now enabled during client startup interval;
this makes it possible to stop the server just in case the client
can't be activated for any reason.
- Top level sub-windows are now always raised and set with active focus
when shown to visibility.
Hope you enjoy.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org