Unusual playback experience

Studio
1

During a playback of an album of 14 tracks of 24 bit/352.8kHz files (up-converted to DSD128 with SoX) (72.11 minutes total length) I experienced at approximately 65 minutes into the album (track 11, approximately 1:17 into the track) a complete drop-out or loss of sync of the signal data which resulted in full-code “hash”… Not a happy experience saying the least, because I was unexpectedly caught off guard, having never experienced this with Audirvana Studio in previous listening sessions… Or for that matter, in a long, long, long time, having experience with digital audio playback and sync issues that created digital hash in the symbiotic connection between my audio interfaces connected to my music production DAW…

It was not a spurious “glitch” as I was able to repeat the incident at exactly the same location in the track, so my initial reaction was that the track file had been corrupted or some other glitch in the playback… I closed and relaunched Audirvana Studio, powered my DAC (after shutting it off to prevent damage) and proceeded to the suspect track and initiated playback… and at exactly the same time-point into the track, the drop-out or loss of sync occurred again… At this stage, I deleted the track from the album folder (moved it to the TRASH) in my library HDD and replaced it with a fresh download of the suspect track from the site it was purchased… I relaunched Audirvana Studio, re-synchronized it with my library and initiated playback of the track… The hash event was produced again at exactly the same time location in the track.

At this point, I began to suspect something else was causing this recurring hash event at this time-location in the album playback… I began to wonder if it had something to do with the caching of the files after playback, and it’s relationship to the total available playback pre-load RAM, since this was a long album of 24/352.kHz files being up-converted to DSD128 in S0x and my playback buffer was set to approximately 6Mb…

I then thought that maybe, it was a cache buffer that had reached it’s maximum capacity and caused an interruption in the playback sync… I subsequently proceeded to exit from Audirvana Studio, shut down my DAC and shut down my MacBook Pro and start it from a cold boot, power ‘on’ my DAC and relaunched Audirvana Studio and initiated playback of the suspect track and it played completely through with no interruption as would be normally expected!

This brought me to a question about caching… “How much cache does Audirvana Studio retain after a track or several track have completed playback?” It seems that when only restarting Audirvana Studio after trashing the suspect track and emptying the trash, and subsequently replacing it with a fresh download, that the ‘old’ (perhaps corrupted) file was playing from the playback pre-load buffer RAM… even after resynchronizing the database. And only after shutting down the computer and starting from a cold-boot, this cache was cleared and I was able to play the refreshed track file.

So, was it a corrupted file or is it a caching/buffering issue? … I’ve increase my playback pre-load RAM size to around 9Mb… I’m a bit reticent to try a full album playback yet, until perhaps I can get some feedback on this experience, so to get a better grip on the potential causation(s)… I’m leaning in the direction of a corrupted file, however, the experience of the repeatedly recurring hash experience, after trashing and replacing the suspect file and “restarting” Audirvana Studio, versus, completely shutting-down my MacBook Pro and starting it from a cold-boot, to only then, have the freshly downloaded, suspect file, playback correctly, without interruption, is disconcerting, leaving me to question “why?”

Any feedback regarding this experience will be appreciated and welcomed.

2

Have you tried the same playlist without upsampling?

3

No… Why would this make a difference? I have other 24/352.8kHz albums that I play routinely, being up-converted to DSD128 and have never run into this behavior, however, they are shorter in length… It seems to be related to the total time of the album of files…

4

Or a corrupted file…

5

There might be some memory leak with the upsampling algorithm. It’s a first troubleshooting step to disable the upsampling and check it that solves the problem already.

Another potential cause of this could be the computer entering stand-by. Are you sure it didn’t enter stand-by?

6

System Optimizer is enabled… and a stand-by interrupt would be random anyway…

I’m able to play the file now just fine… It probably was a corrupted file and after replacing it with the refreshed file, for some reason, the corrupted file was playing from the buffer until I emptied it by shutting down the computer and and starting it from a cold-boot so the album was reloaded into the pre-load buffer RAM… This is where it becomes a question of caching…

7

You should not have trashed the file that you suspected to be corrupted, but stored it somewhere on your drive. You could check then if it can play correctly with AS or another player, and better understand what happened.

8

Thanks for the input… Yes, it might have been helpful…

However, the suspect file would never play correctly in any scenario short of refreshing the suspect file and shutting-down and starting my computer from a cold-boot… This is the only thing I did not try with the suspect file still available in the library folder… I restarted the computer and it didn’t change the interruption behavior at that particular point in the track… Not until the cold reboot with the refreshed file in the library folder did the refreshed file play correctly, which alluded to the audio-engine still drawing from the pre-load RAM cache the ‘old’ corrupted file…

9

Maybe the cache was corrupted, and not the file. You did not try to play it with another player.

10

Yes… I presume this would have provided more insight… However, it does seem the player was drawing from existing, pre-load buffer RAM of the ‘old’ file, as the interrupt occurs at exactly the same time-location of the track every time it is played…

11

And if I understood correctly what happened, the player interrupted the fresh downloaded file also in the same time-location. So it’s very possible that the cache that it was playing was corrupted.

12

Well… I don’t know if it was playing the refreshed file or the previous cached data of the ‘old’ file… This is the question… We would presume that a new buffer of the file is created when it is played, however this does not seem to be the case…

13

If AS was playing the fresh downloaded file and not the old cache, it should have continued to stop the playback of this track at the same place, even after the cold reboot. Don’t you think so?

14

The refreshed file did playback completely without interruption after the cold reboot… and continues to do so, in subsequent playbacks… this is why I suspect the ‘old’ file was corrupted and the audio-engine was drawing from the previously acquired pre-load file data…

15

OK, but there are only two possibilities for what happened. Either the file that you trashed was corrupted or its DSD128 upsampling that was cached was corrupted.

16

What is plainly evident is the audio-engine is drawing from previously cached pre-load data that has not been cleared yet… I don’t see how the up-conversion buffering would be cached and retained… this would be prohibitive in the context of total accumulation of data in this scenario… It just doesn’t make sense to me that the up-conversion data buffer is cumulative and retained… I’d expect this to be overwritten upon each subsequent file conversion…

17

It’s very possible that you are right.
It’s a pity that you did not think to play the track with another player, before trashing it. Though, even if it was played, it would not have completely eliminated the possibility that it was corrupted. A track that has a problem may be played sometime with one player, that can be more tolerant, but not with another.

18

In this case it was not a spurious drop-out… It was a catastrophic failure resulting in full-code hash… I was lucky to react quickly to turn off my DAC… I’m still concerned about the total data accumulation of this album of tracks…
Edit:
"with approximately 9Mb of pre-load buffer RAM, this gives me approximately 25 minutes of buffer at 24/352.8kHz (As determined by the Audirvana Studio pre-load buffer calculation for 24/384kHz files) for the 72.11 minutes of source files alone, which calculates to 8.89056 GB (gigabytes)"
[source calculator for total data: Audio File Size Calculator]

19

UPDATE:
I’ve just completed an audition of the album of tracks in it’s entirety without any interruptions from beginning to end and especially in the track under scrutiny in this event. As noted in my previous posts, I’ve increased my pre-load RAM buffer to approximately 9MB and nothing else, outside of the afore mentioned refreshed download of the suspect track.

I will note here, that in my prior audition which precipitated the catastrophic full-code hash event, I had been playing two albums of 16/44.1kHz files being up-converted to DSD128 (with approximately 6MB of pre-load RAM buffer) and I don’t remember the length of these albums. So, in the context of my original post experiences case, I don’t know how much of the pre-load buffer memory the 16/44.1kHz files occupied, prior to the initiation of the 72 minute, 24/352.8kHz album playback… if it had some influence on the behavior that I experienced.

My questions still are regarding the playback buffer caching and if this is something that must be considered when playing large albums of DXD files of great total length, being up-converted to DSD128 or not, and is buffer RAM allocation inconsequential to the operation of the playback engine architecture in this scenario, outside of CPU request demands/interrupts and playback fidelity?

Or, is this a case of the pre-load RAM buffer cache still holding the corrupted file, and the file manager routine not recognizing the change in the album tracks, only seeing the corresponding track number already stored in memory and not realizing it must reload a new buffer of the refreshed file?