xiphmont: (Default)

Every now and then I'm reminded I'm not the last emi2|6 or 6|2m user left in the world-- apparently Debian just recently made some of the changes that broke the eMagic drivers on other distros years ago and I've been getting mail about it again.

Background: The eMagic emi2|6 and 6|2m firmware loaders shipped with the Linux kernel have been broken for many years. Different distros have had them on life support with an inconsistent array of minor patches, but they've got a couple problems across the lot: races in the loader, an incorrect memory target, deadlocking all of USB with synchronous firmware requests in probe(), and the fact that the bitstream.fw file being shipped for the 6|2m is the wrong file. Apparently, someone accidentally substituted the 2|6 version of the file in a code cleanup years ago, and so even if you get the 6|2m loader to work, it crashes the device because it uploads the wrong thing.

Oh, and Linux is apparently shipping a buggy, early version of the firmware without 96kHz support. Even if you don't care about 96kHz for audio production, and you probably shouldn't, the extra frequency range makes these guys a lot more useful as software oscilloscopes.

I've maintained a working version of the driver with updated firmware for the past several years, but getting it into the official kernel always stalled on 'wait, do you have permission from eMagic to use this firmware?' Unfortunately a) Apple bought eMagic and discontinued all their hardware products more than a decade ago, b) to my knowledge, no one ever had explicit permission to use the firmware currently being shipped either. I have no real interest in having a battle over firmware licensing, so my fixes continue to be my own. If Apple turns out to care, I'll pull them down, but I doubt that will happen. I don't think Apple remembers this device even exists. Seriously, they're Bondi Blue. That's soooo late-90's.

Anyway, here's my latest, updated, out-of-kernel firmware loader with the last firmware release form eMagic. It works properly on 2.6.x and 3.x.x kernels for both the emi2|6 and emi6|2m. It replaces the old firmware and two kernel modules with new firmware and a single unified firmware loader module name emi.ko. All new! Such shiny. Wow.

If you have kernel module build dependencies installed, it should be as easy as untarring as root, make, and make install. I also included a 'make remove-old' target to clean out the old driver and avoid any conflicts. It just removes the old modules and firmware files; obviously that might make a packaging system a little pissy (and you'd probably have to re-run it on each kernel update).

tl;dr, get the driver here: http://people.xiph.org/~xiphmont/emagic/

xiphmont: (Default)

...and the final 1.1 release lands!

The release also features an extensive demo page that describes and shows off the improvements in 1.1 in detail. (The page will look familiar to those who have been following over the past few months; it's an updated and expanded version of the demo for last July's beta test release.)

xiphmont: (Default)

Opus 1.1 just hit release candidate; pending any last minute bug discoveries or showstoppers, this will become the final 1.1 release.

The release candidate includes two major improvements over the previous 1.1 beta.

We've further improved surround encoding quality and tuning of both surround and stereo at lower bitrates. As an example, full 48kHz 5.1 surround is now tested and tuned down to 45kpbs (it's nowhere near audiophile quality at that rate, but it is surprisingly good).

In addition, we also landed additional encode/decode optimizations for all CPU types, but especially ARM which now includes NEON encoding optimizations.

And of course, we hopefully cleared the 1.1-beta buglist :-)

xiphmont: (Default)

Please note: This is not a statement on behalf of Xiph.Org or Mozilla. I speak here for myself, my team, and other developers who share my views on an open web.

If you haven't seen today's announcements from Cisco and Mozilla regarding H.264, you'll want to read them before continuing.

Let's state the obvious with respect to VP8 vs H.264: We lost, and we're admitting defeat. Cisco is providing a path for orderly retreat that leaves supporters of an open web in a strong enough position to face the next battle, so we're taking it.

By endorsing Cisco's plan, there's no getting around the fact that we've caved on our principles. That said, principles can't replace being in a practical position to make a difference in the future. With Cisco making H.264 available at no cost, holding out against H.264 in WebRTC makes even less sense than holding out after Google shipped H.264 in the video tag. At least under these terms, H.264 will be available at no cost to Mozilla and to any other piece of software that uses the downloadable plugin.

Cisco's license hack is obvious enough if you have the money: There's a yearly cap on total payments for any given licensed H.264 product. This year the cap is $6.5M. Any company that pays the cap each year can distribute as many copies as they want. There are still terms and restrictions on how the distribution gets done, but Cisco will be handling that (and only Cisco will be allowed to build and distribute these copies without a separate license).

Once you or your applications download the prebuilt codec blob from Cisco, you're allowed to use that specific blob for anything you want so long as you don't modify it or give it to anyone else. H.264 codecs for everyone! Cisco has committed to these blobs being available for just about every platform and architecture you can think of. "IBM S/360? Yes, please!"

This arrangement has obvious short-term benefits. Open source projects get licensed (if partial and restricted) access to H.264, and users don't feel like they're being held hostage in the ongoing battle between the open web and closed codecs. Firefox and other projects can install H.264 support (via Cisco), which is a big deal.

That said, today's arrangement is at best a stopgap, and it doesn't change much on the ground. How many people don't already have H.264 codecs on their machines, legit or otherwise? Enthusiasts and professionals alike have long paid little attention to licensing. Even most businesses today don't know and don't care if the codecs they use are properly licensed[1]. The entire codec market has been operating under a kind of 'Don't Ask, Don't Tell' policy for the past 15 years and I doubt the MPEG LA minds. It's helped H.264 become ubiquitous, and the LA can still enforce the brass tacks of the license when it's to their competitive advantage (or rather, anti-competitive advantage; they're a legally protected monopoly after all).

The mere presence of a negotiated license divides the Web into camps of differing privilege. Today's agreement is actually a good example; x264 (and every other open source implementation of an encumbered codec) are cut out. They're not included in this agreement, and there's no way they could be. As it is, giving away just this single, officially-blessed H.264 blob is going to cost Cisco $65M over the next decade[2]. Is it any wonder video is struggling to become a first-class feature of the Web? Licensing caused this problem, and more licensing is not a solution.

The giveaway also solves nothing long-term. H.264 is already considered 'on the way out' by MPEG, and today's announcement doesn't address any licensing issues surrounding the next generation of video codecs. We've merely kicked the can down the road and set a dangerous precedent for next time around. And there will be a next time around.

So, we're focusing on being ready.

Fully free and open codecs are in a better position today than before Google opened VP8 in 2010. Last year we completed standardization of Opus, our popular state-of-the-art audio codec (which also happens to be the best audio codec in the world at the moment). Now, Xiph.Org and Mozilla are building Daala, a next-generation solution for video.

Like Opus, Daala is a novel approach to codec design. It aims not to be competitive, but to win outright. Also like Opus, it will carry no royalties and no usage restrictions; anyone will be permitted to use the Daala codec for anything without securing a license, just like the Web itself and every other core technology on the Internet.

That's a real solution that can make everyone happy.

I can't resist a little codec fantasy football.

MPEG HEVC licensing isn't set yet. It will be interesting to watch the negotiations if Cisco's H.264 giveaway plan is wildly successful. In the future, could nearly every legal copy of HEVC come as a binary blob from one Internet source under one cap? I doubt that possibility is something the MPEG LA has considered, and they may consider it now that someone is actually trying to pull it off with H.264. Perhaps in five years, even cameras and televisions will download a software codec to avoid paying monopoly rents. Sillier things have happened given sufficient profit motive.

Or maybe they'll build in a free, legally uncomplicated copy of Daala instead. Dare to dream.

—Monty Montgomery <monty@xiph.org> and others
October 30, 2013


xiphmont: (Default)

Xiph and Mozilla's Greg Maxwell (or as Dave has been teasing, 'Professor Max') gave a good thorough presentation on Opus and progress being made on Daala at the 2013 GStreamer conference in Edinburgh on Wednesday. Unlike many of our presentations, we were more careful to get complete video for this one.

If you've been a fan of the Daala demo updates, his talk touches on some of the topics of upcoming demos, specifically PVQ, the range coder, and motion compensation. Obviously, I'll be going into more detail on those in the actual demo pages.

xiphmont: (Default)

Another new demo, another new technique specific to Daala: frequency domain prediction of the chroma planes from the luma plane!

Predicting the chroma planes from the luma plane isn't a brand-new idea. Still, we're both the only codec to actually be deploying it, and we're doing it entirely in the frequency domain (which is novel).

Read on!

xiphmont: (Default)

I've just posted part 3 in my demo series introducing the Daala video codec. This one is kind of a long one, mainly because I think it's one of the only really detailed presentations of a technique Jean-Marc Valin of Xiph invented and first introduced in the Opus audio codec: 'TF' aka Time/Frequency resolution switching.

Even better... while I was documenting TF for posterity, I spotted a possible improvement. So, I've tossed in documentation of a brand new technique as well!

xiphmont: (Default)

Now up, part two of the introduction I'm writing for Xiph's upcoming video codec Daala. The fact that we're using lapped transforms means we've had to apply a little cleverness to intra prediction, and so we've opted to do it in the frequency domain...

xiphmont: (Default)

I've made another demo page, this one in celebration of the Opus 1.1 beta release today...

"Opus marches onward toward its manifest destiny with today's beta of the upcoming 1.1 release. This will be the first major update to libopus since standardization as RFC 6716 in 2012, and includes improvements to performance, encoding quality, and the library APIs. Here's a few of the upgrades that Opus users and implementors will care about the most."

Cheers!

xiphmont: (Default)

Xiph.Org has been working on Daala, a new video codec for some time now, though Opus work had overshadowed it until just recently. With Opus finalized and much of the mop-up work well in hand, Daala development has taken center stage.

I've started work on 'demo' pages for Daala, just like I've done demos of other Xiph development projects. Daala aims to be rather different from other video codecs (and it's the first from-scratch design attempt in a while), so the first few demo pages are going to be mostly concerned with what's new and different in Daala.

I've finished the first 'demo' page (about Daala's lapped transforms), so if you're interested in video coding technology, go have a look!

xiphmont: (Default)

Oh. Oh my. After a decade of the MPEG LA saying they were coming to destroy the FOSS codec movement, with none other than the late Steve Jobs himself chiming in, today the Licensing Authority announced what we already knew.

They got nothing. There will be no Theora patent pool. There will be no VP8 patent pool. There will be no VPnext patent pool.

We knew that of course, we always did. It's just that I never, in a million years, expected them to put it in writing and walk away. The wording suggests Google paid some money to grease this along, and the agreement wording is interesting [and instructive] but make no mistake: Google won. Full stop.

This is not an unconditional win for FOSS, of course, the LA narrowed the scope of the agreement as much as they could in return for agreeing to stop being a pissy, anti-competetive brat. But this is still huge. We can work with this.

For at least the immediate future, I shall have to think some uncharacteristically nice things about the MPEG LA.*

And now... Discuss!

*Apologies to Rep. Barney Frank

xiphmont: (Default)

We did it. We finally finished Xiph's second big video: Episode 2: Digital Show & Tell

"The second video from Xiph.Org explores multiple facets of digital audio signals and how they really behave in the real world. Sampling, quantization, dither, band-limiting, and vintage bench equipment all in one video!" Go see it!

xiphmont: (Default)

(by Monty and the Xiph.Org community)

Articles last month revealed that musician Neil Young and Apple's Steve Jobs discussed offering digital music downloads of 'uncompromised studio quality'. Much of the press and user commentary was particularly enthusiastic about the prospect of uncompressed 24 bit 192kHz downloads. 24/192 featured prominently in my own conversations with Mr. Young's group several months ago.

Unfortunately, there is no point to distributing music in 24-bit/192kHz format. Its playback fidelity is slightly inferior to 16/44.1 or 16/48, and it takes up 6 times the space.

If you just said 'Whaa?', you may want to read the whole article.

It's fairly long... but hearing, perception and fidelity are complicated topics. Shysters and charlatans exploit that nuance (and misunderstanding) to bilk unsuspecting consumers of their money, all the while convincing them they're paying for 'quality'.

Anyway, happy reading and comments welcome!

xiphmont: (Default)

Camilla forwarded a necessary tip for installing the XiphQT components on a 64 bit Mac OS X so that it works with iTunes. This is a reasonably well known tip, but it wasn't in our FAQ or installation instructions (well it is now as of about ten minutes ago) so I'm passing it along now too...

I upgraded to Lion, and my ogg files stopped being able to play in iTunes (silently). Here's how to make it go:
  1. "show in finder" your iTunes binary (either navigate to the Applications folder, or right/control click on it in the dock, and choose "show in finder")
  2. right/control click on iTunes in the finder, and select "Get Info"
  3. Under General, check the box marked "Open in 32-bit mode"

You should put the above on something linked from: http://www.xiph.org/quicktime/download.html I paraphrased it from roaringapps.com.

If XiphQT can be rebuilt in 64 bit mode, and that shipped that way to Lion users, that would also be a good solution.

That last comment is actually a bit of an embarrassment for us at the moment; neither the XiphQT builds nor code have been updated since 2009 or so, despite multiple releases, fundamental improvements and new features in the Xiph codecs since. There are actually more recent beta builds of updated Mac OS X and Win32 XiphQT components than never got bumped to the official XiphQT download page, but even these builds are from mid 2009.

We don't have any high-powered Mac OS hackers in the core Xiph group at the moment. I have some relatively insignificant amount of experience coding for Mac OS X and Quicktime, but I've been hoping for a volunteer with more chops. Any takers?

xiphmont: (Default)

Turns out I missed blogging about the latest Ghost update... back in November...

Ghost Demo4 is up on the demo list showing the sinusoidal extractor doing some very early sinusoidal tracking frame to frame, and a very early example of the analysis performing real sinusoidal/non-sinusoidal audio splitting. Pictures and interactive listening, oh my!

It looks like I'll be putting a month or two into transOgg before getting back to Ghost work (and demo 5). The work that went into demo4 raised a number of questions I'm not sure how to approach answering yet, so I'm going to let that percolate for a bit.

xiphmont: (Default)

I made a quick change to the Xiph.Org front page that a few people have suggested now over the past few years.

The top few blog posts aggregated by Planet Xiph now appear as a five-item teaser list near the top of the Xiph.Org home page. The idea is both to get some more live content on the front page as well as to draw more attention to both the Planet and our developer community.

Comments and feedback welcome!

xiphmont: (Default)

Quite a few otherwise interested people may not have heard that the FTC (Federal Trade Commission) is holding a panel and workshop next week concerning how patent trolls are abusing standards body processes. This is our field, and we didn't find out about it until end of last week.

Regardless, Xiph.Org has assembled an official comment document, and will be represented in person by at least Dr. Tim Terriberry and possibly a few other core members (I won't be there).

If you're interested in software patents, some of the US Government's thinking on the issue, and participating in the process, have a look at the above two links. Also, feel free to distribute our comments far and wide. It's somewhat more gripping than the usual, dry "Percy Q. Business Leader Advises the Federal Goverment".

xiphmont: (Default)

I'd mentioned in the previous update that we're (Xiph is) using a chirp estimation algorithm that we published back in 2007, and that the original paper has precious little space to devote to describing in detail how the algorithm actually performed. One of the upshots of not having done extensive characterization tests of our own algorithm was that it has already surprised me a few times this year (in both good and bad ways).

Therefore, Ghost Update 20110604 concerns itself with describing and graphing algorithm behavior in mind-numbing detail.

Death! By! Graphs!

xiphmont: (Default)

Not actually last month, but pretty close at this point.

I never publically released the my previous Ghost update delivered internally to Red Hat at the beginning of the month because I hadn't finished some of the diagrams I wanted to do for the last section on chirp coding. Well, the diagrams are done! Here's the latest Ghost demo update, just in time for the next one to almost be due!

xiphmont: (Default)

In case folks have missed it (or worse, read about about it on Ars Technica)...

The WebM folks have finally finished up their work on the WebM Community Cross-License project and announced the license launch. This is a FOSS defensive license/pool similar to what a couple other groups are trying out (and similar to the defensive patent license that Xiph is already using for our parts of Opus within the IETF).

The basic idea of the cross-license is:

"Everyone is free to use any known or unknown WebM patents. Unless you sue over patents related to WebM. In that case, we all agree to yank your license."

In short, it's sort of a NATO for FOSS patents; a free license with an agreed-upon mutual defense clause that tries to enforce everyone playing nice. This strategy is not a new idea, but it's interesting that several different FOSS groups, Xiph and WebM included, are finally trying the idea for real in practice.

Profile

xiphmont: (Default)
xiphmont

Syndicate

RSS Atom

Most Popular Tags