Is Rio required by the Ogg Vorbis license agreement to release the microcode they used to implement this protocol?
No, it's BSD-licensed.
It would be interesting to see what kind of optimizations they used such as special DSP instructions.
Actually we use the Tremor (integerised) Vorbis library almost completely stock -- it already came with optimisations for ARM. The only thing we've really had to take a hitting thing to is its memory allocation.
Yup. It works out about the same CPU usage as MP3 for normal (64-128) bitrates, but seems to scale with bitrate a lot more than MP3 does; by the time you get to 256Kbits/s, Vorbis is really hard work.
And, as long as I'm pestering a Rio employee, how is the ethernet support going to work?
You plug it in. If there's a DHCP server, it DHCPs, otherwise it autonets (UPnP-styley). Then it announces itself over SSDP multicast. If you're using Windows XP Home (or anything else that talks SSDP -- it's a completely open standard) an icon pops up in Network Neighbourhood. If you're using other sorts of Windows, an icon pops up in our own transfer software. Otherwise, you just point a web browser at it: there's a web server in it which will serve you a completely cross-platform Java applet to do your transfers.
I don't know whether we'll be actively helping the open-source community to implement the Ethernet protocol this time, but it certainly wouldn't be rocket science to reverse-engineer it.
Moore, unfortunately, wasn't in the battery business. CPU power for audio decoding is an extremely solved problem; plain old electrical power is not. Batteries have come on a lot in recent years, but if I were playing Civilisation right now I'd still be having people research batteries, not CPUs.
Unlike some previous Empeg/Rio products, the Karma does not run Linux. It runs Ecos, the popular open-source embedded OS. The firmware isn't designed to be modified like the Rio Central or car-player was.
(It always used to gall me slightly that the Rio Central and car-player were described as "hackable", with the implication that people customising them were outwitting us in some way, whereas in fact we put a good deal of effort into making them geek-customisable...)
They were adding restrictions to third party code which they have no right to do.
No. They were pointing out to those tempted to release MPlayer binaries, that while the MPlayer source is not a derived work of the GPL libraries (and so may be redistributed even though it has GPL-incompatible components), an MPlayer binary is a derived work and so may be used (the GPL nowhere prevents use) but not redistributed (GPL section 7).
Such was the MPlayer developers' interpretation of the GPL, and it was mine too: I've released sources into the public domain which linked against GPL libraries, on the same basis that the sources (which I release) are not a derived work even though any binaries (which I don't release) would be. However, this chap upthread seems to be saying I (and MPlayer) were wrong to do so. It does seem slightly cockeyed to me that the GPL works to prevent the release of public domain software, for instance to prevent the release of a Win32 version as public domain just because the Unix version links against Qt.
(Why is public-domain software GPL-incompatible? Because placing works in the public domain prohibits anyone, even the author, from claiming copyright on them; but the GPL requires that the author claim copyright.)
Apparently copy protected "intellectual property content" causes the digital output of the sound card to be shutoff.
It's not shut off, it's emitted with a copyright bit (part of the stream format) set. It's the "client" end (a DAT recorder, for instance) which does the prohibiting. This is all well-trodden ground to anyone who's messed with audio DAT drives or audio CD recorders: it prohibits you from recording copyright-asserted content from one to another digitally.
Collecting marketing data isn't much use when you can't actually sell a product to anyone because they've already downloaded bootleg copies of the studio master tapes.
Bits are not a product. Atoms are a product. Such people could be sold merchandising, or gig tickets. Those are the saleable products of the music industry. Music is not.
I can't remember which language syntantical structure is responsible, but you can't write an LALR parser for C without resorting to a bit of trickery.
foo = (bar)-7;
You can't tell if that's a cast of a negative integer to type "bar" or a subtraction of 7 from variable "bar" unless you know whether "bar" is a typedef name or not.
I have IE6 on Windows 2000 (i.e. Microsoft thinks I'm safe) but Outlook Express still attempts to auto-run Klez in my preview pane, and it's only a third-party virus scanner that stops it running.
A car stereo would be one place I would think they would try incorporate decent audio decompression hardware...
The empeg contains a 200MHz StrongARM. Recent Rio portables contain ARM7s (not sure how fast, I'd guess ~40MHz). They play WMAs and MP3s because there are decent fixed-point software decoders for those formats. Nobody is going to put an FPU in a Walkman form factor (battery life, remember); nor is it a good idea to use a hardware codec which can't be field-upgraded in software.
1.4 "IPR Impairing License" shall mean the GNU General Public License, the GNU Lesser/Library General Public License,
and any license that requires in any instance that other software distributed with software subject to such license (a) be disclosed and distributed in source code form; (b) be licensed for purposes of making derivative works; or (c) be redistributable at no charge.
Notice that they don't say "and any other license". They know full well that the GPL itself does not impair anybody else's intellectual property; nor could it if it wanted to. The whole thing is, as the original poster implied, a GPL scare tactic.
Do you have any idea what underlying protocol this software uses?
It's more-or-less the same as the empeg-car synchronise protocol, for which GPL source is available (search for "emptool"). There is already a rather nifty Java re-implementation (www.jempeg.org), which I believe can (or soon will) synchronise to Rio Centrals just as well as to empeg-cars.
I can't believe that it is soooo hard to do a reasonable AA (no aa between 8-14px, only AA the "round" places and not simply blur the whole letter which looks awful)
any comments on this?
It probably depends what you're used to. To me, whole-letter blurring looks "right" and Windows' blurring of the round places looks "wrong". And 8-14px is exactly when I want the text anti-aliased!
the network over phone lines sounds interesting though - too bad I don't have a modem
You don't need a modem. HomePNA communicates from phone-socket to phone-socket without taking the phone off-hook (and without interfering with voice, ISDN, or ADSL if it is off-hook). You do, however, need a HomePNA card in your PC. Some versions of the Receiver come with a PCI HomePNA card in the box.
Slashdot Mirror
No, it's BSD-licensed.
It would be interesting to see what kind of optimizations they used such as special DSP instructions.
Actually we use the Tremor (integerised) Vorbis library almost completely stock -- it already came with optimisations for ARM. The only thing we've really had to take a hitting thing to is its memory allocation.
Peter
Yup. It works out about the same CPU usage as MP3 for normal (64-128) bitrates, but seems to scale with bitrate a lot more than MP3 does; by the time you get to 256Kbits/s, Vorbis is really hard work.
Peter
You plug it in. If there's a DHCP server, it DHCPs, otherwise it autonets (UPnP-styley). Then it announces itself over SSDP multicast. If you're using Windows XP Home (or anything else that talks SSDP -- it's a completely open standard) an icon pops up in Network Neighbourhood. If you're using other sorts of Windows, an icon pops up in our own transfer software. Otherwise, you just point a web browser at it: there's a web server in it which will serve you a completely cross-platform Java applet to do your transfers.
I don't know whether we'll be actively helping the open-source community to implement the Ethernet protocol this time, but it certainly wouldn't be rocket science to reverse-engineer it.
Peter
Peter
We tested Karma with Vorbis bitrates up to 256Kbits/s VBR. Anyone using Vorbis at higher bitrates than that should IMO be using Flac.
Peter
Have one? He is one. We build a Slashdot astroturfing bot into each unit -- that's what the Ethernet is for.
Peter
Use an Ethernet-to-wireless bridge (e.g. WET11) on the Ethernet port. No hacking required.
Peter
(It always used to gall me slightly that the Rio Central and car-player were described as "hackable", with the implication that people customising them were outwitting us in some way, whereas in fact we put a good deal of effort into making them geek-customisable...)
Peter
That reference.com page has a link to "Get the Top 10 Most Popular Sites for 'larceny'" but none of them were as interesting as I'd hoped.
Peter
No. They were pointing out to those tempted to release MPlayer binaries, that while the MPlayer source is not a derived work of the GPL libraries (and so may be redistributed even though it has GPL-incompatible components), an MPlayer binary is a derived work and so may be used (the GPL nowhere prevents use) but not redistributed (GPL section 7).
Such was the MPlayer developers' interpretation of the GPL, and it was mine too: I've released sources into the public domain which linked against GPL libraries, on the same basis that the sources (which I release) are not a derived work even though any binaries (which I don't release) would be. However, this chap upthread seems to be saying I (and MPlayer) were wrong to do so. It does seem slightly cockeyed to me that the GPL works to prevent the release of public domain software, for instance to prevent the release of a Win32 version as public domain just because the Unix version links against Qt.
(Why is public-domain software GPL-incompatible? Because placing works in the public domain prohibits anyone, even the author, from claiming copyright on them; but the GPL requires that the author claim copyright.)
Peter
It's not shut off, it's emitted with a copyright bit (part of the stream format) set. It's the "client" end (a DAT recorder, for instance) which does the prohibiting. This is all well-trodden ground to anyone who's messed with audio DAT drives or audio CD recorders: it prohibits you from recording copyright-asserted content from one to another digitally.
Peter
Bits are not a product. Atoms are a product. Such people could be sold merchandising, or gig tickets. Those are the saleable products of the music industry. Music is not.
Peter
foo = (bar)-7;
You can't tell if that's a cast of a negative integer to type "bar" or a subtraction of 7 from variable "bar" unless you know whether "bar" is a typedef name or not.
But C++ has significantly worse parsing problems.
Peter
Peter
Peter
The empeg contains a 200MHz StrongARM. Recent Rio portables contain ARM7s (not sure how fast, I'd guess ~40MHz). They play WMAs and MP3s because there are decent fixed-point software decoders for those formats. Nobody is going to put an FPU in a Walkman form factor (battery life, remember); nor is it a good idea to use a hardware codec which can't be field-upgraded in software.
Peter
Peter
Because we needn't have bothered. There was Linux and MacOS support pretty quickly anyway, just from people reverse-engineering the protocol.
Peter
You only get the source for the GPL/LGPL bits (kernel, bash, glibc, etc). You don't get the source for the main player application.
Peter
Do you have any idea what underlying protocol this software uses?
It's more-or-less the same as the empeg-car synchronise protocol, for which GPL source is available (search for "emptool"). There is already a rather nifty Java re-implementation (www.jempeg.org), which I believe can (or soon will) synchronise to Rio Centrals just as well as to empeg-cars.
Peter
The source is available but the link is wrong. Try ftp://ftp.diamondmm.com/pub/rio/radac/
Peter
It doesn't, in fact, have an FTP server. There is a Windows program supplied for storing existing MP3s onto it; this access can be password-protected.
What bitrate does it rip at?
You get to choose, off a menu. By default it rips twice, once at high bit-rate for playback, once at low bit-rate for downloading to portables.
Peter
any comments on this?
It probably depends what you're used to. To me, whole-letter blurring looks "right" and Windows' blurring of the round places looks "wrong". And 8-14px is exactly when I want the text anti-aliased!
Peter
You don't need a modem. HomePNA communicates from phone-socket to phone-socket without taking the phone off-hook (and without interfering with voice, ISDN, or ADSL if it is off-hook). You do, however, need a HomePNA card in your PC. Some versions of the Receiver come with a PCI HomePNA card in the box.
Peter
Charles Dickens said it best:
"Two CPUs, load average 1.95, result: happiness. Two CPUs, load average 2.05, result: misery."
Peter