Bug head Emperor

Status
Not open for further replies.
Jump to Latest
#81
You've answered my question, thanks. I would suspect the heavy use of DSP is what makes the differences in sound. Signal processing aside if a player is just spitting bits out to the DAC then with the same DAC they should all sound very very similar (the same) if just putting out bit identical data.
 
#86
phofman said:
What DSPs does it do specifically, apart of conversion to DSD and preloading/decoding the tracks to RAM?

I wonder how a software can improve/tweak jitter at the soundcard.
Click to expand...

a) no idea whatsoever and I'm guessing you would need to personally visit the developer, with a translator and several kilos of ascorbic acid, before anything approaching sensible could be discerned.

That, however, shouldn't nullify the investigating.... I imagine that connectedness and communication are not his strengths but that doesn't mean that something is not happening.....

As Willy said....
There are more things in heaven and earth, Horatio, Than are dreamt of in your philosophy.

b) From what I can gather the 'rewrite' function before playback de-fragments the queued audio to produce a contiguous file... if that's the 'preloading' then there may be a benefit ?

It's certainly a journey of discovery with more tweaks and options than one could imagine and so little published information that it is almost pushing buttons at random ...but that doesn't mean that something is not happening.....
 
#87
The contiguous file will be split anyways by the driver stack - copied block by block to a memory region for DMA transfer to the soundcard/usb controller. Writing the data to RAM by the CPU/driver and reading from RAM by the soundcard controller via DMA are independent processes. I do not see how user-space software can influence the crystal clock in the soundcard timing the DMA reading and the DA conversion.
 
#88
I'm using this software on a fanless pc with windows server 2012 r2 OS, Core i5 6500T cpu, 256gb m.2 ssd & 16gb RAM. Even with those specs it takes about a minute for it to do the re-write and load an album. The number of DSP options is overwhelming and it's next to impossible to keep track & notice the differences of each. The user graphic interface is easy to navigate but in the same level as foobar in terms of maturity.

I also have JRiver & Foobar on the same system thus I have compared them vs bug head emperor extensively. Right off the bat, I'd say BHE has a warm and rich sound and maybe that's the reason why people are drawn to it. JRiver with the right tweaks and its ability to host vst plugins can be configured to suit one's taste. In terms of ease of use and graphic interface, JRiver is the most matured but it's not free.
 
#91
phofman said:
The contiguous file will be split anyways by the driver stack - copied block by block to a memory region for DMA transfer to the soundcard/usb controller. Writing the data to RAM by the CPU/driver and reading from RAM by the soundcard controller via DMA are independent processes. I do not see how user-space software can influence the crystal clock in the soundcard timing the DMA reading and the DA conversion.
Click to expand...

The explanations given for operation of this product seem to bear little relationship to technical reality , and the whole thing smells of snake oil to me, but I do wonder.

We can only have one DMA bus master device at a time so I guess there is potential for timing effects with soundcard/diskController/CPU/other DMA controllers having to wait for another to release the bus. Whereas user-space software (applications) can't control this directly those DMA operations (largely) originate from stuff the applications do. So reducing DMA activity by for example buffering files in memory may have an effect, or not.

The more detail I try to look at this sort of stuff in the more difficult it seems to actually have an opinion 🙂
 
Last edited:
#92
Any audio data underrun is pretty audible - missing samples do not sound like change in sound color 🙂 I do not see how DMA transfer could change speed of the crystal clock in the sound controller - jitter.

Actually, I have never encountered a DMA underrun. Plus the DMA transfer is performed by the soundcard controller.

If you google through audio forums, you will not find a positive blind listening test confirming real existence of this software voodoo (at least I have never seen one and have been monitoring this for a few years). In fact, you will not find a report of an ABX test performed by anybody claiming this. But you will find loads of "science is not enough, we do not know everything yet" crap.
 
#94
USB controller uses its own clock (often generated by PLL from some common master clock) and reads/writes the data to/from RAM via DMA too. CPU (=software drivers) prepares/formats the USB frames into memory, but the actual transfer is again independent, clocked by the usb controller itself.
 
#95
phofman said:
Any audio data underrun is pretty audible - missing samples do not sound like change in sound color 🙂 I do not see how DMA transfer could change speed of the crystal clock in the sound controller - jitter.

Actually, I have never encountered a DMA underrun. Plus the DMA transfer is performed by the soundcard controller.

If you google through audio forums, you will not find a positive blind listening test confirming real existence of this software voodoo (at least I have never seen one and have been monitoring this for a few years). In fact, you will not find a report of an ABX test performed by anybody claiming this. But you will find loads of "science is not enough, we do not know everything yet" crap.
Click to expand...

Indeed. And hopefully a 'properly designed' sound card would have its own small output buffer so that even if there was a small contention delay with its main memory DMA there wouldn't be any effect.

Whether sound cards are actually manufactured like that I don't know. Whether without that buffer any DMA wait would be audible I don't know. There's a lot I don't know 🙂

But I do find it difficult to imagine that all DMA requests will be satisfied with constant latency if you have the CPU, the sound card, the disk controller, the USB controller, wi-fi etc. all busy generating DMA requests at the same time.
 
#96
gwingn said:
Indeed. And hopefully a 'properly designed' sound card would have its own small output buffer so that even if there was a small contention delay with its main memory DMA there wouldn't be any effect.
Click to expand...

Of course they do have a small buffer. The input side - clocked by PCI(e) clock. The output side - clocked by the master/DAC (or usb controller) clock. The controller keeps sending the DMA requests.


But I do find it difficult to imagine that all DMA requests will be satisfied with constant latency if you have the CPU, the sound card, the disk controller, the USB controller, wi-fi etc. all busy generating DMA requests at the same time.
Click to expand...

Of course the latency varies. Should the data not arrive on time, an underrun (audible click) will occur. The output clock will not wait, affecting the jitter. The output clock is not PLLed from the data incoming over DMA.
 
Last edited:
#98
What I find interesting is that quite often in Audio sub standard products are lamented as fantastic because of the background and myths surrounding them... funnily this software is being used for an audiophile server... again surrounded by belief rather than good engineering practice.
Be it hand rolled capacitors or rather suspect software, give it a good story, throw in some Audiophile beliefs add a lone guru working for the good of mankind and voila!
 
Status
Not open for further replies.
Top Bottom