MusicKit is just a framework to simplify app development for Swift users. It’s built on top of the Apple Music API which is platform agnostic.
1 Like
After some trial with various devices, I settled on my iPad Pro with split screen view and a USB-C to USB-B connection into the Bartok. Works for now, but of course would prefer a Mosaic native integration.
deleted by user
Deleted. Moving conversation to RME forum. See below.
Very interesting, thanks for posting.
However, I’m guessing there must be something wrong with the test set-up. While I haven’t tested it lately (and I’m away on a business trip so can’t test this out at the moment), I know for a fact that Apple Music (the App, not the Service) has no issue with bit-perfect redbook transport of local files, especially on iDevices.
So, this test case you outlined must have something going wrong with it… 
What did you use to convert the RME test files to ALAC?
… duplicate post
Deleted. Moving conversation to RME forum. See below.
Double check Optimize Storage, EQ and Sound Check are all off in the Music app’s Settings on your iPad.
Also note that the volume control will affect playback; I’m not sure what volume setting is unity gain.
Note also there are separate volume settings for the iPad and the Music app.
Also make sure
Sound & Haptics → Headphone Safety → Reduce Loud Sounds
is off.
Deleted. Moving conversation to RME forum. See below.
You mentioned previously (or perhaps it was your deleted post) that you used XLD to convert from .wav to .m4a (Apple Lossless)
I just tried using XLD to convert RME’s test .wav file to .m4a and then back to .wav - the original and reconverted .wav were the same size, but the files don’t match (just using MacOS “diff”).
So, I took a closer look at both, the “musical content” was the same - grouped set of 6 impulses. So, it must be just differences in the headers, but not knowing how RME’s bit transparency test actually works, could this be the problem?
The Apple Music app also supports natively importing .wav files (set in the App’s Preferences), and it does so completely transparently; the imported file remains as a .wav and is bit-for-bit identical to the original .wav file.
Maybe try importing your RME test .wav files directly into the Music App as .wav and see if it makes a difference to the transparency test? 
Deleted. Moving conversation to RME forum. See below.
Ahh, right, you mentioned this before, which I missed.
Hmmm…
At the risk of stating the obvious, since it wasn’t explicitly mentioned in any of your posts so far, are your iPhone/iPad Music App preferences set to Lossless?
I’ve deleted my posts above describing the test procedure to determine whether the Music App on MacOS and iOS delivers locally stored music files bit perfectly to a USB DAC.
Given that the test procedure involves a 3rd Party DAC and test files (RME ADI DAC 2 fs), the most logical place to validate the test is with the RME community. You can follow the conversation at the link below.
Thanks to @Anupc and @BillK for your suggestions. I’ve included these in the revised test procedure.
So I’m not crazy - see the latest posts in the RME thread.
Apple Music itself does some dithering or watermarking. https://www.youtube.com/watch?v=fGLbXsf5gZE
Did it not require 5V external power for Bartok? Vivaldi doesn’t recognize without 5V power thru USB so have to add a powered external USB hub into the mix, too many connections.
I don’t care 24/192K content on Apple music, Tidal/Quboz are better for it, however, does Airplay to dCS network devices play Apple lossless content as ALAC?
Unfortunately, Deezer, Quboz and/or Tidal don’t have content that Spotify and Apple music carries. Spotify has the most and next closest is Apple music. I read Apple music via Airplay plays as AAC and not ALAC though the content is marked loseless. Is that the same with dCS devices too?
Thanks,
Prasad.
With LosslessSwitcher installed, the Mac sample rate is automatically changed to the one of the song playing in Apple Music.
I can go to Audio MIDI settings while the track is playing and hear what it sounds like upsampled from bit-perfect 44.1 kHz to 88.2 or 96 kHz. I always prefer what Apple does with the 96 kHz upsampling. It sounds the best when upsampled again to DSDx2 and the signal then reaches the Utopia22 via the unbuffered inputs on the Lina HeadAmp. The clarity and transparency of these inputs adds to the Apple Music sound and soundstage, I find. Otherwise there is too much noise revealed for my taste.
I also tried bit-perfect in Qobuz and Tidal in their apps and in Mosaic. With other headphones and other XLR cables than what I use and the buffered inputs on the Lina HeadAmp or a 2-channel system these two music apps may work better.
There is some discussion on re-sampling with integer and non-integer ratios here: https://www.audiosciencereview.com/forum/index.php?threads/upsampling-integer-vs-non-integer-ratios-original-samples.27989/
And here by danadam: https://www.audiosciencereview.com/forum/index.php?threads/mqa-a-review-of-controversies-concerns-and-cautions.2407/page-71
1 Like
From Apple‘s support site on some Macs introduced after 2022 https://support.apple.com/en-my/108326
“Compatible Mac computers feature a high-quality, built-in hardware DAC that can convert up to 96 kHz digital audio to analogue audio.
[…]
“To set the sample rate for the headphone jack, use the Audio Midi Setup app,…, select External Headphones, then choose a sample rate from the Format pop-up menu. For best results, match the sample rate for the headphone jack with the sample rate of your source material.”
Apple actually expects users to select the matching sample rate manually for each track. Apparently they can’t be bothered to build an automatic feature like LosslessSwitcher into the MacOS.
1 Like
BTW, with the Lina Master Clock off, bit-perfect sounds much better than 96 kHz upsampled ALΑC on the Lina. I tried to make sense of why everyone is so put off by Apple Music not being bit-perfect from a Mac to a DAC (unless LosslessSwitcher is used) and why even Apple recommends to match sample rates to the source material.
At the same time, danadam shows in the second link above how non-integer resampling can actually retain perfect analogue reconstruction of a digital signal within the Nyquist limit of the lowest sample rate involved and I much prefer the sound of upsampled 96 kHz ALAC. With the Master Clock off, upsampled 96 kHz ALAC sounds a bit horrible, I found out, but with the Master Clock on, one can turn up the volume even more and it sounds so clean and detailed.
Edit - I finally figured out the conundrum. I switched to 6V on the Lina DAC, I was using 2V ever since I got it, and bit-perfect ALAC sounds much better. There is noticeable degradation in SQ when upsampled by Apple. I’m so glad there is LosslessSwitcher because I really like the soundstage of ALAC. Otherwise I would have gone with Tidal or Qobuz.
Not sure if that’s what you actually meant, but even Apple does not “upsample” ALAC; it sample-rate- converts LPCM from decoded ALAC. After which it directly D-to-A converts to the internal speakers, or recode back into ALAC if output over USB to a DAC.
Not surprising, it’s a pretty rudimentary sample rate converter. I wouldn’t call what Apple’s Core Audio does “upsampling” 
1 Like
Thanks for pointing it out. I should have said “resampling.” “Upsampling” was a sloppy use of the word in this context.
In case anyone is interested, the DAC Apple uses in the MacBook Pro with an M3 chip is nowhere near the quality of the AudioQuest DragonFly Cobalt. It’s actually quite bad in comparison to the DragonFly.