I just noticed momentary playback interruption when selecting a track to “Play Next” in the cue… I don’t do this regularly, however noticed this in version 2.5.0 and again in version 2.5.1 the other night, so I don’t know how long this behavior has existed. The interrupt occurs when selecting “Play Next” directly in Audirvana Studio or remotely from the Audirvana Remote App…
I am using r8Brain to up-sample/modulate all PCMxxx to DSD128, with one (1) AU plug-in (Abbey Road Studio 3, virtualization/HRTF), Playback pre-load buffer is set to 5.5GB, and the library drive is connected locally on the USB 3.1 bus.
This interrupt does not occur when playing a DSD track and then selecting another DSD track to “Play Next”… It does occur when playing a DSD track and then selecting a PCM track to “Play Next” or when playing a PCM track and selecting another PCM track to “Play Next” and if playing a PCM track and then selecting a DSD track to “Play Next”.
I will do this test and report… However, I had not encountered this behavior previous to this experience when utilizing the exact same playback configuration.
I removed the AU plug-in and did not experience the interruption… I added the AU plug-in and tested again and did not experience the interruption… I guess doing this cleared a buffer?
@Antoine Okay… tonight I did some more testing with adding to “Play Next” using the AU plug-in enabled… I got the interrupt across the board except for DSD playback (obviously)… I lowered my playback pre-load memory allocation to 4GB and I still get the momentary drop-out but it is shortened and less disruptively prominent (than with 5G pre-load memory allocated) when adding tracks to the “Play Next” cue…. I played DXD 24/352.8k tracks modulated to DSD128 and selected other 24/352.8kHz tracks and PCM 16/44.1kHz tracks and DSD, switching and varying the sample-rate changes back and forth…
I can’t say for sure that there is a correlation to the recent 2.5.0/1 update, because adding tracks to the play cue is not my normal mode of operation… However, this is something that I have not encountered previously.
I do notice when playing tracks tonight and opening and switching to my browser to enter this post, that this action caused a momentary drop-out and sometimes a short burst of drop-outs… This is something that I rarely do (using other applications while playing music in Audirvana Studio)
There is no equivalent to Waves Abbey Road Studio 3… and it is the current update.
Generally, I don’t have problems with playback using this configuration of r8Brain up-sampling/modulating all PCM files to DSD128 and general binaural DSD playback… I just happened to try using the “Play Next” cue… I see that my configuration does consume a significant amount of system RAM… I never really paid much attention to RAM percentage as I just listen for playback anomalies, like clipping, drop-outs and ISP distortions, or smearing due to buffer overruns and under-runs…
My expectation with “Play Next” is, the track selected to “Play Next” is only put into the playback cue, however, I see that the whole album of tracks is put into the playback cue… I also see that the CPU percentage climbs accordingly as it pre-loads the file data, until at which point the file has been fully loaded… I expect this to be normal, however, see the CPU percentage getting close to maximum on occasion…
With 16/44.1kHz files being modulated to DSD128 and DXD 24/352.8kHz files being modulated to DSD128, I expect there will be much number crunching in concert with DoP packetizing and have seen the system RAM-use percentage rise to over sixty-percent… I expect this is normal? I never really paid much attention to Audirvana system RAM usage during playback, under the playback conditions as I have it configured.
I think this now mostly related to track to track sample-rate differences… I’ve updated to version 2.5.2 of Studio and did some bouncing around, and now see that the selected track is only loaded into the play queue, however, initially finding the drop-out (very short)… It seems that common sample-rates don’t induce the drop-out, but I am not completely sure about this and will do more tests… Using “Add to Play Queue” seems to avoid the drop-out… will investigate further. The memory usage remaining constant with 2.5.2 as the memory leak has been addressed in this update. I am getting mixed behavior so will spend more time with adding tracks to the playlist…
@Antoine …Okay… I’m pretty sure I’ve figured out how to use the playlist queue so not to get drop-outs when adding tracks to the queue… I really never use playlists or queue tracks to “Play Next”, so I never paid attention to what happens when selecting a track from an album of tracks…
I see now that when I select a track from an album of tracks and select the “Play” button, the track plays, however the whole album of tracks is loaded into the playback queue along with it… (This does not seem logical to me, but it is what it is…) My expectation was that a single track is selected and no other track will play subsequently, unless loaded into the play queue… I obviously, expect when selecting an “Album” to play from the library screen, that the album of tracks will play in sequenced order… this always seems logical.
I now understand how Audirvana Audio is managing the initial track or album selection for playback…
Selecting an album and selecting the “Play” icon from the library window, all tracks are loaded into the play queue. (obvious)
Initially when selecting a track from the album tracks display, the selected track plays as expected and the whole album of tracks is loaded into the play queue. (It’s not logical to me that the whole album of tracks is loaded simultaneously…)
Selecting a track from an album of tracks when the play queue is empty using “Play Next”, the single track is loaded into the queue, but will not play until selected to play from the queue window.
The same behavior is the same for “Add to Play Queue”.
If a track is selected to play from an album of tracks and the whole album is added to the play queue, any subsequent track selection using “Play Next” will produce a drop-out… (I presume this is because of how the play-back memory is allocated and purged, as I see the CPU percentage jump substantially) However, if the play queue is cleared prior to adding a track using “Play Next” or “Add to Play Queue” there is no drop-out.
(Although it seems illogical in the context of my mode of use scenario…) I understand loading the whole album may make sense when returning to an album of tracks and starting from a new selection that one may wish to begin again from…
Well… I now have a mode of operation that will produce one-shot track playback using the Play Queue without the drop-outs… In the context of my configuration of Audirvana Studio and system RAM and pre-load RAM allocation, I must be aware of how many tracks are in the Play Queue, and keep it simple if I want to use “Play Next” or “Add to Play Queue” and not get drop-outs.
@Antoine … After a couple of hours adding tracks to the Play Queue, I see that when a track is selected from an album of tracks, and the whole album of tracks is placed into the queue, that my CPU Load percentage jumps from about 3% or 4% to 35% or 40% until (apparently) the tracks have been loaded into the playback memory allocation, then the CPU Load drops back down to around 3% or 4%…
I am presuming a faster storage drive will reduce the CPU Load when playing a track in concert with the background loading of the rest of the tracks from the album, or will it just take less time to reduce the CPU Load…? My library HDD is on the USB 3.1 bus and capable of 5Gb/s (625MB/s) and I see there is no way to clear the Play Queue from the iOS Remote App so to stop the background loading of tracks…
I also presume that this has been the normal playback operation, that I have been taking for granted as not producing a lot of background operations while a track is playing… It seems to me that the background pre-loading will produce interrupts that can potentially smear the bit/packet level signals with the increase in CPU Load…
So, is it fair to presume that a faster macOS platform with a fast SSD library storage, will reduce the potential for bit/packet level smearing from the library storage request interrupts, or is this presumption of no consequence in the overall performance of Audirvana Studio today, given my current computer platform and library storage device configuration? My current playback pre-load memory allocation is 5GB…
