MediaWiki API result

This is the HTML representation of the JSON format. HTML is good for debugging, but is unsuitable for application use.

Specify the format parameter to change the output format. To see the non-HTML representation of the JSON format, set format=json.

See the complete documentation, or the API help for more information.

{
    "warnings": {
        "query": {
            "*": "Formatting of continuation data has changed. To receive raw query-continue data, use the 'rawcontinue' parameter. To silence this warning, pass an empty string for 'continue' in the initial query."
        }
    },
    "batchcomplete": "",
    "continue": {
        "gapcontinue": "Reference_manual/pt-br",
        "continue": "gapcontinue||"
    },
    "query": {
        "pages": {
            "108": {
                "pageid": 108,
                "ns": 0,
                "title": "Realtime kernel info",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "In order to get good performance with audio applications on linux, the system/kernel should be tuned for better realtime performance.  This is especially true when using ALSA (or JACK with ALSA) sound devices.  The Audioscience sound cards have high quality hardware design and large buffers that make realtime tunning less critical.\n\nThere are several ways to get better performance from a linux kernel.  They include:\n* [[rtlimits-enabled pam]]\n* [[realtime-lsm (older approach)]]\n\n\n\nThese are links to various resources with more information on realtime performance tunning with linux:\n* [http://lowlatency.linuxaudio.org/ linux low latency audio information]\n* [http://kerneltrap.org/node/11752 article on Ingo Molnar's real time kernel patch]\n* [http://rt.wiki.kernel.org/index.php/Main_Page Linux Realtime Wiki]\n\n\n==When do you need Realtime Kernel patches applied?==\n\nThe general consensus is that a default OS can keep up with the data streaming demands of Rivenedell, however it depends on a number of factors, the primary ones being the sound architecture in use and (sometimes) how critical low latency performance is.   If you're running an ASI card, then standard default kernels should be fine -- the cards have huge buffers, and the internal audio routing is done in the card's DSP core (which is hard realtime by definition). \n\nWhere it can get dicier is if you're running with ALSA or JACK.  If all you're doing is playing and recording, then standard kernels with default settings should work fine.  If however you're running a 'virtual switcher' by means of a Local Audio device (where i/o latency becomes important), you may well end up reducing the buffer sizes (either in JACK or in the [ALSA] section in rd.conf(5); in such cases, a realtime kernel may well be necessary in order to avoid xruns."
                    }
                ]
            },
            "85": {
                "pageid": 85,
                "ns": 0,
                "title": "Recording airchecks with gpi from microphone switch",
                "revisions": [
                    {
                        "contentformat": "text/x-wiki",
                        "contentmodel": "wikitext",
                        "*": "=RDCatch Method=\n== Description ==\nThis setup is designed to record airchecks of air talent for the purpose of talent revue by program directors or consultants. Long form air check recordings can simply use rdcatch however all we want to do is record when the announcer is live on the air. ie: When the microphone is turned on. Problem is we need to be able to archive many cuts until they are needed. Here is my Rivendell solution for this task.\n\nThis could be done over a network between a couple of workstations by embedding rml commands into a script with rmlsend, but for our purposes here this is all done on a single Rivendell workstation.\n\n== Requirements ==\nFirst we must have a gpi source, any of the Rivendell supported hardware can be used as long as it supports both on and off transitions. We are going to take a ttl or contact closure from the on air console mic channel switch available on most all broadcast consoles connect it to our gpi device and with the help of a few simple rml commands and a short script get the job done.\n\n== Record Start Macro ==\nCreate a macro cart in RDLibrary and insert the following rml command in it.\n\n RS 1 999999 001 300000!\n\nThis macro will '''RS''' (record start) '''1''' (deck 1) '''999999''' (cart number) '''001''' (cut number) for '''300000''' ms\n\nThis command will start a recording on record deck 1 and record for 300000 ms or five minutes or until we give it a stop command. For our stations format a five minute window is more than enough to capture the disk jockey's break, your mileage may vary. So, adjust this to fit your needs.\n\nWe assign this cart to the on transition gpi closure in rdadmin so that when the mic channel is turned on we begin recording. You can do this in RDAdmin>Manage Hosts> '''select the host''' >Edit>Switchers GPIO> '''select your gpio switcher''' >Edit>Configure GPIs> '''select your gpi''' >Edit>ON Transition-Cart Number\n\n== Record Stop Macro ==\nNext step is what to do when the microphone is turned off. Create a second macro cart in RDLibrary and insert the following commands on three lines.\n\n RR 1!                         (stop recording on deck 1)\n SP 1000!                      (sleep for one second - this is to give time for the wav file to be closed)\n RN /home/rduser/convert.sh!   (run our script to convert and move the file)\n'''Note:''' This tutorial assumes your linux user is rduser. Change as needed.\n\nAssign to this cart to the off transition for the gpi in rdadmin. You can do this in RDAdmin>Manage Hosts> '''select the host''' >Edit>Switchers GPIO> '''select your gpio switcher''' >Edit>Configure GPIs> '''select your gpi''' >Edit>OFF Transition-Cart Number\n\n== The Script ==\nNow - what goes in the script convert.sh\n\n #!/bin /bash\n \n dt=$(date +\"%b%d%H%M\")     # this is to set a variable dt to our time stamp pattern monthdayhourminute.\n lame -V 8 /var/snd/999999_001.wav /home/rduser/airchecks/$dt.mp3\n\nSave this as /home/rduser/convert.sh and make it executable.\n\nThe lame command uses a variable bit rate (-V) with 1-9 being the relative quality you want to convert our recording to a mp3 file with the file name set by the variable $dt to something like Sept220750.mp3 and saves it in a aircheck directory.\n\nYou now will end up with a mp3 recording of whatever you feed deck one (we assume program signal) for every time someone turns on the control room mic.\n\n== Summary ==\nOn transition of gpi starts macro cart one to begin recording\nOff transition of gpi runs macro cart to stop recording and run a script to convert and save file.\n\n\n== Optional ==\nLast step is to have a apache web server with autoconf enabled. We then simply create a symbolic link of our \"airchecks directory\" and place it in /srv/www/htdocs\nopening this web server with http://yourserver/airchecks will give you a index of all the cuts and they can either be played directly or downloaded.\n\n\nThat's it another task accomplished with Rivendell. I hope this will help others not only solve this particular task but open eyes to just how creative you can get\nwith the combination of Rivendell and Linux.\nRML's can set you free!\n\n\n=JACK Method=\n\nWhen trying the above method my rcatchd process loved to segfault without much reason, so I whipped up a method using jack_capture. This only works if you use JACK.\n\nYou just have your GPI On and GPI Off carts run a script - mics_on.sh, mics_off.sh in our case. To allow us to cleanly background and end the jack_capture process we have to use screen.\n\nIn mics_on.sh we have this:\n\n #!/bin/bash\n dt=$(date +\"%Y-%m-%d-%H-%M\")\n # Start recording, binding to the system's capture inputs, which we assume have programme content on them.\n screen -dmS $dt jack_capture --format ogg --disable-console --port system:capture* /home/insanity/airchecks/$dt.ogg\n screen -list | grep $dt | cut -f1 -d'.' | sed 's/\\W//g' > /home/insanity/rdscripts/capture.pid # Get the PID and put it in a file\n /home/insanity/rdscripts/redisset.py mics_on 1 # This sets a flag in our station statekeeping DB\n ssh insanity@hendrix md_puts \"MICROPHONES\\ LIVE\" # This displays a message in the studio on the clock via another computer\n\nThe mics_off.sh script is simple:\n\n #!/bin/bash\n kill `cat /home/insanity/rdscripts/capture.pid` # Kill the recording\n /home/insanity/rdscripts/redisset.py mics_on 0 # Update the flag in statekeeping DB\n\nYou can also tell jack_capture to record to .mp3 if you want, or .wav so you can transcode into whatever format you desire.\n\n== Timemachine/Loquacious variant ==\n\nAnother variant uses the Timemachine program for JACK which lets you capture audio before you start actually recording. [https://gist.github.com/2725333 This script], loquaciousd.py, can automatically start and control Timemachine's command line interface to manage recording of airchecks, and publishes new recordings to a Redis list for further processing.\n\n=LAB Method=\n\n'''Q:''' Currently I'm using rdcatch to record jocks shows and then scoping them down. Does anyone know of a linux based recorder that I could use with a gpi from the mic switch to record air checks? \n\n'''A:''' Doesn't LAB do this?\nIt does indeed. LAB is referring to the '''Linux Audio Backstop''', an application I wrote back in the late nineties that does pretty much precisely what you are looking for.  OSS based, but still works fine under ALSA with OSS emulation.  Current source can be found at:\n\nhttp://www.rivendellaudio.org/ftpdocs/lab/lab-2.1.6.tar.gz\n\nFrederick F. Gleason, Jr.\n\nChief Developer\n\nParavel Systems"
                    }
                ]
            }
        }
    }
}