Technical notes

reTONE changes how much it handles depending on the track format, the Android version and the output. For PCM tracks, sample rate conversion happens at most once on any path (for DSD, at most once after the DSD-to-PCM stage). With Bluetooth, the phone and the Bluetooth codec process the audio further after this. Playback is built on Android's MediaPlayer and AudioTrack, and reTONE's engine (written in C) handles decoding and conversion before them.

Android 4.x: Many Android 4.x phones open the music output thread at a fixed rate such as 48 kHz, and tracks at a different rate, such as 44.1 kHz or 96 kHz, are resampled inside Android's mixer before they play. Apps have no way to stop this conversion. The standard decoder in 4.x may also reduce 24-bit FLAC to 16 bits, or fail to open 192 kHz FLAC. So on 4.x, reTONE's engine reads all FLAC and WAV, as well as DSF, DFF and AIFF, converts them once to the phone's output rate (the value of AudioTrack.getNativeOutputSampleRate), and hands them over as 16-bit. Android's mixer accepts 16-bit audio at the same rate as is, so no sample rate conversion happens on the Android side. When reducing to 16 bits, reTONE applies TPDF dither, and when the output is 44.1 kHz or 48 kHz, it uses error-feedback noise shaping (Lipshitz, Vanderkooy and Wannamaker's 5-tap E-weighted filter) to move quantization noise to less audible frequencies. If clipping occurs, the fed-back error is limited to ±4 LSB to prevent oscillation. The coefficients were designed for 44.1 kHz and are also used at 48 kHz. The total amount of noise increases, but it's moved to high frequencies where the ear is less sensitive. However, if you set Android's volume below maximum, Android's mixer rounds to 16 bits again after applying the volume, which reduces the benefit of noise shaping. This doesn't apply to phones that adjust the volume in hardware. Either way, no sample rate conversion takes place. MP3, AAC and similar formats play through Android's standard path even on 4.x.

Android 5–9: The Android mixer in this generation accepts float, so reTONE's engine passes float audio to AudioTrack without dither. On phones with 16-bit output, Android then rounds it to 16 bits (Android doesn't apply dither at this point). FLAC and WAV tracks whose sample rate differs from the phone's output rate would be resampled by Android's mixer if passed as is, and tracks above 16 bits would be truncated to 16 bits. AOSP's default resampler uses medium dynamic quality (DYN_MED) when the quality setting (af.resampler.quality) isn't set, and drops to an even lower quality when the estimated load of the resamplers in use at the same time exceeds a limit. On the phone we checked, this setting wasn't set. reTONE's engine resamples only the tracks that meet these conditions, and you can turn this off with the "Conversion by reTONE" setting. 16-bit tracks at the phone's output rate (such as CD audio on a 44.1 kHz phone) need no conversion, so they play through Android's standard path.

Direct output (Android 10 and later; availability depends on the phone): Availability of "direct output," which sends audio at the track's rate without going through the mixer, and "offload," which decodes compressed audio on the chip, depends on the phone and the output. On Android 10 and later, an app can ask the phone with AudioTrack.isDirectPlaybackSupported whether a given format, rate and bit depth can be output directly to the current output. reTONE uses this path only when the phone says yes, and otherwise plays through Android's standard path. The answer differs by output, so reTONE asks again each time earphones or USB are plugged in or unplugged. On the phone we checked, the only formats that couldn't be output directly were 16-bit PCM at 44.1, 48 and 88.2 kHz (CD audio falls into this group). 24-bit and float could be output directly at the track's rate, and MP3 and AAC (tracks 60 seconds or longer) went to offload. So reTONE decodes 16-bit lossless audio (FLAC, ALAC, WAV) to PCM with the phone's decoder and passes it to MediaPlayer through MediaDataSource as a 24-bit WAV with the lower 8 bits filled with zeros. The upper 16 bits are unchanged. Before switching, it actually decodes the first block to confirm that real 16-bit PCM comes out, and falls back to the standard path if it can't confirm this. 24-bit and high-rate lossless audio, and MP3 and AAC, already go to direct output or offload, so they're passed as is. Apps have no way to read which output the phone actually used, so "DIRECT" on the player screen is an expectation based on the phone's answer (on the phone we checked, it matched the system's records). With offload, we also can't check whether the sample rate changes inside the chip. On this path, the phone's software sound effects (such as DTS) aren't applied, while the DAC's hardware settings (such as filters) still take effect. It can be turned on or off in Settings.

Direct output to USB DACs: When you connect a USB DAC to a phone with USB host support (OTG), reTONE sends data straight to the DAC without going through Android's audio path. On the phone we checked, Android's standard path converted audio to 16-bit/48 kHz for the USB DAC (an output for 32-bit/192 kHz was also open, but it wasn't used for music). reTONE's direct output works as follows.

• Using the phone's USB host API, reTONE finds the DAC, gets your permission, and reads the USB descriptors (USB Audio Class 2.0: the clock ID, the alternate settings of the playback interface, the output endpoint and the feedback endpoint).
• It takes the DAC over from Android's driver (claimInterface) and prefers a PCM, 2-channel, 32-bit alternate setting (24-bit or 16-bit if unavailable).
• It reads the supported sample rates with the clock source's GET RANGE. If the track's rate is in range, it sets it with SET CUR and confirms it with GET CUR. Only tracks at unsupported rates are resampled, once, by reTONE. Tracks at rates the DAC supports get no sample rate conversion and no dither. Tracks up to 24 bits are sent with the original data placed unchanged in the upper bits of a 32-bit word (from 0.69.0, when using the DAC's volume or when adjusting the volume on the DAC itself). With 16-bit DACs, tracks that are exactly 16-bit get no dither, and TPDF dither is applied only to tracks with more than 16 bits of resolution.
• Transfers are handled on the C side with usbdevfs isochronous transfers. For High Speed DACs that take audio every 0.125 ms (most of them), 1 ms of audio (8 microframes) is grouped into one transfer, and 64 of these are kept queued ahead. For DACs with a longer interval, each transfer holds 32 packets and fewer are queued, keeping about 64 ms ahead. Asynchronous DACs report the number of frames per microframe from the feedback endpoint, and reTONE adjusts how much it sends to match. The format of that value varies by DAC, so reTONE detects it from what arrives. Volume is applied right before sending, so changes take effect immediately.
• During this time, MP3, AAC and similar formats are also decoded to PCM with the phone's decoder (MediaCodec) before sending, so reTONE plays every track. Unplugging the DAC pauses playback. If the DAC isn't returned to Android, for example after a force stop, reTONE returns it right after an update, and when you open reTONE with "USB DAC direct output" turned off.

Many phones of the Android 4.1 generation can't use a USB DAC as an audio output, but reTONE's direct output uses only the USB host function, so it can still send audio. With our 2012 test phone (Android 4.1) and a battery-powered DAC, 24-bit/192 kHz played without conversion. We have tested USB Audio Class 2.0 DACs; Class 1.0 DACs are untested. Older phones can supply only a small current over USB, so bus-powered DACs may not be recognized. We've also seen a case where Wi-Fi radio interference reached the DAC through the USB cable and caused intermittent noise. Playback doesn't need a connection, so we recommend switching to airplane mode when listening through a USB DAC.

Sample rate conversion recalculates the waveform between the original samples, so the quality of the filter shows directly in the sound. reTONE's filter is an FIR filter made by applying a Kaiser window to a sinc function. It uses a polyphase structure, which splits the coefficients into groups to match the conversion ratio and computes only what's needed. The design rests on two criteria: don't reduce audible sound, and keep the aliasing caused by conversion well suppressed.

• Passband: flat to 20 kHz (within ±0.001 dB by design; for conversions between rates of 44.1 kHz or higher).
• Stopband: starts at "the lower rate − 20 kHz." Between 44.1 kHz and 48 kHz, that's 24.1 kHz. Aliasing that falls in this range appears above 20 kHz and stays out of the audible band (up to 20 kHz).
• Attenuation (design target): 120 dB for phones with float output (Android 5 and later), 100 dB for phones with 16-bit output (Android 4.x). The filter length and window are designed with a 2 dB margin over the target so the calculated value exceeds the target for every conversion (for 44.1 → 48 kHz, the calculated values are about 122 dB and about 102 dB). Residual aliasing at −100 dB is well below the 16-bit noise floor (around −93 dBFS full-band, including dither), so 100 dB of attenuation is audibly no different from 120 dB.
• Taps: determined from the attenuation and the transition band using the Kaiser window formula (86 taps for 44.1 ↔ 48 kHz at 120 dB).
• 2:1 stages: Stages that halve the rate exactly, such as 96 → 48 kHz, use a half-band filter, in which half the coefficients are zero and the rest are symmetric, cutting multiplications to about a quarter of a normal filter. 192 → 48 kHz uses two half-band stages, and remaining ratios such as 88.2 → 48 kHz are handled by a polyphase filter.

In measurements, 1 kHz, 19 kHz and 19.9 kHz signals came out at the same level within 0.01 dB. With a 30 kHz input, the aliasing appearing in 0–20 kHz was at least 104.6 dB below the original signal at 44.1 kHz and 48 kHz output, and at least 116 dB below for conversion from 192 kHz (measured before rounding to 16 bits). These are values at a single frequency. By design, the whole stopband is suppressed to at least the attenuation targets above.

Because conversion creates new points between the original samples, loud tracks can end up with points above 0 dBFS. When we converted several commercial recordings we had to 48 kHz, points above 0 dBFS made up 0.0001–0.001% of the total, with maximums of +0.38 to +0.59 dB. These get clipped at 16-bit output or in the phone's mixer, so when resampling, and only then, reTONE lowers the level by 1 dB, leaving headroom above the measured maximum. Tracks that aren't resampled are left unchanged, so on the same phone, resampled tracks are 1 dB quieter.

Volume isn't applied inside reTONE's engine. It's applied in Android's mixer (the AudioTrack volume). Applying it inside the engine would delay changes until the roughly 500 ms of audio buffered in AudioTrack finished playing, making the volume keys feel sluggish. On phones with 16-bit output, lowering the volume makes Android round to 16 bits again (Android doesn't apply dither at this point).

The calculations are written in C and use ARM NEON instructions to process the left and right channels together. The filter's inner loop reads coefficients as vectors and uses four accumulators to hide latency. Dither, including random numbers, rounding, clipping and error feedback, is also done entirely in NEON, avoiding transfers between NEON and general-purpose registers, which are slow on older cores (Cortex-A9).

There are three places to lower the volume: ① inside reTONE, applied to the data (digital), ② the DAC's internal digital volume, controlled over USB, and ③ the knob or buttons on the DAC itself. reTONE chooses between ① and ② automatically, and asks you only whether ③ exists.

② Volume over USB: USB Audio Class has a volume mechanism called the Feature Unit, and GET RANGE reads its minimum, maximum and step size (in units of 1/256 dB). reTONE converts its volume (a single gain combining Android's steps and the fine volume) to dB. If it falls within this range, reTONE sends it to the DAC and keeps its own output at maximum. Only when the volume goes below the range is the shortfall applied to the PCM with ①. 0 is mute.

① Inside reTONE: For DACs without Feature Unit volume, reTONE applies the volume to the 32-bit data before sending it. It's applied right before sending, so the volume keys respond immediately.

③ The DAC itself: Whether the DAC has its own volume control can't be read over USB. So the first time you connect a DAC, reTONE asks once for "How the DAC's volume is set" (On the DAC / With the phone's volume keys / Not sure). If you choose "On the DAC," both ② and ① are fixed at maximum, and pressing the volume keys changes nothing (a message tells you so). With DACs that have an analog volume control, avoiding digital attenuation lets you get the most out of the DAC. The choice is remembered for each DAC model (USB vendor ID and product ID) and can be changed with the "DAC volume" setting.

When "On the DAC" is chosen, or when the DAC's volume is used (within the DAC's volume range), tracks at rates the DAC supports are sent without changing the data. Only when you set the volume below the DAC's range does reTONE apply the remainder. However, we can't check what happens on the phone or DAC side, so we can't guarantee bit-perfect output.

DSF and DFF tracks are sent as DSD, without conversion to PCM, only when the DAC supports native DSD and its volume can be controlled over USB. reTONE can't change the volume of DSD itself, so volume control on the DAC side is required. The player screen shows something like "DSD64 → USB AUDIO • DSD64 DIRECT."

It's sent as follows.

• Native DSD works with DACs whose USB descriptors include an alternate setting for raw data (TYPE I RAW DATA).
• DSD bits are packed 4 bytes at a time into a 32-bit word per channel, with the oldest bit at the top. DSF stores bits LSB first, so the bits are reversed before packing. Words are sent big-endian (the same assumption as Linux's DSD_U32_BE). This repacking is done in C, and the transfer ring buffer holds about 500 ms.
• The DAC clock is set to "DSD rate ÷ 32" (88.2 kHz for DSD64, 176.4 kHz for DSD128).
• Silence, pauses and track ends are filled with the DSD silence pattern 0x69.

This byte order and bit order were verified by correct playback on the DAC we tested. They haven't been checked with other DACs yet, and DoP (DSD over PCM) isn't supported. DST-compressed DFF can't be read either.

Sending DSD (setting): "Sending DSD" appears under "Sound" in settings only while a DAC that can use native DSD is connected. The default is "Send as DSD" (the DAC plays DSD directly), and you can switch to "Convert to PCM" (reTONE converts it to PCM). If DSD tracks cut out, or if you prefer PCM playback, choose to convert to PCM. The choice is remembered for each DAC model, and switching reopens the current track at the same position. We found a DAC that briefly cut out with DSD recordings whose modulation exceeded the 50% reference level. The transfer was normal, so this appears to be due to the DAC's design. Converting to PCM prevents the dropouts in that case too.

DSD → PCM conversion: When native DSD isn't used (with DACs that don't meet the conditions, when "Convert to PCM" is chosen, and for output to Bluetooth, earphones or the speaker), reTONE converts DSD to PCM in two stages.

• Stage 1: The DSD bitstream is decimated by a factor of 32, 64 and so on into PCM at about 88.2 kHz or higher (DSD64 by 32 to 88.2 kHz, DSD128 by 64 to 88.2 kHz). The filter is a Kaiser-window FIR filter. The passband extends to the larger of 20 kHz and a quarter of the output rate, the stopband starts at "output rate − passband," and the attenuation is 100 dB for 16-bit output and 110 dB for float and USB. The number of taps is determined by the Kaiser window formula. The calculation uses 16-bit table lookups, and the tables are built once per configuration and reused. In measurements, the response at 20 kHz was 0.000 dB, and aliasing below 20 kHz was −101 dB (100 dB design) / −110 to −117 dB (110 dB design).
• Stage 2: If needed, the same resampler described in the filter section converts once to the phone's output rate (such as 44.1 kHz or 48 kHz built-in output).
• Level: Converted so that SACD 0 dB (50% modulation) becomes −6 dBFS (a common convention; from 0.69.0. Earlier versions used −12 dBFS and played 6 dB quieter).

When sending PCM to a USB DAC, reTONE sends PCM at "DSD rate ÷ 32" (88.2 kHz for DSD64, 176.4 kHz for DSD128, 352.8 kHz for DSD256) as is, without the stage 2 conversion, if the DAC supports it. Because DSD is converted to PCM, DIRECT isn't shown in this case.

reTONE aims to "do nothing when stopped" and "draw nothing while playing with the screen off." Periodic work runs only during playback: every second with the screen on and every 5 seconds with it off, and the seek bar on the player screen redraws only itself every 250 ms. The clock and battery are updated by notifications from the system, without polling.

reTONE's CPU usage relative to one core on our 2012 test phone (Android 4.1, 2-core Cortex-A9).

• Stopped: 0%.
• Playing with the screen off: drawing stops. Tracks played with Android's standard playback use almost 0%, while tracks played by reTONE's engine (FLAC, WAV and others on Android 4.x) add the decoding and conversion load below.
• Playing with the player screen shown: about 2% (measured during actual playback; mostly seek bar redrawing, not including decoding).
• reTONE's engine outputting CD audio (16-bit/44.1 kHz) as is at 44.1 kHz: about 2%. Converting to 48 kHz for output: about 4%.
• Converting 24-bit/96 kHz to 48 kHz: about 5%. To 44.1 kHz: about 7%.
• Converting 24-bit/192 kHz to 44.1 kHz: about 10% (calculation only) to about 15% (rough estimate of the total playback load, scaled to maximum clock).
• Sending 24-bit/192 kHz to a USB DAC without conversion: about 20% (measured during actual playback, screen on, including the transfer thread).

The engine figures from "CD audio" to "24-bit/192 kHz" come from running the same calculations at full speed at maximum clock and converting them to a percentage of real time. During actual playback the phone lowers its clock to between 200 MHz and 1 GHz, so the figures shown on the phone look 2 to 3 times higher (20–29% for 24-bit/192 kHz). How the code is written also makes a big difference: the current implementation in C and NEON had about a third to a fifth of the load of an earlier prototype written in Java.

For DSD-to-PCM conversion, with that 2012 phone and a battery-powered DAC, converting DSD64 to 88.2 kHz PCM and sending it over USB took about 11.8% for the conversion and about 5.8% for the USB transfer (at about 1 GHz). When DSD64 played through the built-in output (48 kHz) on an Android 4.4 phone, the decoding thread used 23.8%, but the phone kept its clock at the minimum 300 MHz, so simply scaling by the clock ratio gives about 3% at maximum clock.

On the phones we tested, the load while the screen was on depended more on screen resolution than on CPU speed (Android 4.x appears to redraw the whole screen even for small updates). A 1080 × 1920 phone used about 4% on the player screen, and a 1440 × 3120 phone running Android 11 used about 8.5% (relative to one of its 8 cores; about 1% of the whole phone). Older phones have small screens and high-resolution phones have more processing power, so for now the redraw rate is the same on all phones.