A toast to PGGB, a heady brew of math and magic

[Fourlegs]

4 minutes ago, Progisus said:

Does mconnect point the player directly to the source or does the file go through mconnect on it’s way to the player. i.e. after starting can you disable mconnect and the song keeps playing? For optimum quality direct play is preferred. 

Mconnect is not in the signal path. You can pull the Ethernet cable from the rear of the streamer and the file/album keeps playing. 

[Progisus]

1 hour ago, Fourlegs said:

Mconnect is not in the signal path. You can pull the Ethernet cable from the rear of the streamer and the file/album keeps playing. 

OK.. I'll give that another listen. I think mconnest is a dlna/ipnp player. I was trying not to run dlna server and using true MPD applications such as Cantata, Rigelian etc. The later MPD versions use direct access to the file system on the  Antipodes server.

[Progisus]

2 hours ago, Fourlegs said:

Mconnect is not in the signal path. You can pull the Ethernet cable from the rear of the streamer and the file/album keeps playing. 

I revisited mconnect. The quality is right there with Rigelian. Pulling the ethernet quits at the end of the track while Rigelian quits at the end of the album. Terminating mconnect completely by a second up swipe terminates playback immediately. Rigelian continues to play. Interesting little things which make one wonder on the path of the file.

 

I am getting such a dramatic noticeable improvement with PGGB through roon/hgpe that it still wins out for me. Time to listen.

[Fourlegs]

10 hours ago, Progisus said:

I revisited mconnect. The quality is right there with Rigelian. Pulling the ethernet quits at the end of the track while Rigelian quits at the end of the album. Terminating mconnect completely by a second up swipe terminates playback immediately. Rigelian continues to play. Interesting little things which make one wonder on the path of the file.

 

I am getting such a dramatic noticeable improvement with PGGB through roon/hgpe that it still wins out for me. Time to listen.

Pulling the Ethernet cable effectively proves that mconnect is not in the signal path. I guess that terminating mconnect by doing the double swipe must send a stop signal to MPD.

 

As ever the user is the only person who can decide on what sound quality is acceptable. For me MPD is so far ahead of Roon + HQP + NAA on the Antipodes that i am willing to ditch Roon.

 

As an aside for Innuos users thinking of trying PGGB i can tell them that the impending Innuos 2.0 app can play PGGB 705 / 768 32bit files and has a user interface which is a very good replacement for Roon. I am running the beta version of 2.0 and the sound quality of PGGB files on the Innuos is superb and well waiting for when it comes out. 

[musicme2]

Hi Fourlegs

A question about using the new update from Innuos when its available .

My set up is Zenith / Phoenix to Mscaler / Dave , when selecting bit rate would I use 25bit or the 32bit .

Have read in this thread that if using the Mscaler I should use the 25bit is that correct as you are beta testing the new update 

would this  still apply . I want to make a few samples of my music using the trail version of BGGD before the trail date ends so I will have

some samples to try as the new Innuos 2.0 is still not available and by the time I install the new update my trail version BGGD would have ended .

[Zaphod Beeblebrox]

5 hours ago, musicme2 said:

Hi Fourlegs

A question about using the new update from Innuos when its available .

My set up is Zenith / Phoenix to Mscaler / Dave , when selecting bit rate would I use 25bit or the 32bit .

Have read in this thread that if using the Mscaler I should use the 25bit is that correct as you are beta testing the new update 

would this  still apply . I want to make a few samples of my music using the trail version of BGGD before the trail date ends so I will have

some samples to try as the new Innuos 2.0 is still not available and by the time I install the new update my trail version BGGD would have ended .

If you plan to play gargle blasted tracks via MScaler in pass through, yes please use 24bits with noise shaping on. Though I would recommend playing direct to DAVE via USB at 32 bits or using SRC-DX  at 24bits.  

 

If you are unable to evaluate because the trial period expires before Innous 2.0 is released, no worries,  just email me and I can extend the trial to help you.

 

[Progisus]

6 hours ago, Fourlegs said:

Pulling the Ethernet cable effectively proves that mconnect is not in the signal path. I guess that terminating mconnect by doing the double swipe must send a stop signal to MPD.

 

As ever the user is the only person who can decide on what sound quality is acceptable. For me MPD is so far ahead of Roon + HQP + NAA on the Antipodes that i am willing to ditch Roon.

 

As an aside for Innuos users thinking of trying PGGB i can tell them that the impending Innuos 2.0 app can play PGGB 705 / 768 32bit files and has a user interface which is a very good replacement for Roon. I am running the beta version of 2.0 and the sound quality of PGGB files on the Innuos is superb and well waiting for when it comes out. 

Thanks. I will be using mconnect for MPD playback. 

[LowOrbit]

I have been playing my handful of PGGB 32/705 tracks again this weekend having just taken delivery of an SRC.DX to feed my Mscaler/DAVE (and of course just DAVE). I found that WTFPlay works with these files without issue (Fred only claims 352/384 as the upper rate, but I guess the capabilities of the USB interface hold sway).

 

Sound is - as always with WTF - exquisite. Enough to have me re-evaluating my initial thoughts re PGGB perhaps. 

 

ALso proved more reliable than Audirvana (3.5 or Studio trial) which is not happy with the SRC.DX driver - random failures to start playback and application crashes. Shame because the sound is fine.

[sig8]

I have been listening to Gargle Blasted files for several days now. Amazing improvement in SQ. Only a big leap in speakers, cables, amp, or pre might give you this kind of improvement in sound. My system sounds best ever. I am feeding 20bit 32fs files to Terminator Plus DAC.

[musicme2]

Thank you Zaphod for offer to extend trail I will most likely do that as the roll out will be delayed .

I tried to use the SRC- DX when first came out but it was not compatible with the Innuos it worked to let audio through but I could not get the audio signal to use double BNC . I spent weeks trying solve the problem but always ended with Dave showing not seeing the 2-BNC signal , email from Innuos the confirmed that it would not work with Zenith mrk ii , so I sold the SRC-DX .

[austinpop]

There seems to be some ongoing confusion about what bit depth to process PGGB files for the DAVE/TT2/Qutest when going through the SRC-DX USB-to-DBNC bridge.

 

The short answer is 24. (Not 42. That's the Ultimate Answer. We aren't there yet. The Galactic Government gave us a waiver. )

 

Why? TL;DR below.

 

When processing PGGB files, the prime directive is to do so in a way that the PGGB files are not molested on the way to the DAC. So you want to look at the bit depth allowed by the eventual DAC interface you're driving, not the SRC-DX USB interface you're initially driving. WIth the SRC-DX, you're eventually driving the dual BNC inputs on the DAC, and these only support 24-bits.

 

You might think: but the USB input on the SRC-DX supports 32-bit, so why not use 32-bit? The reason is that then you're asking the controller chipset in the SRC-DX to do the 32-to24-bit conversion, and we don't know what it does. Does it truncate? Round? Dither? None of these are good options because they all negate the noise shaping that PGGB did for you so carefully. The noise shaper in PGGB is a critical contributor to the superior SQ, and molesting the signal this way will affect SQ.

 

There are many other considerations when picking bit depth, and they vary by DAC and connection path. The above was specifically addressed to Chord DACs being driven via an SRC-DX bridge.

[ajm]

In an earlier post, Rajiv @austinpop, you mentioned that 256GB RAM might be beneficial for PGGB. As most PC's are not upgradable beyond 128GB, is it possible to hint what 256GB might be needed for (is it just very long tracks?) Could @Zaphod Beeblebrox perhaps also comment on whether any future developments of PGGB are likely to further increase the RAM requirements above 128GB.

If one is purchasing a new PC largely for the purpose of PGGB activity, it would be particularly frustrating to find in due course that the chosen machine was actually inadequate because the RAM could not be expanded sufficiently. In addition, machines suitable for more than 128GB RAM are generally in a significantly higher price bracket.

[austinpop]

3 minutes ago, ajm said:

In an earlier post, Rajiv @austinpop, you mentioned that 256GB RAM might be beneficial for PGGB. As most PC's are not upgradable beyond 128GB, is it possible to hint what 256GB might be needed for (is it just very long tracks?) Could @Zaphod Beeblebrox perhaps also comment on whether any future developments of PGGB are likely to further increase the RAM requirements above 128GB.

If one is purchasing a new PC largely for the purpose of PGGB activity, it would be particularly frustrating to find in due course that the chosen machine was actually inadequate because the RAM could not be expanded sufficiently. In addition, machines suitable for more than 128GB RAM are generally in a significantly higher price bracket.

 

I can't recall what I said, but my intent was to say that if you have 256GB, it can speed up some very challenging remasters, like a DSD256 track that's 45 minutes long, with Max taps set to 8192!

 

But you don't require 256GB, or even 128GB for that matter. I have a 128GB machine, and I have yet to run into an album that won't process. Some do take a very long time, but again, this in only for those pathological DXD or DSD albums with long track lengths. They do get done, eventually.

 

The key thing to keep in mind is that PGGB needs a certain amount of virtual memory to run, and you must accommodate this virtual memory by configuring your system appropriately. To explain, here is what Task Manager shows on my system. The amount of available virtual memory for the entire system is shown in the Red oval.

 

 

This number is actually the sum of the physical RAM (in my case 128GB) and the allocated paging files, shown below:

 

 

By human arithmetic, that total 128+350=478GB, but math was never Windows' strong suit  so they show it at 470GB. Good enough for government work, I guess.

 

So what this is saying is that as long as all processes in your system are allocating less than 470GB of virtual memory, things will fit. When running PGGB, you really want to only be doing that, so this is effectively the virtual memory that PGGB can use. If you get an OOM (out of memory) error when running PGGB, it is telling you that it has exhausted virtual memory. You can remedy this by increasing the paging file size, as long as you have free space on the disk on which the paging file lives.

 

But keep in mind that you still only have 128GB of RAM, and this is where paging enters the picture. The amount of virtual memory that is allocated (not necessarily used) by all processes in the system is known as the committed memory, or the commit charge, in Windows-speak. This is the amount in the green oval. If this commit charge grows to exceed the available virtual memory, you get OOMs.

 

Task Manager also shows you the amount of physical RAM that is in use (the purple oval). What you will see if you observe Task Manager during a heavy PGGB run is something like this:

• Commit charge will start growing
• Memory in use will also start growing, but won't be as high as the commit charge. This is because an application may commit (allocate) virtual memory, but not necessarily use it. The amount of virtual memory a process is actually using at any time is called its working set, and you can observe this with other tools like Process Explorer. But let's go back to the application's progress
• If at some point, the memory in use grows to fill the available RAM, the OS will start paging. This is a mechanism where because the demand for physical memory exceeds what's available, the OS will temporarily expel pages not in use to accommodate pages in use. These pages are written out to the paging file on disk.
• When this happens, it's called paging, and it can be observed in multiple ways. In the Task Manager view, you will see a burst of I/O to the disk, so the disk utilization (in the blue box) will go up. 

This is why having the paging file on a really fast SSD is such a good idea. In days of yore, for those old enough to remember the days of HDDs, a system that went into heavy paging essentially became unusable. With modern SSDs, and with a batch-oriented application, you can actually tolerate a moderate amount of paging, but the inevitable slowdown in execution time can be mitigated by ensuring the page file is on a fast SSD.

 

This is why it is strongly recommended that you run PGGB on a machine with a fast SSD hosting the OS and the paging file.

 

Summary

 

While PGGB will run much faster when you provision your machine with more RAM, you can still run even the most challenging workloads, as long as you supply adequate page file space. Make sure to put that page file on as fast an SSD as you can manage, to improve run time.

[austinpop]

Before anyone asks — the rationale is the same on MacOS, but I'm not intimately familiar with how MacOS manages virtual memory. 

 

I do know that MacOS doesn't rely on preallocated paging files, but dynamically generates one (or more) swapfile's in dynamic response to virtual memory demand. How well this works is to be determined, although I have heard some reports from PGGB beta users that suggested that this dynamic allocation strategy, while more robust and elegant, does seem to be slower. 

 

This is perhaps not surprising, as the advantage of the preallocated pagefile strategy on Windows, while inelegant, does greedily allocate paging space ahead of time, which may be a run time advantage.

 

In any case, minor differences in run time are irrelevant if you're using PGGB the way you should — as a batch processor, that you set up and let run to completion in the background.

[josephs]

Hi,

 

Apologies if this is the wrong thread to be asking, but a friend sent me a PGGB (705.6kHz) file to listen to so I could compare it to a 44.1kHz file. I'm using a mid-2012 MacBook Pro, so I downloaded the file to my iTunes library, which then automatically transferred ito my Roon library. 

 

I've tried for 2-3 days to play the PGGB file using my Mac via USB direct to my KTE Spring DAC (NOS - max sample rate PCM 32 / 705.6) to no avail. I've tried every configuration I could possibly think of and when I press play I lose the signal to my DAC with the sample rate set to 705.6.

 

I can use 44.1 all the way through to 384 and the PGGB file will play fine. I know that my DAC supports up to 768, but again, once I press play I lose the signal to my DAC. What could I possibly be missing here? I'd appreciate any input to help try and figure this out because I'd really like to compare these two files before moving forward with a license. 

 

Thank you very much,

Joseph

[ted_b]

I've owned a Spring 1 KTE for many years, reviewed it here, and NEVER have I been able to play 16fs (aka 705.6/768k).  FYI. 

[Zaphod Beeblebrox]

2 hours ago, austinpop said:

There seems to be some ongoing confusion about what bit depth to process PGGB files for the DAVE/TT2/Qutest when going through the SRC-DX USB-to-DBNC bridge.

 

The short answer is 24. (Not 42. That's the Ultimate Answer. We aren't there yet. The Galactic Government gave us a waiver. )

 

Why? TL;DR below.

 

When processing PGGB files, the prime directive is to do so in a way that the PGGB files are not molested on the way to the DAC. So you want to look at the bit depth allowed by the eventual DAC interface you're driving, not the SRC-DX USB interface you're initially driving. WIth the SRC-DX, you're eventually driving the dual BNC inputs on the DAC, and these only support 24-bits.

 

You might think: but the USB input on the SRC-DX supports 32-bit, so why not use 32-bit? The reason is that then you're asking the controller chipset in the SRC-DX to do the 32-to24-bit conversion, and we don't know what it does. Does it truncate? Round? Dither? None of these are good options because they all negate the noise shaping that PGGB did for you so carefully. The noise shaper in PGGB is a critical contributor to the superior SQ, and molesting the signal this way will affect SQ.

 

There are many other considerations when picking bit depth, and they vary by DAC and connection path. The above was specifically addressed to Chord DACs being driven via an SRC-DX bridge.

In addition to what @austinpop states above, DBNC, 16FS/24bits input into DAVE/TT2/Qutest is preferred only when using SRC-DX which can convert 16FS USB input to DBNC. I am not aware of any other device being able to do it other than of course the Mscaler.

 

However, there is more to it than just converting USB 16FS to DBNC and the main reason for using SRC-DX is to bypass the USB reciever on DAVE/TT2/Qutest and Mscaler. If USB is plugged into Mscaler and if you use Msclaer for USB to DBNC conversion even in pass through mode, you are still going through the USB receiver of Mscaler.

 

Mscaler when fed 16FS/32bits, though it is not Mscaling, it is not strictly pass through either.  It will noise shape to 24 bits (because BNC cannot do 32 bits). Since PGGB has already noise shaped, Msacler noise shaping again results in double noise shaping and is not ideal. If you wish to keep the mscaler in the path, then you will have better results if you set PGGB output to 24 bits and even better if you directly go to DAVE via USB and keep PGGB output at 32 bits.

In short, ere is my order of preference (low to high):

Not recommended: PGGB tracks (16FS/32bits) -> (USB)Mscaler -> (USB) DAVE /TT2/Qutest

OK   (but not ideal): PGGB tracks (16FS/24bits) -> (USB)Mscaler -> (USB) DAVE /TT2/Qutest

Better                    : PGGB tracks (16FS/32bits) -> (USB) DAVE /TT2/Qutest

Best                      : PGGB tracks (16FS/24bits)-> (USB) SRC-DX-> (DBNC) DAVE/TT2/Qutest

 

[josephs]

10 minutes ago, ted_b said:

I've owned a Spring 1 KTE for many years, reviewed it here, and NEVER have I been able to play 16fs (aka 705.6/768k).  FYI. 

This is interesting because I'd thought I'd definitely be able to play it due to the Springs ability to do up to 768? Would you happen to know why this is? 

 

Thanks,

Joseph

[sig8]

As I move towards getting the license, few logistical questions come to mind; storage, and playback file location.

 

Am I correct in thinking to add several 18TB Western Digital SATA HDDs to a NAS for storage? Not thinking of converting everything, but still, there is no spare capacity available at this time, so need something. I have read Rajiv's advise for warehouse/jukebox type of system, but need to build a warehouse and a jukebox, as the house is full right now. My current library is about 2.7TB, and I will be converting to 32fs for my Terminator Plus DAC at 20 bits.

 

Is it preferred (based on sound quality) to playback from internal NVMe or files stored on NAS. 8TB NVMe is $1,400 currently, that can buy 2-18TB HDD's for NAS. Thoughts?

[ajm]

Many thanks to @austinpop for the detailed reply about RAM requirements - very helpful

[Zaphod Beeblebrox]

21 minutes ago, sig8 said:

As I move towards getting the license, few logistical questions come to mind; storage, and playback file location.

 

Am I correct in thinking to add several 18TB Western Digital SATA HDDs to a NAS for storage? Not thinking of converting everything, but still, there is no spare capacity available at this time, so need something. I have read Rajiv's advise for warehouse/jukebox type of system, but need to build a warehouse and a jukebox, as the house is full right now. My current library is about 2.7TB, and I will be converting to 32fs for my Terminator Plus DAC at 20 bits.

 

Is it preferred (based on sound quality) to playback from internal NVMe or files stored on NAS. 8TB NVMe is $1,400 currently, that can buy 2-18TB HDD's for NAS. Thoughts?

For 32FS or 16FS file, certainly better to playback from internal drive. I too have the 8TB NVME and I also have 2TB intel NVMEs on my server and they sound great.

 

Though my full library is close to 2TB, only those I listen to frequently get to go on to to the SSD.

[Progisus]

My files are in 16fs 24b. I am playing through hqpe to src-dx to tt2. Should I set the dac bits in hqpe to 24b? 

If I remove the src-dx and play to the usb on tt2 should I set the dac bits in hqpe to 24b?

[Zaphod Beeblebrox]

2 minutes ago, Progisus said:

My files are in 16fs 24b. I am playing through hqpe to src-dx to tt2. Should I set the dac bits in hqpe to 24b? 

If I remove the src-dx and play to the usb on tt2 should I set the dac bits in hqpe to 24b?

Yes to both. If your gargle blasted tracks are 16fs/24 bits, set HQPE to 24bits irrespective of whether you use SRC-DX or not.

 

[muski]

5 hours ago, austinpop said:

Before anyone asks — the rationale is the same on MacOS, but I'm not intimately familiar with how MacOS manages virtual memory. 

 

I do know that MacOS doesn't rely on preallocated paging files, but dynamically generates one (or more) swapfile's in dynamic response to virtual memory demand. How well this works is to be determined, although I have heard some reports from PGGB beta users that suggested that this dynamic allocation strategy, while more robust and elegant, does seem to be slower. 

 

This is perhaps not surprising, as the advantage of the preallocated pagefile strategy on Windows, while inelegant, does greedily allocate paging space ahead of time, which may be a run time advantage.

 

In any case, minor differences in run time are irrelevant if you're using PGGB the way you should — as a batch processor, that you set up and let run to completion in the background.

I'm having issues on my iMac blasting >600MB DSD files—I get a warning saying "Your system has run out of application memory" and then I can see PGGB is not responding, and fails. It's happened on two tracks now. I'm using the Throttle DSD toggle, but that doesn't help.

 

I have a 2020 iMac with an 8-core i7 with 64GB RAM and a very fast SSD (so swapfiles should work really well). Feels like something else isn't quite right. Any MacOS gurus have ideas? Anyone else seeing this?

 

Cheers,

muski

[Zaphod Beeblebrox]

3 minutes ago, muski said:

I'm having issues on my iMac blasting >600MB DSD files—I get a warning saying "Your system has run out of application memory" and then I can see PGGB is not responding, and fails. It's happened on two tracks now. I'm using the Throttle DSD toggle, but that doesn't help.

 

I have a 2020 iMac with an 8-core i7 with 64GB RAM and a very fast SSD (so swapfiles should work really well). Feels like something else isn't quite right. Any MacOS gurus have ideas? Anyone else seeing this?

 

Cheers,

muski

Throttle DSD only helps with system cooling as it make sure not all cores are loaded. On Mac with no way to control swap, it is totally up to the OS. What is the max taps you have set? you can also email me the log so i can see what is going on. One way to help with swap is try and close all applications other than PGGB.  Is it a DSD64?