Revision Log
Last Updated: 30/12/2015
Improved readability, that is all. Courtesy of writing a new slab of text.
Less monospace after all these years, more sans.
Quicknote: 04/10/2016, 06/06/2017, 19/07/2017
Looking forward to updating things in September '16 November '16 August '17? as a couple of things have changed and improved.
I have a list of notes and am checking it twice. Meanwhile Opus 1.2-Alpha
Added my ToC generator as tested on my other tome.
Meanwhile Meanwhile:
"Are you using the Opus codec?" - "Yes"
Shoutout to Cleanfeed, a new project by the chap who made xwax.
Revision Entry: 15/12/2015
Opus has been updated to 1.1.1.
Meanwhile I haven't plugged Daala yet so go check out the "Opus" for Video.
TL;DR; Everything is great.
Meanwhile, don't expect working song metadata till icecast 2.5 or 2.6.
Other then that, tiny clean ups and this slab of text still appears
to check out pretty decently overall since it's inception. To anyone reading this,
a good winter solstice and yuletide is once again implied.
Google Bait:
Opus codec streaming to icecast with MPD as source client RFC 6716
This information is by no means complete and it's very likely that
way too many assumptions have been made as to the succesful conclusion
of this endeavour on a case by case basis.
This is a stopgap measure until Opus has seen more widespread adoption.
TL;DR; It worked for me, maybe it will for you. HTH.
*NIX based operating system.
Music Player Daemon a.k.a MPD.
(Any media player with STDOUT support should do in theory.)
Compilers / Linkers / etc. aka. build essentials.
A fetish for audio codecs.
The end result, if achieved, is most functional and full of hack value. On MacOS X : Encoding / Broadcasting / Playback - Succesful On Fedora : Encoding / Broadcasting / Playback - Succesful On LinuxMint : Encoding / Broadcasting / Playback - Succesful VLC 2.0.4+ : Playback - Succesful Foobar 1.2.9+ : Playback - Succesful On Firefox 15+ : Built-in supported playback - Succesful (Update or Disable noscript as it seems to interfere with <Audio>.) On Opera 12.15 : Built-in supported playback - Succesful On Chrome 26+ : Built-in supported playback - If you turn it on. On Chrome 29+ : Build-in supported playback - On by default. On Chromium 25+: Built-in supported playback - If you turn it on. On Android : A fellow scientist recommends VLC on Android On iPhone : Some Opus support exists, but local playback only... On WinPhone : No idea, likely a lost cause anyway.
SoX is readily available from package managers.
Alternatively anything that accepts STDIN and spits out sound.
For everything else it's recommended to compile from latest source.
Don't forget to enable your newly created output in MPD.
TL;DR; LET'S DOWNLOAD HALF THE INTERNET TO MAKE THIS WORK. IN THE TRIED AND TRUSTED OPEN SOURCE TRADITION!
Browsers are an evermoving landscape and sometimes kids can't make up their minds of which features they'd actually want to adopt or activate. It is therefore a good thing there are settings panels and flags that we can tinker with for our amusement. I leave these here for reference, if progress progresses as progress does this section should become irrelevant in the near future. The information below assumes you follow the practice of regularly updating your browser.
Has been doing Opus playback fine for quite some time unless you happen
to be using JACK as your audio backend on Linux. Which you should,
because being able to tie in any application output to any other
application input is made of tar.xz. Shoutout to JACK Rack!
However the Mozilla kids have been busy with getting a new media backend
up and running which appears to use a sample format that is not
compatible with JACK at this time.
The solution is trivial and requires a single setting to be added to your
about:config department. For as long as it may last.
Update: (07/12/2012)
Firefox 25+ appears to have killed the old backend so this doesn't work
anymore. Yet this is kept for historical purposes.
Quoting here from this Mozilla bugreport:
--
Thanks. Setting "media.use_cubeb" to false switches back to the old
audio backend. Please don't add that to the wiki, it only exists for
troubleshooting purposes and will be removed in the near future.
Since the old backend works and the new one doesn't, there are a couple
more things worth testing.
--
Good thing this is not a wiki, also you have been warned.
Update: (05/07/2014)
Relevant to a niche audience, Chrome appears to have become a well
mannered citizen on Linux and targets Pulseaudio natively.
Previously while running a JACK setup the Flash plugin and HTML5 audio
would summon a raw ALSA output this is no longer the case and the
Pulaseaudio JACK Sink happily obliges.
Update: (07/12/2012)
Now comes with Opus out of the box.
Yet this is kept for historical purposes.
You have two option to get Opus to work here.
Go to chrome://flags and look for
"Enable Opus playback in <video> elements." and hit Enable.
Then scroll down and hit the "Relaunch Now" button.
Adjust your start script, shortcut, whatever and append
"--enable-opus-playback" flag to the executable.
For more nerdery, an extensive list of Chromium Flags
FYI, Chromium is Chrome with alot less Google Chrome.
Opera 12.15 on Linux just works out of the box, albeit using PulseAudio.
But with the PulseAudio JACK Sink in place this poses no threat.
Party on you crazy Norwegians!
Safari and Internet Explorer will likely depend on how well WebRTC get's
pushed and how soon they both adopt the RFC specification.
Apple will likely resist harder as there's no hardware decode on iOS
devices for Opus. But given how impressive Rockbox is on media players
I doubt this will really be an issue unless they don't like battery life
being eaten away by a software decoder.
Android and Windows phone are in a similar boat however Can I use reports
that "Firefox for Android" should have playback support.
A fellow scientist has not yet confirmed this as to be true at present
but recommends "VLC on Android" for the time being, see up top.
Patents are not the issue here, willingness to be awesome is.
Unfortunately Lady Meta does not think Lord Icecast is a worthwhile suitor.
As it stands attempts to update metadata from within Icecast's admin panel
results in "Mountpoint will not accept URL updates". It turns out that at
this point in time Icecast does not support updating Opus stream meta
data in any form.
I'm currently using MPD's native Opus output to stream and with the exact
same output config stream Vorbis at the same time. The Vorbis stream
delivers meta data just fine where as the Opus stream does not.
I am not the only individual having come upon this issue see this
particular icecast mailing list post shedding a little light on the matter.
There is also Xiph ticket #2017 that makes mention of
"out of band Opus Metadata updates not allowed".
TL;DR; You must wait more till icecast 2.5 or even 2.6.
Let us hope the next Icecast point release may bring that which, perhaps
for many, brings this long awaited support.
Consider the following, if you have a fetish for being on the latest
and greatest like a fellow scientist has. The more traditional method
follows after this section but this should preferrably become the
right way of doing things.
A fellow scientist recommends the following for your .mpdconf
audio_output {
type "shout"
encoding "opus"
name "Opus shout stream"
host "127.0.0.1"
port "8000"
mount "mpd.opus"
password "PasswordHere"
bitrate "64000"
format "48000:16:2"
protocol "icecast2"
user "source"
}
Icecast may complain a little and metadata is still absent but
the method is confirmed to work.
The only downsides to this method:
- Requires GCC 4.7 for the MPD Opus code to compile.
- No way to control framesize and encoding modes.
- Hooking into latest Opus potentially requires effort.
We give thanks to a fellow scientist for this contribution.
Having recently moved to Fedora Linux for my day to day tasks I've come to appreciate the powers that a good package manager has to offer. While Homebrew and MacPorts are valiant efforts, most OSS material seems to just function better with less comedy where it is most at home. But I may be biased in this case.
Without futher ado, the essentials mix:
yum install libogg libogg-devel libvorbis libvorbis-devel libtheora libtheora-devel speex speex-devel libshout libshout-devel flac flac-devel
If you prefer the latest stable opus:
yum install opus opus-devel opus-tools
Else do some Shake 'n Bake.
To be able to grab the source for oggfwd:
yum install bzr bzr branch http://v2v.cc/~j/oggfwd cd oggfwd make; make install
Optionally, if console playback is important to you:
yum install sox
Alternatively, combine RPMfusion with VLC
yum install vlc vlc-plugin-jack
Build essentials:
yum install tar make gcc
A handsome scientist asked for Opus on his Linux Mint box, the following package names were translated to get going.
apt-get install oggfwd libogg0 libogg-dev libvorbis0a libvorbis-dev libtheora0 libtheora-dev speex libspeex1 libspeex-dev libshout3 libshout3-dev apt-get flac flac-dev (Assumptions are made here, do your homework.) apt-get install tar make gcc apt-get install libopus0 opus-tools apt-get install sox
Dependencies for compiling Icecast 2.4 Beta
apt-get install curl libcurl4-openssl-dev libxslt1.1 libxslt1-dev
Seriously, what is up with Ubuntu's weird package numbers and multiple
flavours of everything. On the upside, oggfwd is already in the tree.
Doing a Shake 'n Bake for Opus is highly recommended as Ubuntu / Mint
currently (08/08/2013) ships (old) libopus 1.0.1 and opus-tools 1.2-1.
Where as Fedora ships (latest stable) libopus 1.0.3 and opus-tools 0.1.7.
We give thanks to a handsome scientist for providing a shell to tinker on.
With that done grab a copy of Icecast 2.4 from the front page, do a Shake 'n Bake, then skip to Setup 'n Use.
./configure make make install beverage > /dev/mouth
It's highly recommended to follow this order to avoid dependency hell.
None of this appears to rely on anything exotic anyway...
But hell is still unpleasant, or at-least so the legend has it.
libogg libvorbis libflac #if you want FLAC transcoding support for opus-tools libtheora #icecast likes this libspeex #icecast likes this
libopus opus-tools
If opus-tools fails to find Opus headers and libs:
./configure \ --with-opus-includes=/usr/local/include/opus/ \ --with-opus-libraries=/usr/local/lib/
If opus-tools complains about pkgconfig:
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/:/lib/pkgconfig/
export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/:/lib64/pkgconfig/
If opus-tools complains about missing FLAC libraries and you don't require FLAC transcoding support.
./configure --without-flac
Don't forget to add other flags where appropriate.
libshout #oggfwd wants this icecast 2.4.0
bzr branch http://v2v.cc/~j/oggfwd cd oggfwd make; make install
SoX
audio_output {
type "fifo"
name "fifo"
path "/tmp/mpd.fifo"
format "44100:16:2"
}
PROTIP: Enable it after restarting MPD.
As Lord Monty and friends decree we must honour the correct MIME type as per RFC 5334. <mount> <mount-name>/mpd.opus</mount-name> <type>audio/ogg</type> <password>password</password> <max-listeners>5</max-listeners> <no-yp>1</no-yp> </mount> -- Alternatively: "audio/ogg; codecs=opus" Future Likely: "audio/opus"
If you've done a shake 'n bake and your package manager installed Opus
on your behalf you may want to force the use of your own Opus libs before
running any of the Opus related executables.
It's likely best to put this at the start of a shell script vs setting
it as a session global but this is all up to you.
export LD_LIBRARY_PATH=/usr/local/lib/
Expected result examples:
[user@host ~]$ opusenc --version opusenc opus-tools 0.1.8 (using libopus 1.1) <<< THIS! Copyright (C) 2008-2013 Xiph.Org Foundation
Not the expected result:
[user@host ~]$ opusenc --version opusenc opus-tools 0.1.8 (using libopus 1.0.3) <<< DO NOT WANT! Copyright (C) 2008-2013 Xiph.Org Foundation
opusenc /tmp/mpd.fifo --raw --raw-rate 44100 --bitrate 64 - | \ oggfwd localhost 8000 password /mpd.opus
TTY :: [-] 00:30:10.26 0.999x realtime, 63.03kbit/s
opusenc reads the fifo output from MPD and feeds
Opus encoded audio to STDOUT.
oggfwd takes the output via STDIN and feeds it to Icecast.
By default opusenc assumes 2 channels use "--raw-chan 1" for mono.
Make sure to adjust MPD to mono before flipping this switch.
PROTIP: man opusenc << #Seriously #LateNightReading #OPTIONS
Open the stream url in a browser / VLC / an awesome media player.
Or if you prefer the CLI approach:
curl http://localhost:8000/mpd.opus -s | \ opusdec --quiet - - | \ sox -t raw -r 44.1k -c 2 -e signed -b 16 - -d
TTY :: In:0.00% 00:01:39.47 [00:00:00.00] Out:4.39M [ -====|=====-]
curl 'streams' the audio data in from icecast.
opusdec decodes STDIN to STDOUT.
sox takes raw STDIN and provides PCM outputs to audio device.
"And thirdly, the code is more what you'd call 'guidelines' than actual rules." - Captain Barbossa
I don't have alot of bandwith:
opusenc --bitrate 48 --cvbr --framesize 60
Shut up I have Opus 1.1 and plenty upstream:
opusenc --vbr
The man page stipulates:
"Default is 64kbps per mono stream, 96kbps per coupled pair."
Which is a very conservative but solid guideline.
If you provide an input of 44.1khz / 16-bit / Stereo for most genres of
music 48kbit combined with a framesize of 60 will give an adequate output
that would be very friendly to streaming to EDGE / 2.5G connections.
Ideally a bitrate of 64kbit provides the most 'transparent' output and
will also be minimally destructive on genres that involves traditional
instruments. ie. Orchestral Music, Choirs, Guitar, etc.
As streaming music is not a 'real-time' affair upping the framesize to
60ms gives the best quality return. In un-scientific testing the lower
the framesize the more artefacting and flutter came into play.
In totally un-scientific testing CVBR just appears to sound best.
But as always feel free to experiment.
Fellow scientist adds: (17/09/2012)
There is a regression present in the release code which affects their
relative performances which one is best does wind up subjective to what
bitrate you are doing it at. Via #opus
A sonata for VBR in Opus 1.1: (07/12/2012)
I've been running opusenc near exclusively in VBR mode since the 1.1-beta
improvements and in general the bitrate tends to hover between
90 - 115Kbit.
If your music library is mostly FLAC it's gorgeous. If your music library
is mix mash of potato quality you get "exactly" the same potatoes
delivered where you listen to your Opus stream.
Based on un-scientific testing consider it very much an un-official
guideline that works out pretty well. This table reflects the initial
release of the Opus codec. It is assumed Opus 1.1 improves on it till
further time for testing has been found.
Testing was done with both lossy and lossless material with the main
goal of being as "compression transparent" as possible. As such the
bitrates labelled as "Ideal" work best when streaming lossless material.
"Perfect" should be interpreted as close to perfect as you can get in
this type of situation regardless of source.
96 kbit - 44.1 khz / 16-bit / Stereo - Perfect 64 kbit - 44.1 khz / 16-bit / Stereo - Ideal 48 kbit - 44.1 khz / 16-bit / Stereo - Adequate for most genres 32 kbit - 44.1 khz / 16-bit / Mono - Mono, but Ideal 56 kbit - 32.0 khz / 16-bit / Stereo - Perfect 48 kbit - 32.0 khz / 16-bit / Stereo - Ideal 32 kbit - 32.0 khz / 16-bit / Stereo - Adequate for most genres 28 kbit - 32.0 khz / 16-bit / Mono, but Perfect 24 kbit - 32.0 khz / 16-bit / Mono, but Ideal 24 vs 28 kbit mono does makes a very audible difference. 32 kbit - 22.05khz / 16-bit / Stereo - Ideal 24 kbit - 22.05khz / 16-bit / Stereo - Adequate for most genres 20 kbit - 22.05khz / 16-bit / Mono - Mono, but Ideal 16 kbit - 22.05khz / 16-bit / Mono - Mono, acceptable if you want to.
To see if curl is connecting remove -s.
To see opusdec output remove --quiet.
sox #SoX -r 44.1k #Samplerate, change to 11k, 22.05k, 32k or 96k for amusement. -c 2 #Channels, change to 1, 3 or 4 for amusement. -e signed #Don't change this. Seriously Bro. If you do, mind your volume. -b 16 #Change to 8 for half an ocean. 32 for double time. - #STDIN. -d #Default audio device.
Discover for yourself what all these numbers and things mean.
SoX + OpusDec averages 0.7% + 2.0% CPU time | 2.9MB + 728KB mem. OpusEnc averages 2.9% CPU time | 784KB mem. Chrome built-in Opus playback 2-3% CPU time. Firefox built-in Opus playback 23% CPU time...
audio_output {
type "fifo"
name "fifo"
path "/tmp/mpd.fifo"
format "8000:16:1"
}
opusenc /tmp/mpd.fifo --raw --raw-rate 8000 --raw-bits 16 --raw-chan 1 \ --cvbr --framesize 2.5 --bitrate 12 - | \ oggfwd localhost 8000 password /mpd.opus
With this the encoded output will turn into a vocoderized like mess
sounding like a monotone decepticon.
The assumption is that something happens to the stdin buffer that causes
opusenc to throw a wobbly. Since framesizes of 5 and 10 do not function
either with anything below 22.05Khz.
Feeding a normal pcm file into the encoder delivers as expected.
When uade123 is set to output on STDOUT it wants to go as fast as the
system can write which causes serious CPU spiking. The solution is hacky but effective.
PipeViewer a.k.a pv has an option that allows one to rate limit
and adjust buffer sizes.
Invoking:
uade123 --frequency=44100 -r -z ./* -c | pv -L 180634 -q
Will rate limit uade123 to writing 1 second of 44.1khz / 16-bit / Stereo into the pipe buffer per 'cycle'. The frequency flag is provided as uade123 seems to output 96khz if this is left out despite the man page saying 44.1khz is the default.
This one is straight out of the opusenc man page with a tiny change.
Assuming you are on Linux and like to use raw ALSA this will encode
and stream whatever is connected to line-in on your audio device.
arecord -f S16_LE -c2 -r48000 -twav - | opusenc --bitrate 64 - - | \ oggfwd localhost 8000 password /mpd.opus
"POSIX, STDIO, PIPES, JACK, FIFO.
By your powers combined, I am Captain Planet."
Having an stdin / stdout interface for JACK,
is such a thing even possible ?
Yes it is.
Could we use Netcat to pipe audio over a LAN,
is such a thing even possible ?
Yes it is.
If you like adventure and your power level is over 9000 this may
just be the sub-section for you ?
Yes it is.
So, you have JACK running and would like to feed whatever is playing
into an Opus stream but the application in question does not know
what Icecast is nor does it know what Opus is.
A dapper chap by the name of Robin Gareus has created a tool that
exposes an STDIN and STDOUT interface to JACK. Aptly called jack-stdio.
I trust you are familiar with doing a git clone and a make; make install,
as well as the naming conventions of JACK clients.
jack-stdout \ audacious-jack_15247_000:out_0 \ audacious-jack_15247_000:out_1 | \ opusenc --raw --raw-rate 44100 --vbr --bitrate 64 --framesize 60 - - | \ oggfwd localhost 8000 password /mpd.opus
In this instance we are connecting the output from Audcious to jack-stdio
and piping it through the now familiar process. As a bonus the stdio pipe
keeps running even without Audacious being connected or running which then
allows one to feed anything else back in via qjackctl if so desired.
Alternatively, launching as:
jack-stdout out_0 out_1
Will give an error message, but does expose a connectable port.
To be expanded on in the next revision, but effectively this will permit
the creation of an HE-AAC stream feed via Darkice from an MPD source.
Deliciously hacky and most functional for iOS devices.
You want a separate fifo output for this as MPD does not appreciate it
when multiple cat attempts happen on the same fifo.
It is assumed you've succesfully compiled Darkice in combination with
the aacplus library and the other dependencies.
/etc/darkice.cfg ---------------- [general] duration = 0 # duration of encoding, in seconds. 0 means forever bufferSecs = 2 # size of internal slip buffer, in seconds reconnect = yes # reconnect to the server(s) if disconnected [input] device = jack_auto # OSS DSP soundcard device for the audio input sampleRate = 44100 # sample rate in Hz. try 11025, 22050 or 44100 bitsPerSample = 16 # bits per sample. try 16 channel = 2 # channels. 1 = mono, 2 = stereo [icecast2-0] bitrateMode = cbr # average bit rate format = aacp # format of the stream: ogg vorbis bitrate = 48 # bitrate of the stream sent to the server server = 127.0.0.1 # host name of the server port = 8000 # port of the IceCast2 server, usually 8000 password = trololol # source password to the server mountPoint = mpd.aac # mount point of this stream on the server name = MPD # name of the stream description = MPD # description of the stream url = http://n.n # URL related to the stream genre = Everything # genre of the stream public = no # advertise this stream? ----------------
Option 1: Step 1 - Open a terminal, start darkice. Step 2 - Fire up qjackctl. Step 3 - Connect MPD output to Darkice input. Step 4 - ??? Step 5 - Done.
Option 2:
audio_output {
type "fifo"
name "fifo-darkice"
path "/tmp/mpd-di.fifo"
format "44100:16:2"
always_on "yes"
}
cat /tmp/mpd-di.fifo | \ sox -t raw -r 44.1k -c 2 -e signed -b 16 - -t raw -r 44.1k -c 2 -e signed -b 16 - | \ jack-stdin darkice-20478:left darkice-20478:right
20478 is the PID for Darkice, replace with appropriate PID.
The things you learn from running Linux as your primary desktop.
On your NAS, assuming it has no sound card and has IP 192.168.88.88:
jackd -R -d netone &
On your playback machine:
jack_netsource -H 192.168.88.88 -N NAS-MPD &
Option 1:
Start qjackctl, connect NAS-MPD to system.
Option 2:
jack_connect NAS-MPD:capture_1 system:playback_1 & jack_connect NAS-MPD:capture_2 system:playback_2 &
You may not hear MPD yet if you don't have a Jack output in MPD.
Add this to your .mpdconf:
audio_output {
type "jack"
name "MPD Jack"
}
Restart MPD and toggle your Jack output.
Enjoy your sample timing exact latency free audio pipe.
Note: This does push 550-600KB/sec of network traffic both ways as long
as jack_netsource is active.
But surely you are connected on ethernet right ?
These notes have been preceded by the above.
But this is still good fun! (07/12/2012)
You may ask yourself, Why ?
Because I can and because I run MPD on a NAS and whenever I switch
tracks with ncmpcpp I can't stand the latency that occurs when
listening through a streaming socket on my local LAN.
RAW! | 200K/sec | Latency 0.200ms | no encode cpu time.
MPD Host: -- cat /tmp/mpd.fifo | nc -k -l 3333
Playback Host: -- nc 192.168.88.88 3333 | sox -t raw -r 44.1k -c 2 -e signed -b 16 - -d or nc 192.168.88.88 3333 | aplay -i -f cd
Should you feel that 200KB/sec is too much, at the sacrifice of a little latency you can have FLAC pipes.
FLAC | Default (5) 100 - 120K/sec, Level 8 35 - 120K/sec | Latency about 0.75 sec. | CPU: Default - 1%, Level 8 - 3%
MPD Host: -- cat /tmp/mpd.fifo | \ flac --endian=little --channels=2 --sample-rate=44100 --bps=16 --sign=signed - | \ nc -k -l 3333
Playback Host: -- nc 192.168.88.88 3333 | \ pv -b | flac -d -F - | \ sox -t raw -r 44.1k -c 2 -e signed -b 16 - -d
We force the -F flag to avoid drama, and gaining the ability to resume
the playback stream vs having to restart netcat on both ends.
Without -F the FLAC decoder on the playback host will complain about
a corrupted stream.
*** Got error code 0:FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC
You might argue, one could add a FLAC output that's internal to MPD
to bypass alot of comedy. This, because I can in the spirit of science.
"Captain Monty, he's a hero, gonna take those patents down to zero!"
Tested an iPod Nano and iPod Video with the latest RockBox firmware, it works but playback performance is hit and miss in my case. Audio plays fine but controls take a long time to become responsive.
They don't wear coats.
Now that you've reached the end of this you shouldn't:
Follow me, Like me, Flattr me, Web 3.0 me.
Don't worry about me. Walk your own path with your head held high.
I only claim credit for reading man pages and adding some ketchup.
Nothing else.
Ergo, this document is licensed under the WTFPLv2.
Revision: 05/07/2014
Spend some google/duckduck-fu on the meta data issue. Hence a section on meta data with relevant links has been written. MPD has been updated to 0.18.11 Improved Opus file support and fixes. Icecast has been updated to 2.4.0 Which prompted testing and tinkering, as Ogg Opus support is official now. Opus has remained at 1.1 stable. Lord Monty and friends quiety continue to tinker in the Opus git repo. Trivia: By today's count 1971 people have perused this wall of text since it's original inception or there abouts.
Revision: 07/12/2013
Lord Monty and friends have released Opus 1.1 stable! With this also opus-tools 0.1.8. Relevant releases on the Opus HomePage. Sections have been updated to account for changes in opus-tools. Sections have been updated to reflect upon changes in Opus 1.1. Darkice notes have been expanded slightly. Network audio notes have been expanded slightly. Other corrections where appropriate. To anyone reading this, a good winter solstice and yuletide is implied.
Revision: 01/08/2013
Lord Monty and friends have released Opus 1.1 beta! Moved revision log to bottom of article. Added package info for Fedora. Added an index. Added "Captain Planet".
Revision: 21/06/2013
Added Browser information. Updated Firefox vs Jack information. MPD native Opus output option.
Revision: 21/01/2013
Added live audio input section. Minor fixes.
Revision: 29/10/2012 & 31/10/2012
Updated bitrate table, minor other fixes. Updated title and cleaned up.
Revision: 21/10/2012
VLC 2.0.4 has been released with Opus support. Average CPU time hovers around 3.8%, 46.8MB memory use. Achievement Unlocked: Opus stream playback in a more user-friendly and cross-platform way.
Initial Write up: 13/09/2012
//- Rev -// v2.0 // 1451626851