This question plagued me when the new plexamp settings came out as well, so I decided to do some testing with the equipment I have on hand. This is a fairly in depth dive so it’ll be a bit (see what I did there?) of a read.
Plexamp Settings
For such a test to be meaningful (and pass), all of Plexamp’s fancy (very cool Elan) DSP-based features must be disabled. Each of these features affect the digital bitstream in some way and will therefore cause any of the below tests to fail miserably. These features included Loudness Leveling, Sweet Fades, Equalizer, and Music Playback Speed adjustment.
Bit Test
I was able to confirm this on macOS after assuming a few basic things:
- The sample rate is matched using the latest “sample rate matching” setting
- The audio device is set through Plexamp’s audio device setting
My DAC through USB is the RME ADI-2 DAC FS (v1 with the AKM chip). The ADI-2 has a unique feature called “Bit-Test” where, if the DAC sees a specific stream of bits that RME provides for download, it will display a message. RME provided files for:
- 16bit/44.1KHz
- 16bit/96KHz
- 16bit/192KHz
- The respective 24-bit versions of all of these
- The respective 32-bit versions of all of these
A browse through the menu suggests that even an alteration to the LSB (least-significant-bit) on any of these files would cause the bit test to fail.
macOS Audio MIDI Setup shows the RME ADI-2 DAC FS as running in 2-channel 32-bit Integer mode and does not allow this to be changed. Source is Default and the ADI-2 is using its internal clock source (as per the display).
All 6 files were loaded into my Plex server and Plexamp and were run as is. For all 16-bit and 24-bit files, the ADI-2 displayed passing on the Bit Test and therefore suggests that Plexamp is able to pass these files bit-perfectly. The sample rates on all the bit test files matched on the DAC as what was being played; note that the Bit Test would fail if there was any re-sampling involved either upsampling or downsampling.
However, Plexamp failed the 32-bit Bit Test. Instead, the DAC displayed as only passing 24-bits. Thus, it seems that either Plexamp’s audio pipeline (or CoreAudio?) is dropping the final 8 LSB’s of the word and falling back to only passing 24-bits. I blame this primarily on Plexamp’s audio pipeline, since CoreAudio (via MIDI Setup) appears to properly negotiate the ADI-2 to 32-bit integer capable.
Note, the same tests were repeated on iOS on my iPad Pro via a USB C to USB A cable. The results were identical. I was not able to pull the exact word length (bit depth) that the DAC was running on through iOS since neither the software nor the DAC itself displays this information. Instead, I had to rely on the bit depth that the DAC displayed upon passing Bit Test.
MQA Support?
As a final bit of torture (read as, investigation) for @elan and guys over at Plex, I decided to try out some MQA and see whether it would be passed properly. The equipment changed a little bit here, swapping the RME ADI-2 DAC FS for the Khadas Tone2 Pro. The T2P is an MQA capable DAC that can handle all three MQA processing stages (rendering, decoding, and third unfold). The T2P provides an RGB indicator for MQA type and support, separating out MQA OFS, MQA Studio, and MQA Native (just called MQA).
My library contains a fair bit of MQA files, so I was able to get a broad suit in for testing. In short, Plexamp is able to pass the MQA data stream, assuming the OS does not interrupt it at any time.
Initial test tracks for integrity were Trigger by Seori [MQA Studio 44.1/48KHz], Lovers in the Night by Seori [MQA Studio 88.2/96KHz], and Getting Older by Billie Eilish [MQA Native 44.1/48KHz]. These three tracks were chosen to show multiple types of MQA support. All three tracks initially negotiated into PCM, but immediately renegotiated into their respective MQA formats as indicated through the LED on the T2P. Tracks continue to remain negotiated @ MQA throughout playback.
Of note, when system sounds are played through the same output device, MQA negotiation is seamlessly lost. However, as soon as the system sound is over, MQA re-negotiates successfully after a brief 1 second delay. This is NOT a drawback of Plexamp but rather a result of MQA’s metadata riding on the LSB of the PCM data stream. In fact, this shows that Plexamp will pass bit-perfect and successfully recovers to bit-perfect even after being interrupted by a mixed in CoreAudio stream. This is, in my opinion, a resounding success and the exact expected behavior, knowing the details of MQA metadata.
Identical test results occurred on iOS using the T2P.
Sample Rates
As @elan and team is already aware in a previous post, Plexamp matches sample rates “opportunistically” rather than after every track, in current behavior on 3.7.1. However, in a heterogenous sample rate playlist, MQA support (and similarly bit test passage) fails due to a mismatch in sample rate. This can only really be remedied by having Plex match sample rate on a track by track basis rather than opportunistically.
Here’s to hoping that the team will add a new option for that in the next or near future release.
No testing was done on Windows or Android as I do not have easy access to any such devices.
