Intro

What is this?
A collection of geeky details about the hardware, software, operation, and design of the Rio Karma. We obsess about digital audio players here at DAPreview, which is why this kind of stuff is interesting (to us, anyway). The Karma holds a particular fascination as our house favorite.

What's the source of the information?
Everything presented here comes from employees and associates of Rio Audio, taken from messages posted at the Riovolution.com forums over the last couple years. Riovolution is a fan site for Rio Audio players, and everything that's been written in the forums is available for public review. I pulled up a list of posts made by each of the guys from Rio, sorted through them, and saved anything interesting. Just keep in mind that these people from Rio, when posting at Riovolution, are doing so as enthusiasts... not as company representatives.

Note that much of the text was copied word for word but in some cases I paraphrased or combined things. I tried to group the information in some useful ways but I don't have the time to organize it further. Also, this stuff was compiled back in September 2004.

Thanks
I want to give our thanks to the Rio developers who were good enough to share all of this with the fans and for the effort they put into the Rio Karma. We appreciate the attention to detail and the many playback options that you won't find on any other player.

---

Index

Karma: Hardware
Hard Drive
Hard Drive issues/Failure Rate
Battery, Power Management, Power Consumption
Internal Hardware
DAC
Dock
Line-out or Networking cables from the Dock Connector port
In-line Remote
Networking, Transfers

Karma: Software
Linux apps
Rio Music Manager
Open-Sourcing

Karma: Features
Gapless
Cross fading
Track Profiling
Shuffle
EQ
AGC/Normalizing
Codecs
Possible New Features
ReplayGain Support

Karma: System
Karma's OS
Buffering
Tagging
Handling of similar files and names
Playback Tracking
Languages, Fonts
Recovery Mode, Updating, Rescanning
Remaining Bugs in Fir mware 1.68

Karma: Audio
Sound Quality & Audio Performance

Rio Carbon
Notes about the Rio Carbon

Rio
SonicBlue, Rio, DNNA
Rio people at Riovolution

---

Karma: Hardware

Hard Drive (top)

• The software really isn't picky, as long as the drive is big enough to hold the system partition.
  
• The housing size and thickness of 1.8-inch drives aren't standardized like they are for 2.5in and 3.5in. Toshiba drives are a little longer and thinner than the Hitachi drives used in Karma, and they have a different connector.
  
• The Karma's HDD connector, though physically the same as a 2.5" one, runs at 3.3v (2.5" drives need 5v).
  
• 3.3v happy drives include Hitachi 1.8", Toshiba 1.8" with an adaptor of some sort (though they won't fit in the case), CF drives with an adaptor (all CF cards have to be 3.3v and 5v happy).
  
• Karma does not do LBA-48 addressing, so you'd be limited to 137gb
  
• The 40GB drive is 2.5mm thicker and will not fit in the casing properly, and the software isn't tuned to deal with twice the number of tunes. The more tracks you have on there, the bigger the database and the less room there is for caching. If you just loaded the same number of tunes at a higher bit rate, then it would probably behave ok.
  
• Karma will format any blank drive it can detect
  
• MicroDrives and flash cards could be used in place of a HD with a 2mm 44-way to 50-way CF ATA adaptor.
  
• The Hitachi drive, although shorter than a standard laptop drive, has the same connector and will happily run from 5v (runs at 3.3 in the Karma).
  

Hard Drive issues/Failure Rate (top)

• Stiction in modern drives occurs because the platter and head are so perfectly machined flat (and the atmosphere inside a drive so perfectly dustless) that, once they touch, the atomic forces holding them together (i.e. the same ones holding a solid block of material together) are significant.
  
• Shock is rated at 1200G, say the drive makers. If anything happened to you while running that caused the drive to experience 1200G, then it'd be your next of kin who would be worrying about whether your Karma still worked.
  
• Rio firmware is not the issue - nothing the firmware can do should land a head on the platter. Rio has investigated this very seriously (and still have the issue open with the HDD manufacturer) however the RMA rate for disk failure (which is barely to the left of the decimal point) is totally consistent with HDD technology in general.
  
• Rio does not publish RMA statistics but the disk failure rate appears to be less than 1%.
  
• Only if reinstalling the firmware fails, or recovery mode says no disk is found, is there likely to be a hard disk failure or stiction problem.
  

Battery, Power Management, Power Consumption (top)

• Power consumption through the jack is spec'd for worst case scenario: backlight on, disk spun up and writing, ethernet active, usb2.0 connection (USB2.0 chip running, 480MHz PLL), cpu locked in fast mode (it does this when docked to give better TCP performance), battery charger at full tilt (battery level is low), & input voltage sagging to about 4.75v. I don't think this actually hits 2A, but it almost certainly could hit 1.5A. The PSU is overspec'd so it's running well within its limits.
  
• Karma does have some continuous-battery drain similar to iPod, although its sleep mode doesn't seem to use anything near as much power as the iPod. The reason is that DRM requires an onboard clock, and an onboard clock requires continuous power.
  
• The battery gradually self-discharges anyway, so you wouldn't get infinite shelf-life even if there were a hard power-switch.
  
• Charge-over-USB wasn't implemented because Karma is rated as needing 2A (that's what the PSU supplies) whereas a USB port is limited to 500mA. A USB target is limited to 100mA unless it specifically negotiates 500mA, which the Karma doesn't. USB cannot provide enough current to both run the player and charge it at the same time. At least, not if you care about USB compliance,
  
• The battery _cannot_ overcharge. There is autonomous smart circuitry to ensure this. Also, it will not charge if the temperature is out of range.
  
• Karma will draw more battery current when docked (assuming there is no power supply attached to the dock of course). This is mostly because of the components in the dock that have to get powered, including part of the Ethernet interface. The player also makes certain assumptions about being docked, and switches itself into a less power efficient mode.
  
• Every band on the EQ that is non zero takes a little more power; but only a little. Tweaking all five bands of the EQ could knock off an hour or so.
  
• Using the VU meters does not consume extra power.
  
• There is a slight improvement in battery life with lower bit rates, mostly because the disk has to spin up less often, but also because the decoder overhead is lower.
  
• If a Li-Ion battery is fully charged and stored for a year its capacity will decrease by about 20% - Similar degradation occurs when the battery is deeply discharged for a period of time. At around 40% fullness Li-Ion battery degradation over the course of a year is around 4%.
  
• Extremely low impedance (like 4ohm) headphones/speakers will use the battery faster but shouldn't cause any harm. It was designed for 16 or 32ohm loads.
  
• The player shouldn't get that hot during charge (especially if it's off). There will be heat under the Rio logo on the front, this is where the charger chip is, but the rest of the player should not get more than slightly warm. If you're syncing to the player then the HDD is running continuously and will get warm.
  
• USB being connected takes >2x as much power as the player playing - even if you're not downloading (it's higher still in that case). The USB chip takes a lot of power.
  
• Karma will switch over to the battery at low input voltages, this is done by the charge controller chip. HOWEVER, the plug indicator may still display - this doesn't mean the unit is being charged (or powered) - the trip point for the AC input detection is NOT the same as the trip point for the charger activation - the charger/power switching is an autonomous system apart from the CPU.
  
• The battery level indicator is gauged on battery voltage and instantaneous current draw.
  
• The player shuts down at 3.5v at which point the battery only has 1-2% charge left.
  
• EQ settings can have a significant effect on power usage
  
• If USB is plugged in, this drains lots of power. This can be detected and the USB chip is only enabled if a USB connection is detected.
  
• Ethernet can't be detected in the same way as USB, so when docked the player periodically (every 5s) powers up the ethernet chip and tries to do link negotiation. If the dock isn't plugged in it will still work but it hits the battery big-time.
  
• The more buffer RAM you have, the more power you expend on running it. And RAM, unlike disk, is running the whole time. So there's a sweet-spot amount of RAM for the best battery life, and it's less than you might think, although it's constantly moving as new RAM and disk technologies are developed.
  
• Battery is not easily replaceable as it is hardwired to the sub board that has the charging (protection) circuit.
  
• There is no battery replacement program in place for US customers while there is a replacement program in place in Japan for that market.
  
• The Karma battery pack is 2 x 800mAh cells in parallel, with a protection circuit at the top (the little bulge where the wires come out).
  
• There's no sleep mode (low-power mode), so no instant on capability.
  
• Random play does not affect battery life.
  

Internal Hardware (top)

• Processors: 2 ARM7's, each one can go up to 90Mhz. At that rate even half an ARM7 could easily decode MP3.
  
• I believe the Philips player has the same processor as the iPod, which in turn is almost identical to that in Karma. Given similar starting platforms, all players are not created equal
  
• Karma output is max 55mW/channel into 16 ohms.
  
• The DAC/headphone amp in the Karma is the same series as used in the iPod - Wolfson 87[2|3]1, hence the output power is comparable.
  
• The display is made by VDS, it's a custom part probably not available for individuals to purchase. On the display, it reads: VG T161251 1WFEBA, then 038022807.
  
• The wheel is a Panasonic part; it's off the shelf (and used in various other things, like the Blackberry for example) - Rio did not influence its internal design, it's a single component.
  
• The charger IC is a Linear Tech LT1733 ISTR.
  
• Battery is 1600 mAh, 59 x 48 x 6.5mm
  

Karma DAC (top)

• The DAC is fed with standard I2S signal. The pins are:
  Pin 2 - I2S bit clock
  Pin 3 - I2S data
  Pin 4 - I2S left/right clock
  
  However, there is no external 256fs master clock signal, which may be required to drive an external DAC setup. The Wolfson DAC is special in that it will accept a 272fs or 544fs master clock, which is great if you have a 12/24MHz clock kicking about (e.g., a USB clock) but not very standard for audio components. Also, the lines are not buffered and are at 3.3v levels - you may run into signal integrity problems over a cable run and the lines are not particularly protected against static discharges as they were never supposed to run outside the case.
  

Dock (top)

• Cradle is intended to be used powered, but all of the dock functionality will work without it, except for the LEDs. The RCAs on the dock work even when it's unpowered.
  
• Inside: The J6 line is not a JTAG header, that's where the debug serial connection comes out. Except that it's not serial level, it needs a line driver chip on its dongle, so you can't just connect it to a PC serial port. Even so, released firmware builds don't output anything on the serial port (nor can they; the GPIO is shared with the blue dock light control).
  
• The line outputs have been measured as having slightly higher quality than the headphone output
  
• The light on the dock, when set to pulse by the music,
  
• An early implementation of the Dock Pulse used something like BPM, but an AGC approach was eventually settled on because the BPM beat is actually a lot less interesting to watch.
  
• The ethernet transceiver is in the dock, and is powered when the Karma is docked. AC power is assumed.
  

Line-out or Networking cables directly from Karma's Dock Connector port (top)

• Some of the LAN hardware is in the dock, so for a networking cable, you'd end up with a nutmeg-sized dongle and there would be issues keeping the cable anchored to the player.
  
• The part in the dock (that connects to Karma's connector) is a Molex 54944-2690. These are not easy to get hold of, and are not suitable for cable connection.
  
• There would be no power consumption issue with a line out-dock cable. The big problem is that the connectors are not easily available. There may be a cable-mount version of the connector, but this has not been verified.
  
• If using the PCB mount connector (as does Karma), it's dual-row which means you can't really solder it down without an oven as you can't physically access the internal row of pins with the connector sat on a PCB - so no hand-soldering possible.
  
• The same connector is used on the Casio Exilim cameras, and they have a remote/headphone port which uses this connector.
  

In-Line Remote (top)

• Support for a remote is not written into the firmware.
  
• Some testing of the remote port was done early in development, but it was never configured for actual listening or controlling the UI with it.
  
• It's not clear why the remote was abandoned except that it was probably decided that it would not be profitable for the expected volume of sales, after tooling costs. Same issue applies other accessories.
  
• One remote prototype used a Philips I2C port expander and an I2C addressable LCD display. The controls and LCD both hook up to the same I2C bus (i.e., SDA and SCL wires). There's support in the code for talking to the Philips I2C IO expander, it's just commented out. It was used to validate the hardware.
  

Networking, Transfers (top)

• Would it be possible for somebody to create an interface to control the Karma via the network? No, the protocol doesn't support this.
  
• Could a WiFi USB adapter be plugged into the Dock to make it wireless? No, Karma's dock is USB slave only, but you can use an ethernet-to-WiFi bridge to get the same effect.
  
• Ethernet transfers are much slower than USB transfers, mainly because of network stack performance in our embedded application. The USB chip talks direct to the hard drive with no interaction by the CPU. With ethernet there is significant CPU involvement running the TCP stack, transfer protocol, etc, hence it is slower.
  
• Support 100mbit. You do not get full 100mbit speeds, mainly because of the poor little CPU running the TCP stack, but most people see over 1MByte/second, which is the vague maximum of 10mbit ethernet.
  
• A USB 2.0 connection will max out the Karma hard disk at around 10MB/sec
  
• Ethernet hardware is divided up between Karma and dock. The magnetics are in the dock, the rest of the chipset, including the bit with the MAC address, is in the Karma unit.
  
• When you transfer using Ethernet, it's Karma's job to sort the artist list, so it's the Karma firmware version which decides how that's done (for example older versions wouldn't see Doors and The Doors as the same Artist). When you transfer using USB, it's the PC's job to sort the artist list, so that depends on the Rio Music Manager version.
  

---

Karma: Software

Linux apps (top)

• Files located at [Linky]
  
• July 3: Source code released for RioStreamer, RioCopy, RioBackup, RioRID, and RioRepair. No RMML source yet. Java docs available from [Linky].
  
• Under a properly configured network, RMML typically meets or beats RMM's speed on the same transfer (the "beats" occasions are mainly because a slightly larger buffer size is used in RMML).
  
• In RMML, playlist properties included an "Always randomize contents" flag. It doesn't work. You can set the flag in RMML, save the playlist to the Karma, then open it again and the flag is cleared.
  

Rio Music Manager (top)

• RMM will encode CDs into Ogg Vorbis (.ogg) and FLAC (.flac) and WMA out-of-the-box. MP3 encoding is an optional upgrade ($10) but only needed if you like the idea of doing everything without leaving Rio Music Manager. Alternatively you can use (free) MP3 encoders like LAME. [UPDATE: The $10 commercial encoder is no longer available, but somewhere on rioaudio.com you can get LAME itself pre-packaged in an installer that puts it where RMM expects to find it.]
  
• Songs can be copied from Karma to PC in both RMM and RMM Lite. In RMM, select the songs (or genres, or whatever) that you want to copy back, right-click to open the context menu, and choose "Save As".
  
• There's an Easter Egg in there somewhere
  
• Rio Music Manager has advanced synchronization features (just like what Apple are now calling "AutoFill") capable of randomly cycling a larger FLAC collection on and off the Karma
  

Open-Sourcing (top)

• Karma firmware releases are encrypted for DRM reasons. It's the WMA DRM part that stops it being possible to open-source the firmware.
  
• The possibility of two alternative firmware versions was considered: one Karma-like, closed-source, encrypted and DRM-capable, and the other Empeg-car-like, open-source kernel and closed-source userland, non-DRM-capable. But nothing came of it. There are hardware issues about hiding key-management stuff from the open-source kernel whilst making it available to the closed-source WMA firmware.
  
• Adding GPL'd code to the firmware means you have to release the source code to the entire binary. In Karma's case, this is the entire source code. FTP was simple enough to implement ourselves, without using any GPL code.
  
• Ogg Vorbis has a BSD license, not GPL.
  
• FLAC was the first, and AFAIK is still the only, lossless codec released under a BSD-style license which allows us to incorporate it for free into commercial products.
  
• The Karma OS (Ecos) requires the whole application to be linked as one monolithic binary. The licensing conditions of the WMA DRM stuff require us to forbid reverse-engineering of that binary, while the licensing conditions of the LGPL code forbid us from forbidding reverse-engineering. Thus Rio cannot incorporate both WDA DRM and LCPL code in the same firmware build, and Rio believes that WMA DRM is considerably more popular than any GPL code that has been considered. Including MPC codec support.
  

---

Karma: Features

Gapless (top)

• Even though a player doesn't add gaps, Regular MP3 playback can have gaps between tracks because blank frames at the start and/or end of the track. Old encoders would regularly prepend or append blank frames to tracks for no particularly good reason. This is less common now, and in any case the frames are relatively easy to remove using an MP3 trim program.
  
• First and final frame padding. This problem is inherent to the MP3 format. Frames are a fixed length (1/32nd of a second) but of course a track is rarely an exact multiple of frames. Therefore some padding must occur, and usually this is split between the first and final frame. This means there could be a glitch up to about 1/32nd of a second in length between tracks. In practice this is often not noticeable. YMMV.
  
• Karma will attempt to compensate for gaps introduced by MP3 encoders. It can use information added to VBR files by Lame (3.90 and later) in order to do so with total precision; for other encoders or for files without the Info header (i.e. most CBR files), it uses a heuristic, which produces indistinguishable results in most cases.
  
• This process will not eliminate gaps which are present in the source material, i.e. if there's a one-second gap between songs when you play the original CD, Karma will render that gap faithfully. You can look into using the cross-fader if this is a problem. There should be no other situation in which MP3 files exhibit one-second gaps on Karma, unless the MP3 files themselves are damaged.
  
• A rip to individual FLAC tracks will play back gaplessly on a Karma, and, as FLAC is lossless and sample-accurate, it should play back gaplessly on any other FLAC player, too.
  
• Karma 1.41 and before didn't use the Lame tag to do gapless, it used a heuristic in all cases.
  
• The very first Karma firmware required LAME --nogap encodes, with all tracks of the album encoded in one operation, to give gapless MP3s. Subsequent versions can also produce gapless playback by reading the gapless tag which is added even for single-file encodes.
  

Cross fading (top)

• It does take 30 seconds to prepare a 3 second cross fade
  
• If you have cross fade set to 3 seconds, and a track starts and then 15 seconds later you skip the next track, then you won't get the 3 second cross fade, you would get 1.5 seconds worth of cross fading.
  
• Skipping shortly after the track has started will result in a short cross fade
  
• 3 second cross fade takes about 0.5MB of space, or the equivalent of about 30 seconds of audio buffering. Cross fade could be increased by reducing buffering, but it was decided to leave the maximum at 3s on Karma.
  
• Cross fading uses a single decoder driven at faster than real-time (not 2 decoders). If it were using 2 then there would be no restriction on the length of the cross fade since the two decoders would be decoding simultaneously and both feeding into the mixer.
  
• Another way to tell that this is the case is to watch the track profiler build a new profile for a fairly short track - You will notice that the profile gets built ahead of the playback position, and that this gap gets wider until the profile is the chosen cross fade setting ahead of the playback position (maximum 3 seconds currently).
  

Track Profiling (top)

• This is not a visualization, it is a tool for navigating within a track visually
  
• The profiles on Karma are 48 bytes each, so a very small size overhead. A track's profile is only generated the first time the track is played (or if the profiling firmware changes and needs to update a profile because it was created by an older profiler)
  

Codecs (top)

• WMA is supported only up to 192Kbits/s. The decoder used in Karma won't play any WMA track, or section of a track, that's more than 192kbps. And of course any track which averages 192kbps will have some sections which are higher bit rate and so won't play. As soon as the WMA decoder sees such a section, it gives up on the whole track. There isn't a lot we can do about that, sadly, as we license in the decoder as a "black box".
  
• MPC (and other) decoders cannot be supported because of its LGPL status which conflicts with requirements of WMA DRM which is a more popular feature.
  
• FLAC gives about three hours less battery life than MP3, mainly because the disk has to spin up more often.
  

EQ (top)

• Custom EQ, regarding octaves and widths:
  
  • Each octave is a halving or doubling
    
  • A curve is applied to the EQ in that the centre frequency is just the peak of the curve and the "width" is the width at which the effect is half what it is at the peak.
    
  • If the centre is 60Hz and width is 2 octaves, then 60Hz will receive the biggest boost, 30Hz half as much boost as 60Hz, and 120Hz also half as much boost as 60Hz. Beyond 30Hz and 120Hz it tails off.
    
• Karma EQ presets...
  
  • Rock: 4, -2, 0, 6, 0
    
  • Pop: 2, 0, 6, 0, -2
    
  • Jazz: 2, 0, 1, 0, -3
    
  • Classical: -3, 0, 3, 0, -3
    
  • Trance: 4, 5, 0, 0, 6
    
• Stereo Separation feature involves cross feed, delay, and roll-off. Designed for old Beatles-style stereo recordings with hard left/right panning.
  
• Karma has a flat response when the EQ is turned off. The vast majority of CE devices set their "flat" EQ to a slight curve, which is considered pleasing to the ear. This typically adds a little at the top and a little at the bottom.
  
• EQ settings can have a significant effect on power usage
  

Shuffle (top)

• Shuffle and Random playback are the same thing, the difference is just a matter of the order in which tracks are displayed in the "now playing" screen.
  
• Shuffle never plays the same track twice, removes duplicates in the shuffled order so each song only appears once.
  
• When songs are shuffled, they are then listed in the Now Playing screen in their randomly shuffled order. This makes it easy to see which song is coming up next, in case you don't like it. If it just showed the original track order, then each time a new track started it would jump around in that list and you'd have no idea what the next random track is.
  
• You can unshuffle around the current track to hear the rest of an album you like (same with random, but pointing out this is not a disadvantage)
  
• shuffle remembers all the tracks you've already heard and puts them behind the current track, so you can switch in and out of shuffle without having to listen again to tracks you've already heard from the running order
  
• You can shuffle, observe the running order, reshuffle if you don't like the order, etc.
  
• Shuffle order is preserved across reboots until you replace the running order
  
• the xx/yy indicator shows you how far through the shuffle you are, not how far through the original order. The 41/65 means you're on the 41st song of the shuffled order, not of the original order. If you turn shuffle off, the 41 will (probably) change to a different number which is the position of that song in the original order.
  
• Karma has a bipartite shuffle: whenever you turn shuffle on, it takes all the songs in the current running-order which you've heard, shuffles them, and puts them behind the current song; then it takes all the other songs, which you haven't heard, shuffles them separately, and puts them ahead of the current song. Shuffle mode never repeats until you've heard everything once (when the flags all get cleared and it starts again). This even carries on working if you Insert or Append new songs into the running-order, although obviously it's not remembered if you select an all-new running-order in Play Music. The flags are also remembered when you make a bookmark, and are restored when the bookmark is restored.
  

AGC/Normalizing (top)

• The auto gain control feature does not operate on tracks as a whole, it has no concept of tracks, instead it operates on an audio stream.
  
• The reference level is determined from the audio that has recently passed through an algorithm.
  
• The feature is rather like a compressor in the conventional audio domain in that it makes quieter passages in the audio sound louder. Such a feature can be desirable when listening to delicate music in a noisy environment - The idea is that the quieter passages of the music are brought to a level where they can be heard above the background noise. An audiophile listening at home would not have the feature turned on since it might be said that it removes a level of artistic expression from the sound.
  
• A feature that adjusts the volume based on the track's peak level might be described as a 'normalizer'
  

ReplayGain Support (top)

• We did actually implement it. But the whole user-experience is so bad (the overall volume reduction, the need to set a guessed pre-amp for non-RG tracks, the tagging confusion) that we disabled it for the 1.68 release. If it gets enabled again in the future, it would only be as a deeply, darkly hidden config-file option or suchlike, with stern warnings not to turn it on unless you're sure you know what you're doing.
  
• As an example of the sort of issue facing us, suppose you encode a CD with Lame. Modern Lame versions write a RG tag into the Lame header. So should we obey the Lame header and attenuate the output? If so, why does MP3Gain not alter the Lame header? Surely after MP3Gaining, the required further attenuation is zero?
  

Possible New Features (top)

• The Real Time Clock has an alarm feature that (in theory) would allow the player to wake up when the alarm time was reached. This draws no more power. However this feature is not on the to-do list.
  
• Karma already calculates BMP although it isn't used for anything yet. The code has been in place for a year or two and it is pretty accurate - usually giving the same figure as the original CD sleeve. Karma can also pitch shift if we were to add the UI.
  
• There was a time when we all thought a mass-storage upgrade for Karma was only months away. So we said so. Then Rio's plans changed. It was never really a promise though. There were no database or battery life issues that prevent a conversion to MSC functionality. The issue in upgrading a unit from non-MSC to MSC is that it would require a reformat.
  
• MPC support wasn't added for licensing issues and possible patent issues.
  

---

Karma: System

Karma's OS (top)

• The embedded OS used in Karma is called Ecos, and it's an older release under an RHEPL license. This license allows us to link a proprietary application against it, just so long as any changes are shared with Ecos itself.
  
• Modern releases of Ecos are under the GPL plus an exception clause, so in theory it could be used.
  
• Despite what has been said the past, the Karma file system is NOT journaled, and offers NO better behavior on unexpected power-down than would be offered by any purely hypothetical FAT32 Karma. The people who implemented the file system made several others people at Rio believe it was journaled, but there's no journaling or journal-replay code anywhere in there.
  
• The current proprietary file system rules out the possibility of it being mass-storage class USB device
  
• Ecos requires the whole application to be linked as one monolithic binary.
  
• OS has something like 1.2 million lines of code, incorporating most of the aspects of any modern computer system and many additional challenges unique to a time critical system - including multitasking/multithreading, a full network stack, multi-processing (there are two ARM cores), scalable filter graph network, GUI, database, tight power optimizations, etc.
  
• Karma firmware is written mostly in C++, the smaller players are a mix of C and assembler.
  
• Possible for user to create their own firmware? Possible, but requires the compiler tool chain to get started and that's $10,000 per seat. [UPDATE: Karma's firmware is built with GCC, which is free, although something of a chore to configure correctly if you want cross-compiling multi-threaded C++ to work]
  
• The firmware loads out of FLASH memory although a few bits and pieces such as RMML are put on the hard disk by the firmware updater (so you can always restore a player with a completely blank disk).
  
• The HD stores a couple of hundred KB worth of data files used by the player, such as your running order, bookmarks, resume details, settings and so forth. The firmware loads out of FLASH memory although a few bits and pieces such as RMML are put on the hard disk by the firmware updater (so you can always restore a player with a completely blank disk).
  
• The code in the Karma started life in 1998 and was 3 production players (though none of them hand-portable) before it went into the Karma.
  

Handling of similar files and names (top)

• "Accent-folding" was implemented so that "Beyonce" and "Beyoncé" are now listed as one menu entry, not two.
  
• Karma differentiates between tracks by MD5 digest (of audio data only), not by leafname. Loading a track won't overwrite another unless it's actually the same encoding of the same version of the same song.
  
• RMM won't load two copies of the same song to Karma, even if the two copies are tagged differently. This is to prevent wasted space from duplicate tracks.
  
• RMM and Karma ignore all non-alphanumeric characters when matching names. That's how they can tell that "R.E.M.", "REM", and "R-E-M" are all the same band.
  
• Karma will recognize that "POP" is the same as "Pop", "ACDC" the same as "AC/DC", "The Beatles" the same as "Beatles", and so on.
  
• "A ..." bands are sorted as if the "A" were not there. Like "A Flock Of Seagulls" is sorted under F.
  
• If you re-rip an album at a higher bit rate, with the same tags, RMM will transfer the second copy to Karma on the basis that the file contents are different.
  
• A track processed with MP3gain will be considered different from the same track that hasn't been processed with MP3gain. If you've already got the original one on your Karma, Rio Music Manager will cheerfully copy the Mp3Gain'd one on to it as well, as it doesn't know they're duplicates.
  
• Karma doesn't use tags at all to determine if a song is already present, it uses the audio data itself. If the audio data is identical, it will decide it's already present. If you have a single, and the exact same encoding with different tags (like album name) it still knows that the file is the same as another on the unit and won't transfer it.
  
• The filenames used on the unit itself (internally) have no relation to the tags on the file
  

Tagging (top)

• Karma will read iD3v.1 and iD3v.2 (2.2, 2.3, 2.4) tags.
  
• New files created by RMM get written with 2.3 tags, as that's the latest version that old WinAmps support.
  
• If you omit the Album tag on a track it will be listed under [None] in the list of Albums
  
• Karma does no tag extraction: it only believes the tags that RMM or RMML told it at the time the file was put on. So whenever you put a track on Karma, it gets the album tag that RMM thinks it has.
  
• Karma never reads any tags from the file. Karma is entirely told about tags by the PC-side software, whether RMM, Windows Media Player, or whatever.
  
• Karma uses native FLAC tags: artist, album, track number, title, genre, date.
  
• FLACs with FLAC tags only will be read correctly on the Karma
  
• RMM can read ID3v2 tags on FLAC files, but not ID3v1. (It can read both types on MP3 files.)
  
• RMM always uses UTF-16 (not UTF-8) for tagging non-Latin-1 MP3s; this seems to have the widest compatibility.
  
• If a FLAC file has id3 and Vorbis comment fields populated, RMM will use the id3 tags.
  
• RMM understands both FLAC comments and ID3v2-on-Flac. It doesn't understand ID3v1-on-Flac. It doesn't add ID3v2 tags unless you edit the tags in RMM, whereupon it does add an ID3v2 tag. [UPDATE: The current version of RMM never adds ID3v2 to Flac files; it always uses native Flac tags. It'll still read ID3v2-on-Flac though, and will rewrite ID3v2-on-Flac if you edit a file that already has such a tag. Similarly with Vorbis files.]
  
• Karma only supports track numbers up to 255
  

Buffering (top)

• Karma caches the beginnings of the tracks several tracks in advance, filling the memory buffer, so if you hit skip a few times, it can seamlessly start playing for long enough to spin the disk up and read the rest of the track.
  
• Not all the 16MB is used for cache - there's program code, workspace, cross fade buffer, fonts, etc all in there too.
  

Languages, Fonts (top)

• The PC software translates all ID3 tags to Unicode in order to tell Karma about them. Karma only understands Unicode (specifically, UTF-8).
  
• Currently it's not possible to customize the fonts
  
• Cyrillic and Greek were never in the official spec. Engineering crew snuck them in under the radar because it was dead easy and makes those few people who need it extremely happy.
  
• Will probably not be adding any languages for areas where it is not being sold (Hebrew, Chinese, Hangul, etc) due to expense of obtaining fonts and the difficulty of implementing some languages. Japanese can just be displayed character-for-character with no "intelligence", whereas with Hangul you have to know how to compose and decompose the syllables (unless we only allowed the composed form). And Karma doesn't do anything clever, for instance, about getting Kanji in the right order in menus: they just appear in Unicode order. That's definitely not smart enough behavior for Hangul syllables.
  
• The Karma fonts contain about 700 hand-drawn glyphs in each of the three sizes, almost the entire of WGL4 except the dingbats and box-drawing characters. And that's not including the several thousand Kanji characters.
  

Recovery Mode, Updating, Rescanning (top)

• To enter recovery mode, power down the unit, and then hold down the menu button while pressing the _power_ button (rather than the RioStick). It should then boot up into recovery mode.
  
• When you store a track onto Karma, Karma puts the tags both into the database (where all the menus and stuff access them) and into a fallback file on the file system. The rescan thing (Settings > Troubleshooting > Rebuild database) searches the file system for tracks and their fallback files, and makes a new database from them. It's kind of a hedge in case there are any bugs in the database code (whether on Karma or in RMM), or so you can "rescue" orphaned files in the case where someone yanks Karma's USB connection after RMM has stored the tracks, but before it's updated the database. Try that on most other MP3 players, even disk-based ones, and that disk space will be lost until the next reformat.
  

Playback Tracking (top)

• Times Played increments after you have listened to a certain number of seconds of the song, about 15 seconds.
  

Remaining Bugs in Firmware 1.68 (top)

• Year field doesn't appear on karma in tracks tagged with id3v2.4. Problem is with RMM so the fix depends on the next RMM release. Karma only displays the tags that RMM told it were in the file. For now you're probably better off sticking with ID3 v2.3.
  
• When you're looking at albums (or tracks) starting with a given letter, it ignores A/The when choosing which names to display, but then doesn't ignore them when sorting.
  

---

Karma: Audio

Sound Quality & Audio Performance (top)

• Karma is A-weighted at 95dB SNR, Nitrus at 93db SNR.
  
• 16 hour playback was attained many times during development and testing. It is attainable using reasonable bit rates, a reasonable volume setting, and we can also apply these same parameters across all our players, from Cali to Karma. Testing is done with 128kbit MP3 (CBR), EQ Off, volume 15/30, no backlight, no browsing, and with the supplied headphones plugged in.
  
• Things that can affect playback time include Backlight, Browsing/Playing with the unit (skipping tracks, etc), bit rate & codec, EQ settings, headphones, etc.
  
• SNR (Signal to Noise Ratio) is a measurement that directly reflects the quality of the output signal from the device. The higher the number, the better the quality. Whether an additional 5dB matters to you will depend how discerning a listener you are and what equipment you will be listening through. Another common measurement of quality is THD+N (Total Harmonic Distortion plus Noise). Again, Karma performs well in this area.
  
• If using the headphone jack on the karma as a line out jack, the best level would be 29 which corresponds to -1dB. The value for 0 (mute) is -120dB.
  
• Karma's output is 55mW/ch into 16 ohms.
  

---

Rio Carbon

General Notes about the Carbon (top)

• If you connect the Carbon to a computer's USB port it goes into USB mode. When in this mode, the disk drive is accessible from the PC, but you can't play music. When you connect the Carbon to a charger (in-home or in-car) it can play music whilst charging.
  
• There will be Janus on Carbon, it's just a pretty complex bit of work.
  
• It is not faster charging with the AC adaptor. The charge rate is identical between USB and AC charge.
  
• Any powered USB port is spec'd to supply 500mA. When charging, the Carbon takes only a tad over 400mA (peak), whether this is from a PC connection or from the AC adaptor. The AC adaptor is over-spec'd - we do not use 1A from this supply.
  
• A full charge takes about 2 hours, 20 minutes
  
• Carbon uses the same scroll wheel as Karma, but at a different angle within the case (i.e., click is at 45 degrees on the Karma and more like about 30 from vertical on the Carbon)
  
• Using the headphone extender, there is no measurable degradation. The extra capacitance & resistance of another set of contacts is really not a problem at audio frequencies.
  
• All Carbons leaving the factory after something like early December were AC-coupled - no static issue. That means all the ce2100s and Pearls have the static fix.
  
• We determined why flash cards (and maybe some HDDs) don't work - it's because they do not support the IDE flush cache command - we send this to the drive before spinning it down to ensure the drive's write cache is empty. This is why the player appears to work fine, then reboots a few seconds later - it's the point at which the player is spinning down the disk. It's possible the handling of this command will be changed in future releases which should mean it's compatible with many more flash cards, but I have to say it's not exactly a big priority for us!
  
• SNR is >93dB A-weighted, Output is >16mW per channel into 16 ohms
  
• The AC adaptor is 110-240v, so will work in the UK or Europe as long as you have a plug adaptor.
  
• Carbon's firmware is demand-paged out of SDRAM
  
• RMM renaming rules: punctuation and spacing are ignored, case is ignored, and accents are ignored. For artist names (only), "the", "der", "die", "les" and a small collection of leading articles from other European languages are also ignored. Implementing the full range of Karma/RMM rules would be a nightmare.
  
• No plans to add dynamic playlists
  

---

Rio

SonicBlue, Rio, DNNA (top)

• Sonicblue for the most part no longer exists. Rio and ReplayTV were acquired by D&M Holdings (Denon & Marantz) which formed the subsidiary named DNNA (Digital Networks North America) which consists of Rio, ReplayTV, and Escient. DNNA, at least the name, will probably go away, and all the D&M North American subsidiaries will be under the D&M parent company directly if it isn't already.
  
• See [Linky].
  
• The development wing of the "new Rio" is the old Empeg Limited, assimilated into Rio during 2000 and responsible for the Empeg-Car, the Rio Receiver, and the Rio Central (and, more recently, the S-series, Fuse/Cali/Chiba, Nitrus, and Karma). There's no connection (except the name) with the division of the "old Rio" who made the 300/600/800 and Riot.
  
• The original reasoning behind the Karma not being USB Mass Storage was legal (related to SonicBlue), not technical.
  
• Rio's HQ is in Santa Clara, ca (marketing and operations and most of the management) while firmware development is done in Cambridge, England.
  
• The software development team has a about a dozen people, including Windows as well as embedded.
  
• Empeg produced a now-discontinued but extremely well-loved MP3-playing hard-disk-based car stereo. Empeg was subsequently bought by the company which became Rio. Almost all of the original Empeg/Rio Car team still work at Rio, and the firmware in the Rio Karma is built from the same code-base as the Rio Car firmware (with different compile options, of course).
  
• Rio _invented_ the MP3 player business, six years ago. Rio 300 was the first MP3 player to ship in the US. Rio was the first company to get sued by the RIAA over MP3, defended the case, and was successful. Without Rio there would be no MP3 player market (or at least we'd be a few more years behind).
  
• Rio isn't a company - it is one of D&M's brands
  
• Rio was sold for pennies by the Chapter 11 stricken SonicBlue, which had certain expensive issues with the television industry at the time.
  
• Rio (or rather, D&M) has different sales and marketing teams in each of their major regions (currently North America, Europe and Japan).
  
• Various contract manufacturers make Rio products; the Karma is made by the factory that also makes iPods for Apple.
  
• Rio players have not been MSC due to restrictive rulings against Diamond Multimedia/Rio back when the Rio 300 came out. Now that assets were bought by another company (D&M), Rio is not bound to the old rulings which were unfair considering competitors didn't have the same restrictions. In the future, players will have mass storage class functionality.
  
• The Rio return centre was in Texas but has now moved to Milpitas, CA.
  

Rio people on Riovolution (top)

• phrenzy (Rob) was Manager of Software Development. No longer works for Rio.
  
• UK Rio Engineer (aka UKRE) is one of the engineers who is involved in the coding process
  
• peter is one of the engineers who is involved in the coding process
  
• Logan is in QA, he looks for errors in the code. -email-
  
• nanook works with the beta testers. aka Nong Vang, Rio Beta Program Coordinator. -email-
  
• mschrag wrote code for RMML as a contractor. not actually employed by Rio or D&M.
  
• TheBarrelShifter writes the visualization code
  
• monkeyboy maintains and updates RioAudio support site
  
• Travis works in Rio Support
  
• Eman is a member of the software team, mainly concentrating on the audio and platform side of things