I wouldn’t draw that conclusion based on the specs. M1 has massive bandwidth capability, both memory and storage. It far exceeds the requirements put on it by audio playback, DSD256 included.
Even with a modest pre-load cache, it should be able to fetch new data fast enough to avoid interruption in playback.
Empirical evidence from @Dandaman would suggests otherwise. Further information is necessary to reach conclusion. It’s something for Audirvana team to look at.
…
I completely understand the potential throughput capabilities of the M1 system bus architecture… However, when the available system RAM is consumed by both the macOS and Audirvana processing DoP 1.1, it will not matter how fast the data bus may be… the I/O request interrupts for memory caching to the SDD, clocking related errors and error-correction requests, etc, will increase… I understand the M1 platform has great capacity… However if you are basing your presumptions regarding audio processing power, on it’s video processing capabilities, you must account for the dedicated graphics sub-processing in the GPU (Graphics Processing Unit)… If the M1 MacMini had a dedicated Audio Processing Unit (APU) 
then I would agree with your presumptions.
I completely understand the M1 SoC capacity with multiple channels of PCM audio data… However I would never run large Logic Pro sessions with 8GB of RAM and expect the recordings and processing to run flawlessly.
I’m basing my perspectives from my own empirical evidence acquired over several decades of working with digital audio systems and files on a several iterations of Apple Macintosh platforms, working with PCM recording and production with Logic Pro and various other DAW’s and more than a decade of DSDxxx playback via DoP 1.1 using PureMusic and Audirvana Studio, on my MacBook Pro’s with 16GB of RAM and having my Logic Pro session files and my music library drives on the Firewire bus and the USB bus where it now resides on the USB 3.0 bus of my 2016 MBP quad-core i7…
Over the years, I’ve experienced all of the digital-audio gremlins associated to a system platform’s memory availability, throughput restrictions of a given platform configuration and the performance detriments and attributes in sound-quality and playback performance from a given system platform and configuration of amalgamated components.
I agree that my perspective may not be the ultimate conclusion… As I stated… it may be one conclusion… There might be other factors at play… However available system memory is the first place to start the investigation in the context of flawless Audirvana DSDxxx / DoP 1.1 processing and playback, from my experience.
If the system can be used to edit 4K video, it surely can play DSD256. There’s no question about it.
I also wouldn’t advise anybody to run large Logic sessions on 8GB of RAM. That’s a bit different from simple playback of pre-recorded content.
Just purely looking at the capabilities of the system, it should be able to play DSD256 without issues (and probably stream 4K video in parallel). The question is why is Audirvana choking on it. Would be interesting to try playing the same content with another M1 (ARM) native app.
…
Yes it should be able to handle any DSDxxx flawlessly… I keep reading problems with M1 mac’s with 8GB having playback problems… We don’t see owners of M1 Mac platforms with 16GB or more, reporting DSDxxx playback issues.
You can’t compare the video processing capabilities because of the dedicated GPU processing that handles those video streams… There is no such Audio Processing Unit in any Apple platform or any computer platform outside of Pro Tools, Pyramix systems and the Sonoma DSD systems, etc.
It could be that there are fewer of those around.
Have you tried playing a big DSD file, then after one second of playing, pause it, then just see the buffer bar advance to it fully loaded, then hit play again and see if it plays well.
Also if i was you, i will have put the buffer at the basic setting Audirvana put it by default, with 8gb of ram it is around 5500 to let macos have 2.5gb for itself. This is for none upsampling or plugin involve.
The faster it loads in memory the less problem should occurred i think, after it is supposed to play from memory, you can remove your external hard drive, the song will continu to play 
…
I must challenge these suggestions, base on my experience playing DSDxxx (DoP 1.1) in Audirvana on my 2016 MacBook Pro with 16GB when not having enough pre-load memory allocated… I get predictable drop-outs directly correlated to the available pre-load memory… I have found flawless playback of DSD128 using 11,710MB of pre-load memory… lower than this, I will most certainly get spurious drop-outs, depending on the track file time…
In regard @bitracer 's response below regarding not seeing 16GB M1 platforms reporting problems:
Well… My 2016 MBP quad core i7 with 16Gb, would be empirical evidence of the need for more RAM, it is certainly less capable than the M1 SoC MacMini…
For reference, in regard to DSDxxx (DoP 1.1) processing:
DSD64 sample-rate is 2.822MHz and requires a 176.4kHz PCM signal for DoP 1.1… the sample-rate is double for DSD128 at 5.644MHz, requiring a 352.8kHz PCM signal for DoP 1.1… the sample-rate for DSD256 is 11.288MHz requiring a 705.6kHz PCM signal for DoP 1.1…
It depends, the UMA architecture should require less RAM.
…
This presumption would need corroboration in this context of macOS + Audirvana DSDxxx DoP 1.1 processing on a 8GB M1 SoC MacMini or other 8GB M1 platform…
It’s a general consideration. Maybe Audirvana is not leveraging properly the UMA architecture, but that’s just speculation.
…
I’m not a programmer, however know a bit about signal flow, etc, on the Apple platform audio API’s, so might be off-base here:
It seems obvious that the Core Audio and/or MediaPlayer API’s would access the M1’s unified memory… not Audirvana directly…
If Audirvana was having problems accessing the DSDxxx files on the storage device and loading these DSDxxx files into the DoP 1.1 processing RAM cache and the RAM buffering of processed DoP 1.1 data to the various output buses, it would have problems with all audio file types because all audio data flows through the Core Audio and/or MediaPlayer API’s…
I have been watching the conversation thus far. What I notice is this: on a DSD file, no matter what amount of RAM I give the buffer 1) the dropout occurs when exactly 50% of the buffered music has been played, and 2) the buffer never replenishes until the 1st dropout occurs, THEN it immediately starts replenishing. I compared this with a long FLAC 192 kHz and it filled the buffer until full (again with 12:48 of playing time) and played until just a few seconds before reaching the same 50% mark of 5:48, when the buffer began replenishing and the music never experienced a dropout. So whatever is supposed to cause the buffer to replenish when approaching the halfway point works with all file types I have except DSD, and those hit the brickwall of an used-up buffer before replenishment happens.
Just for clarification purposes, What DSD file type you are playing? Are these “.dsf” files or are they “.iso” files? Also… if they are .dsf files, were these extracted from an SACD .iso file?
…
Here is some information that corroborates the need for more system RAM for flawless DSDxxx (DoP 1.1) file playback:
Using the Audirvana integrated pre-load buffer memory allocation analysis read-out/report:
4000MB (4GB) of pre-load memory =
Combine this with the size of both the incoming DSDxxx file being cached for DoP 1.1 processing and the size of DoP 1.1 processed signal output buffer… It is fairly easy to see how available system RAM is essential for flawless DSDxxx (DoP 1.1) playback and for uninterrupted DXDxxx playback (Dependent on track(s) length)
This is just when the macOS platform is doing nothing else but supporting Audirvana file playback to a single DAC… Just imagine when other system components and operations are active, like Ethernet wired network management of multiple audio devices on the network and/or Wi-Fi, etc clients on the network…
Note: –
ISO files extracted from SACD are notorious for causing resets in the playback DAC due to gaps and zero crossing errors from bad extraction processes, even if they have been converted to .dsf files.… These .iso files must be extracted at the recorded sample-rate of DSD64 2.82MHz and they generally need to be edited to minimize “clicks”…
Reference:
The file was from the album “Gatti Mahler 2” purchased as a .dsf DSD128 download from ProstudioMasters.com back in 2018. I have continued testing various files and I’m coming to the conclusion you have, namely 8 GB RAM turns out to be too little for some .dsf files. So I may wait to see when the M2 mini becomes available & get one of those with more RAM. Thanks to all for the help.
Looks like a bug to me. Audirvana makes the assumption that there is still music cached based on the amount of data it loaded, but in reality it’s just the padding in the DoP package. That’s why the music stops.
Audirvana is accessing the Core Audio and/or MusicPlayer API’s and making calls to the audio-files library storage device, while processing DoP, etc, and managing the output data flow to the Core Audio and/or MusicPlayer API’s output bus controller(s)… A single raw .dsf DSD128 track file of an average length of time, can be three-quarters of a gigabyte or more in size (@750MB give or take)… The system RAM demands are being taxed by all operations of the host macOS and Audirvana.
You may be making presumptions based on the M1 SoC memory bus throughput-speed specification and CPU’s clock speed and PCI bus throughput… All operations demand and absorb clock time and RAM … If there is inadequate system RAM to support the audio-data caching for DoP processing and the output buffering memory for the post DoP processing data, there will be data anemia, which will precipitate gate interrupts and resynchronization request delays and buffering delays.
I don’t buy the idea that 16GB M1 platforms users are so scarce that we don’t see them posting issues with DSDxxx (DoP 1.1) playback on their 16GB M1 platforms.
Having to buy a system that can cache the longest song at DSD256 with 50% utilisation can’t be the solution. Something’s up with the caching implementation on M1.
I think too, when no upsampling or plugins involved, Audirvana should play all those files flawlessly… maybe those french holidays will end up soon to react here