In playback of local DSD files I get dropouts at regular intervals and those intervals are directly affected by the amount of buffer RAM I choose. For example, if I set the buffer at a minimum value the dropouts may come at about 1:40 of play time & then at 3:20 & then 5:00 & so on. If I then double the buffer RAM they will occur at about 3:20 & then 6:40 & then 10:00 & so on, This continues until I have no more RAM to give it. I’m using an M1 Mac Mini reading files on an external hard drive connected with a Firewire 800 cable to an Apple brand Firewire to Thunderbolt 2 adapter to an Apple Thunderbolt 2 to Thunderbolt 3 adapter into the M1 mini. This works fine for non-DSD files & even a 352.8 kHz DXD file. It works fine for non-DSD files while employing Hang Loose Convolver audio units. It’s only DSD files that are affected. Is the buffer in Studio not re-loading as it should, i.e. an Audirvana problem?
Are you upsampling to DSD or playing native DSD files?
playing native DSD files. DAC is an Exasound e-22 which play DSD up to 256.
Put some native DSD files on the internal storage. Mount that in the library and try to play it.
That was a good idea. I found that even playing on the internal ssd of the Mini, it still had the dropouts.
…
Never, ever a good idea to put your library files on the same storage device (SDD) that the macOS system resides…
How much system RAM do you have in your M1 MacMini?
Try allocating approximately 11,000MB of pre-load memory… I use 11,170MB… Make sure you are using DoP 1.1 for DSD transmission to your DAC…
It’s possible the Firewire throughput is the bottleneck, this is why the suggestion to put files on the System SDD… If you have a faster connection, like SATA or USB 3.0 use that.
Bitracer said *some * files, not the entire library. In fact I put one known offender ( a 20 minute classical track) on the internal disk while dismounting the external drive. That was enough to tell. I have a base M1 mini with only 8 GB of RAM because I’m not upsampling and it’s a dedicated music mac not doing other things. From what I’ve read that should be enough, though I will concede it’s possibly a cause. I sort of lean towards the Firewire with adapters possibly being the bottleneck. I wondered if anyone else using an M1 mini could share their experience with 8 GB. As to the firewire and adapters, I already had the Firewire enclosure so wanted to see if a couple adapters would work for a minimal cash solution. If no one else has input, I may look at a 16 GB mini, especially when the M2 variant arrives. Also I’ve often heard to keep away from other USB connections when using a USB connected DAC. I formerly ran with a 2008 Mac Pro with 16 GB ram & it had no issues.
Looks like a bug to me. Antoine will have to try to replicate this once he’s back.
…
It’s more likely the Firewire 800/400 throughput, not the adapters…
I’ve been reading here from owners of M1 MacMini’s with 8GB of RAM, having playback issues… The DoP 1.1 DSD files are very large and require a lot of preload memory…
As I showed in my previous response, I use 11,710MB of pre-load memory (11.43GB) I need to do this to insure flawless playback of DSDxxx files… In Audirvana Studio, all PCMxxx is remodulated to DSD128 via SoX after processing with 112dB’s Redline Monitor Audio Units plug-in, and I playback Binaural DSD128. (2016 MacBook Pro, quad core i7, 16GB RAM, macOS Monterey 12.4) My USB 3.0 7200 rpm HDD is connected to the USB 3.0 bus and my DAC system is connected to the USB 3.1 bus of my MBP… My DAC is fed via USB 2.0 after passing through an iFi Audio iGalvanic 3.0 on the USB 3.0 bus. (I’m simpifying my system configuration here, as it is more complex…)
I’ve read that M1 Mac’s require @ 4GB RAM to run the macOS system efficiently.
Still, it should continue fetching data. There’s no reason why it shouldn’t work on 8GB M1, especially since no funky processing is going on.
I don’t subscribe to the dogma that internal storage should not be used for the library. With SSD drives it shouldn’t make any difference. If anything, it should be better.
Of course it will continue to fetch data… @Dandaman has no problem with smaller PCMxxx and DXD 352.8kHz… It’s the very large DoP 1.1 files that are getting interrupts… If you have read my posts regarding DSD playback you will notice that I use 11.4GB of pre-load memory…
Using an example of one of my Binaural DSD128 DSF track files which is 730MB in size… This is going to be interleaved into a PCM 352.8kHz file as a DoP 1.1 file… Imagine how large a DSD512 or DSD256 DoP1.1 file is…
The DoP 1.1 interleaving process demands more memory from the system… If the macOS system needs approximately 4GB to efficiently operate (meaning it does not need to cache much to available RAM or the available SDD memory) this leaves approximately 4GB for application memory usage… I can imagine scenarios with DoP1.1 processing requiring a lot of RAM and potential system interrupts for fetching and writing data…
If one is not concerned about producing the highest quality of digital-audio playback, then it matters little if the music library exists on the macOS system drive…
If one is concerned about the system interrupts induced by data fetching and or writing, of large high-resolution digital-audio files, and the ripples induced into the system architecture these interrupts precipitate, then one would never, ever, consider storing music library files on the macOS system drive…
Still, from the internal storage it should be able to fetch DoP fast enough to avoid interruptions, even at DSD256. There’s something that doesn’t add up.
I would consider it, if the internal storage was big enough. The same “interrupts” occur when accessing external storage.
I could understand if the internal drive used old school spinning platters, but with fast SSDs it doesn’t really matter.
…
This is not true… external TB and USB and SATA buss controllers are separate from the PCI-e bus that the internal SDD drive exists on (as is the case of my MBP with 512 SDD) where the macOS system resides on.
It doesn’t matter, interrupts are still generated. USB buses eventually terminate on the PCI.
…
Yes… they eventually flow to the PCI-e bus… However, the external bus controllers have buffers to handle the interrupts and minimize the clocking errors… In my system, this is a major aspect in the data flow integrity… maybe the M1 CPU has enough integrated RAM to manage interruptions precipitated by requests… However, it seems that there are some issues with M1 platforms with 8GB of system RAM, based on the issues I’ve read about here on the forum…
M1s have UMA. Maybe it’s related to implementation issues specific to this architecture. The throughout capabilities are more than adequate. It’s a guess. Audirvana team should know this better.
Anyway there is no inherent advantage to using external storage opposed to internal well integrated storage. Other than lower cost of external storage, that is. This is even without taking into account the swings on the power rails caused by the power draw of the external drives.
The power noise ripples would be an issue if powered by the buss controller… Power supply noise is always a problem in a system architecture… The power-signal induced noise injected from an external drive power-supply, can be managed easily…
EDIT:
There seems to be an issue with 8GB of UMA being enough to handle both the macOS system and Audirvana processing DSD for DoP 1.1
[(July 13) I removed some of my statements from this post…]
… @bitracer , @Dandaman
From the Wikipedia article: Apple M1 Apple M1 - Wikipedia
Memory
The M1 uses 4,266 MT/s LPDDR4X SDRAM[19] in a unified memory configuration shared by all the components of the processor. The SoC and RAM chips are mounted together in a system-in-a-package design. 8 GB and 16 GB configurations are available.
The M1 Pro has 256-bit LPDDR5-6400 SDRAM memory, and the M1 Max has 512-bit LPDDR5-6400 memory. While the M1 SoC has 68GB/s memory bandwidth, the M1 Pro has 204GB/s bandwidth and the M1 Max has a 408GB/s bandwidth.[10] The M1 Pro comes in memory configurations of 16 GB and 32 GB, and the M1 Max comes in configurations of 32 GB and 64 GB.[20]
The M1 Ultra doubles the specs of the M1 Max for a 1024-bit memory bus with 816GB/s bandwidth in a 64 GB or 128 GB configuration.
One conclusion that may be drawn from the M1 SoC specs in concert with the anecdotal evidence produced in similar issues stated here in this forum, by other M1 platform users with 8GB unified memory, is:
An M1 MacMini or any M1 platform with 8GB of unified memory RAM is inadequate in handling both the macOS and platform component demands and the Audirvana audio playback-engine demands of processing DSDxxx via DSD over PCM 1.1 (DoP 1.1) while supporting enough pre-load memory for flawless DSDxxx (DoP 1.1) file playback, when both systems are loaded into the System memory of the M1 MacMini.