From 21704435b1619b299b790ef1a3138b180dd375c5 Mon Sep 17 00:00:00 2001 From: Paul Davis Date: Wed, 24 May 2006 20:40:11 +0000 Subject: [PATCH] provide interface to PBD::ThreadCreated() in BasicUI; remove/clean DOCUMENTATION files git-svn-id: svn://localhost/trunk/ardour2@531 d708f5d6-7413-0410-9779-e7cbd77b26cf --- DOCUMENTATION/README | 101 --------------------- libs/surfaces/control_protocol/basic_ui.cc | 8 ++ libs/surfaces/control_protocol/basic_ui.h | 4 + 3 files changed, 12 insertions(+), 101 deletions(-) delete mode 100644 DOCUMENTATION/README diff --git a/DOCUMENTATION/README b/DOCUMENTATION/README deleted file mode 100644 index b1e85b4d37..0000000000 --- a/DOCUMENTATION/README +++ /dev/null @@ -1,101 +0,0 @@ - ARDOUR README - - Paul Davis June 2003 - -Welcome to Ardour. This program is still very much under development, -but has now reached the stage where it will be productive and useful -to have other people testing it out and perhaps (hopefully!) fixing -bugs and adding features. - -**** SECURITY ******************************************************* - -To run Ardour with the lowest latencies, it's necessary to use POSIX -Real-Time Scheduling as well as locking all the memory it uses into -physical RAM. These requirements can only be met if Ardour is run with -root priviledges. - -On the other hand, things are not so bad. If you don't attempt to -install it setuid root (which actually won't work anyway), then -someone needs to have gained root access in order to run it like this. -If they already have root access, Ardour is the least of your -problems. So relax. We'll use capabilities once Linux kernels start -arriving with them enabled, though this won't help too much with -security, since the relevant capabilities would still allow a wiley -cracker to do anything at all. - -Alternatively, you can choose to run Ardour without RT scheduling, and -then there's no concern at all. It just won't be useful in low latency -situations, which are desirable in most studio environments. Note that -this is not so important if you have audio hardware that is capable of -doing "hardware monitoring" - in this case, a lack of low latency will -simply make response to Ardour's UI controls a little sluggish, but -monitoring during capture will be excellent. - -**** HARDWARE COMPATIBILITY ***************************************** - -Ardour uses JACK for all its audio I/O, thus providing seamless -connections to both audio hardware and other applications. Its really -not the right place to discuss JACK, but in case you are wondering: - -Although JACK uses the ALSA 0.9.0 API, it exercises this API in a way -that no other application to date has done, and it also tries to use -certain hardware features that again, no other existing applications -use. As a result, although complete portability to all ALSA supported -h/w is an eventual and very achievable goal, there may be issues -surrounding h/w compatibility. Please remember that my primary goal -with JACK is to build a professional audio system, and with Ardour, a -professional digital audio workstation. If they happen to be useful -for people with 2/4 channel cards, then great, but it's not my own -primary focus. - -One other important issue is that your audio interface must support -full duplex i/o with the same sample format for both capture and -playback. This means, for example, that the SoundBlaster AWE cannot -be used with JACK in full duplex mode - it only supports full duplex -i/o if one of the two directions (capture or playback) is 8 bit and -the other is 16. Very few cards have this kind of limitation, and if -they do, they typically are not suitable for use with applications -like JACK or Ardour for other reasons. - -To date, JACK has been run with: - - RME Hammerfall (Digi9652) (26 channels in, 26 channels out) - RME Hammerfall DSP (hdsp) (26 channels in, 26 channels out) - RME Hammerfall Light (Digi9636) (18 channels in, 18 channels out) - Midiman Delta series (ice1712 chipset) (12 channels in, 10 channels out) - - Various consumer grade audio interfaces, typically with 2 channels - in, 2/4 channels out, including: - - Hoontech 4Dwave-NX (Trident chipset) - Ensoniq 5880 - Soundblaster 32 - Soundblaster 64 - Creative SBLive64 - -and many more. - -So, basically, it appears to work for just about all ALSA supported -cards, which is the goal. - -********************************************************************** - -BUG REPORTING -------------- - -Bugs should be reported to http://ardour.org/mantis/ . They are more -likely to be remembered and dealt with there. Please check the existing bugs -to make sure it has not already been reported and/or fixed in CVS. - -COMPILING ARDOUR ----------------- -Please see the file "BUILD". - -RUNNING ARDOUR --------------- - -NOTE: You must have a running JACK server before starting Ardour. - ----------------------------------------------------------- - -Typing "ardour" will hopefully have some effect. "ardour --help" lists -available options. diff --git a/libs/surfaces/control_protocol/basic_ui.cc b/libs/surfaces/control_protocol/basic_ui.cc index 4519eb2781..8cf157c26c 100644 --- a/libs/surfaces/control_protocol/basic_ui.cc +++ b/libs/surfaces/control_protocol/basic_ui.cc @@ -19,6 +19,8 @@ $Id$ */ +#include + #include #include @@ -42,6 +44,12 @@ BasicUI::~BasicUI () } +void +BasicUI::register_thread (std::string name) +{ + PBD::ThreadCreated (pthread_self(), name); +} + void BasicUI::loop_toggle () { diff --git a/libs/surfaces/control_protocol/basic_ui.h b/libs/surfaces/control_protocol/basic_ui.h index 2db19685b1..81f2727264 100644 --- a/libs/surfaces/control_protocol/basic_ui.h +++ b/libs/surfaces/control_protocol/basic_ui.h @@ -22,6 +22,8 @@ #ifndef __ardour_basic_ui_h__ #define __ardour_basic_ui_h__ +#include + #include namespace ARDOUR { @@ -35,6 +37,8 @@ class BasicUI { void add_marker (); + void register_thread (std::string name); + /* transport control */ void loop_toggle ();