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âŚ
